On Tue, Jan 31, 2012 at 3:48 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > If the DEBOUNCENABLE bit is set and the debounce clock is off and the GPIO > IP block is idle, then yeah, I'd assume that GPIO wakeups would not > work. > > But it sounds like they are working for you when DEBOUNCENABLE is set and > the debounce clock is on and the GPIO IP block is idle and CORE & PER are > ON? I think so. It works with DEBOUNCENABLE set when cpuidle is disabled or CPU is spinning. CORE & PER are ON according to pm_debug/count, I think debounce clock is enabled too but I don't know if GPIO is idle then (how do I check?). > And when DEBOUNCENABLE is clear and the debounce clock is off and the GPIO > IP block is idle and CORE & PER are still ON, then they work? Yes. > If the answer to those two latter questions are true, then it sounds like > the hardware is working more or less as expected... So when does all wakeup stuff come into effect, when CORE+PER go to low power state? I'm using 3.2 and CORE seems to always be ON (regardless of cpuidle option) except when I suspend I guess. I can get PER state to change if I set serial timeouts, but that doesn't help the GPIO problem. > Of course our software support probably still isn't right. We probably > should keep the debounce clock enabled as long as some GPIO has debounce > support enabled. And probably provide some way for GPIO users to indicate > whether they are okay with debounce support being disabled when the > rest of the CORE/PER can enter a low-power state. The motivating > principle being that PM shouldn't violate a requirement from the rest of > the system... > > Anyway, just thinking out loud. > > > - Paul -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
