1. 02 May, 2015 1 commit
  2. 20 Oct, 2014 1 commit
  3. 29 Jul, 2014 1 commit
    • Suman Anna's avatar
      hwspinlock/omap: enable module before reading SYSSTATUS register · e1e4528f
      Suman Anna authored
      The number of hwspinlocks are determined based on the value read
      from the IP block's SYSSTATUS register. However, the module may
      not be enabled and clocked, and the read may result in a bus error.
      This particular issue is seen rather easily on AM33XX, since the
      module wakeup is software controlled, and it is disabled out of
      reset. Make sure the module is enabled and clocked before reading
      the SYSSTATUS register.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      [replace pm_runtime_put_sync with lenient pm_runtime_put]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
  4. 28 Nov, 2012 3 commits
  5. 21 Sep, 2011 5 commits
    • Ohad Ben-Cohen's avatar
      hwspinlock/omap: omap_hwspinlock_remove should be __devexit · 9efb4a1b
      Ohad Ben-Cohen authored
      Mark omap_hwspinlock_remove with __devexit (and use __devexit_p
      appropriately) so the function can be discarded when the conditions are met.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
    • Ohad Ben-Cohen's avatar
      hwspinlock/core: register a bank of hwspinlocks in a single API call · 300bab97
      Ohad Ben-Cohen authored
      Hardware Spinlock devices usually contain numerous locks (known
      devices today support between 32 to 256 locks).
      Originally hwspinlock core required drivers to register (and later,
      when needed, unregister) each lock separately.
      That worked, but required hwspinlocks drivers to do a bit extra work
      when they were probed/removed.
      This patch changes hwspin_lock_{un}register() to allow a bank of
      hwspinlocks to be {un}registered in a single invocation.
      A new 'struct hwspinlock_device', which contains an array of 'struct
      hwspinlock's is now being passed to the core upon registration (so
      instead of wrapping each struct hwspinlock, a priv member has been added
      to allow drivers to piggyback their private data with each hwspinlock).
      While at it, several per-lock members were moved to be per-device:
      1. struct device *dev
      2. struct hwspinlock_ops *ops
      In addition, now that the array of locks is handled by the core,
      there's no reason to maintain a per-lock 'int id' member: the id of the
      lock anyway equals to its index in the bank's array plus the bank's
      Remove this per-lock id member too, and instead use a simple pointers
      arithmetic to derive it.
      As a result of this change, hwspinlocks drivers are now simpler and smaller
      (about %20 code reduction) and the memory footprint of the hwspinlock
      framework is reduced.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
    • Ohad Ben-Cohen's avatar
      hwspinlock/core/omap: fix id issues on multiple hwspinlock devices · c3c1250e
      Ohad Ben-Cohen authored
      hwspinlock devices provide system-wide hardware locks that are used
      by remote processors that have no other way to achieve synchronization.
      To achieve that, each physical lock must have a system-wide id number
      that is agreed upon, otherwise remote processors can't possibly assume
      they're using the same hardware lock.
      Usually boards have a single hwspinlock device, which provides several
      hwspinlocks, and in this case, they can be trivially numbered 0 to
      (num-of-locks - 1).
      In case boards have several hwspinlocks devices, a different base id
      should be used for each hwspinlock device (they can't all use 0 as
      a starting id!).
      While this is certainly not common, it's just plain wrong to just
      silently use 0 as a base id whenever the hwspinlock driver is probed.
      This patch provides a hwspinlock_pdata structure, that boards can use
      to set a different base id for each of the hwspinlock devices they may
      have, and demonstrates how to use it with the omap hwspinlock driver.
      While we're at it, make sure the hwspinlock core prints an explicit
      error message in case an hwspinlock is registered with an id number
      that already exists; this will help users catch such base id issues.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
    • Ohad Ben-Cohen's avatar
      hwspinlock/omap: simplify allocation scheme · c97f6dd0
      Ohad Ben-Cohen authored
      Instead of allocating every hwspinlock separately, allocate
      them all in one shot.
      This both simplifies the driver and helps achieving better
      slab utilization.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
    • Ohad Ben-Cohen's avatar
      hwspinlock/core: simplify 'owner' handling · e467b642
      Ohad Ben-Cohen authored
      Use struct device_driver's owner member instead of asking drivers to
      explicitly pass the owner again.
      This simplifies drivers and also save some memory, since there's no
      point now in maintaining a separate owner pointer per hwspinlock.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
  6. 17 Feb, 2011 1 commit