* Kevin Hilman <khil...@deeprootsystems.com> [100309 11:23]: > Tony Lindgren <t...@atomide.com> writes: > > > * tero.kri...@nokia.com <tero.kri...@nokia.com> [100309 00:20]: > >> > > >> >Changes in wakeup state should not be directly correlated to interrupt > >> >enabled GPIOs. Rather, this should only be done for GPIOs that are > >> >explicitly wakeup enabled (via enable_irq_wake(), which in turn > >> >calls gpio_wake_enable()). > >> > >> This logic somehow escapes me... I would guess drivers should not care > >> during dynamic idle whether the device is in off/ret/ina and interrupts > >> should just work. This is done to make this happen. Also, I understood > >> that gpio wakeup logic is needed for the suspend wakeup, which is quite > >> different from dynamic idle wakeup. > >> > >> However, if this is intended behavior for the kernel, then I will accept > >> it. You are saying the code below should be moved into the > >> gpio_wake_enable() / disable() calls? > > > > I agree. I'd assume during the idle modes we want everything to > > automatically wake the system up. Otherwise we again have non-standard > > Linux behaviour that's mysterious to track down. The enable_irq_wake > > should only be needed for suspend states. > > OK, then essentially all GPIO IRQs need to be configured in the > equivalent of an enable_irq_wake'd state by default. That means > IO pad wakeups *and* module-level wakeups. > > Upon suspend, the ability to wakeup should be removed for all except > for those that have been explicitly enabled via enable_irq_wake().
That sounds pretty good to me. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
