summaryrefslogtreecommitdiff
path: root/kernel/sched_debug.c
diff options
context:
space:
mode:
authorKevin Hilman <khilman@deeprootsystems.com>2009-09-10 15:53:08 (GMT)
committerKevin Hilman <khilman@deeprootsystems.com>2009-10-05 17:51:00 (GMT)
commiteb350f74ebff9573641c5fb689fb071b695ef35b (patch)
tree7705cc548ae762c124c6bd2f5d30ff36b57c6d14 /kernel/sched_debug.c
parent71a807757394205cdb1465d68a4f0be50fd6f04b (diff)
downloadlinux-eb350f74ebff9573641c5fb689fb071b695ef35b.tar.xz
OMAP3: PM: Enable GPIO module-level wakeups
Currently, only GPIOs in the wakeup domain (GPIOs in bank 0) are enabled as wakups. This patch also enables GPIOs in the PER powerdomain (banks 2-6) to be used as possible wakeup sources. In addition, this patch ensures that all GPIO wakeups can wakeup the MPU using the PM_MPUGRPSEL_<pwrdm> registers. NOTE: this doesn't enable the individual GPIOs as wakeups, this simply enables the per-bank wakeups at the powerdomain level. This problem was discovered by Mike Chan when preventing the CORE powerdomain from going into retention/off. When CORE was allowed to hit retention, GPIO wakeups via IO pad were working fine, but when CORE remained on, GPIO module-level wakeups were not working properly. To test, prevent CORE from going inactive/retention/off, thus preventing the IO chain from being armed: # echo 3 > /debug/pm_debug/core_pwrdm/suspend This ensures that GPIO wakeups happen via module-level wakeups and not via IO pad. Tested on 3430SDP using the touchscreen GPIO (gpio 2, in WKUP) Tested on Zoom2 using the QUART interrup GPIO (gpio 102, in PER) Also, c.f. OMAP PM wiki for troubleshooting GPIO wakeup issues: http://elinux.org/OMAP_Power_Management Reported-by: Mike Chan <mikechan@google.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Diffstat (limited to 'kernel/sched_debug.c')
0 files changed, 0 insertions, 0 deletions