summaryrefslogtreecommitdiffstats
path: root/include/linux/hwspinlock.h
AgeCommit message (Collapse)Author
2012-03-16device.h: audit and cleanup users in main include dirPaul Gortmaker
The <linux/device.h> header includes a lot of stuff, and it in turn gets a lot of use just for the basic "struct device" which appears so often. Clean up the users as follows: 1) For those headers only needing "struct device" as a pointer in fcn args, replace the include with exactly that. 2) For headers not really using anything from device.h, simply delete the include altogether. 3) For headers relying on getting device.h implicitly before being included themselves, now explicitly include device.h 4) For files in which doing #1 or #2 uncovers an implicit dependency on some other header, fix by explicitly adding the required header(s). Any C files that were implicitly relying on device.h to be present have already been dealt with in advance. Total removals from #1 and #2: 51. Total additions coming from #3: 9. Total other implicit dependencies from #4: 7. As of 3.3-rc1, there were 110, so a net removal of 42 gives about a 38% reduction in device.h presence in include/* Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-11-08hwspinlock: Don't return a value in __hwspin_unlockAxel Lin
Fix below build warning: CC arch/arm/mach-omap2/hwspinlock.o In file included from arch/arm/mach-omap2/hwspinlock.c:22: include/linux/hwspinlock.h: In function '__hwspin_unlock': include/linux/hwspinlock.h:121: warning: 'return' with a value, in function returning void Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2011-09-21hwspinlock/core: register a bank of hwspinlocks in a single API callOhad 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: Ohad Ben-Cohen <ohad@wizery.com>
2011-09-21hwspinlock/core: remove stubs for register/unregisterOhad Ben-Cohen
hwspinlock drivers must anyway select CONFIG_HWSPINLOCK, so there's no point in having register/unregister stubs. Removing those stubs will only make it easier for developers to catch CONFIG_HWSPINLOCK mis-.config-urations. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2011-09-21hwspinlock/core/omap: fix id issues on multiple hwspinlock devicesOhad Ben-Cohen
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: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Tony Lindgren <tony@atomide.com>
2011-02-17drivers: hwspinlock: add frameworkOhad 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: Ohad 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: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tony Lindgren <tony@atomide.com>