summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap1/board-h3.c
diff options
context:
space:
mode:
authorDavid Brownell <dbrownell@users.sourceforge.net>2006-12-06 17:14:11 -0800
committerRussell King <rmk+kernel@arm.linux.org.uk>2007-05-05 10:57:17 +0100
commit11a78b7944963a8b052be46108d07a3ced9e2762 (patch)
treedd93c3f88de3c8047186c5ee43ecc763cf6f7318 /arch/arm/mach-omap1/board-h3.c
parent58781016c3637caf314ca7f579ce0acd1b0378dc (diff)
ARM: OMAP: MPUIO wake updates
GPIO and MPUIO wake updates: - Hook MPUIOs into the irq wakeup framework too. This uses a platform device to update irq enables during system sleep states, instead of a sys_device, since the latter is no longer needed for such things. - Also forward enable/disable irq wake requests to the relevant GPIO controller, so the top level IRQ dispatcher can (eventually) handle these wakeup events automatically if more than one GPIO pin needs to be a wakeup event source. - Minor tweak to the 24xx non-wakeup gpio stuff: no need to check such read-only data under the spinlock. This assumes (maybe wrongly?) that only 16xx can do GPIO wakeup; without a 15xx I can't test such stuff. Also this expects the top level IRQ dispatcher to properly handle requests to enable/disable irq wake, which is currently known to be wrong: omap1 saves the flags but ignores them, omap2 doesn't even save it. (Wakeup events are, wrongly, hardwired in the relevant mach-omapX/pm.c file ...) So MPUIO irqs won't yet trigger system wakeup. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch/arm/mach-omap1/board-h3.c')
0 files changed, 0 insertions, 0 deletions