1. 22 9月, 2011 3 次提交
    • O
      hwspinlock/core: register a bank of hwspinlocks in a single API call · 300bab97
      Ohad Ben-Cohen 提交于
      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
      base_id.
      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: NOhad Ben-Cohen <ohad@wizery.com>
      300bab97
    • J
      hwspinlock/core: use a mutex to protect the radix tree · 93b465c2
      Juan Gutierrez 提交于
      Since we're using non-atomic radix tree allocations, we
      should be protecting the tree using a mutex and not a
      spinlock.
      
      Non-atomic allocations and process context locking is good enough,
      as the tree is manipulated only when locks are registered/
      unregistered/requested/freed.
      
      The locks themselves are still protected by spinlocks of course,
      and mutexes are not involved in the locking/unlocking paths.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NJuan Gutierrez <jgutierrez@ti.com>
      [ohad@wizery.com: rewrite the commit log, #include mutex.h, add minor
      commentary]
      [ohad@wizery.com: update register/unregister parts in hwspinlock.txt]
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      93b465c2
    • O
      hwspinlock/core: simplify 'owner' handling · e467b642
      Ohad Ben-Cohen 提交于
      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: NOhad Ben-Cohen <ohad@wizery.com>
      e467b642
  2. 18 2月, 2011 1 次提交
    • O
      drivers: hwspinlock: add framework · bd9a4c7d
      Ohad Ben-Cohen 提交于
      Add a platform-independent hwspinlock framework.
      
      Hardware spinlock devices are needed, e.g., in order to access data
      that is shared between remote processors, that otherwise have no
      alternative mechanism to accomplish synchronization and mutual exclusion
      operations.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Hari Kanigeri <h-kanigeri2@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      bd9a4c7d