| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock:
hwspinlock: add MAINTAINERS entries
hwspinlock/omap: omap_hwspinlock_remove should be __devexit
hwspinlock/u8500: add hwspinlock driver
hwspinlock/core: register a bank of hwspinlocks in a single API call
hwspinlock/core: remove stubs for register/unregister
hwspinlock/core: use a mutex to protect the radix tree
hwspinlock/core/omap: fix id issues on multiple hwspinlock devices
hwspinlock/omap: simplify allocation scheme
hwspinlock/core: simplify 'owner' handling
hwspinlock/core: simplify Kconfig
Fix up trivial conflicts (addition of omap_hwspinlock_pdata, removal of
omap_spinlock_latency) in arch/arm/mach-omap2/hwspinlock.c
Also, do an "evil merge" to fix a compile error in omap_hsmmc.c which
for some reason was reported in the same email thread as the "please
pull hwspinlock changes".
|
|
Remove all these duplicated structures since a default one is now
available.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
|
|
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>
|
|
All of the device init and device driver interaction with omap_device
is done using platform_device pointers. To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.
All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.
This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
|
|
Build and register an hwspinlock platform device.
Although only OMAP4 supports the hardware spinlock module (for now),
it is still safe to run this initcall on all omaps, because hwmod lookup
will simply fail on hwspinlock-less platforms.
Signed-off-by: Simon Que <sque@ti.com>
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
