Re: [PATCH] OMAP3: GPIO: Added dynamic control logic for pad wakeups

[Tony Lindgren <tony@atomide.com>]

* Kevin Hilman <khilman@deeprootsystems.com> [100309 11:23]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Tero.Kristo@nokia.com <Tero.Kristo@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