On Fri, Nov 22, 2013 at 11:46:10PM +0400, Dmitry Eremin-Solenikov wrote: > Hello, > > On Fri, Nov 22, 2013 at 9:45 PM, Russell King - ARM Linux > <[email protected]> wrote: > > Therefore, if we want to have certain GPIOs triggering wakeups (iow, > > those GPIOs which have had enable_irq_wake() called on them) but not > > those which haven't, we need to reprogram GRER and GFER with the > > GPIOs which can wake the system up. > > I thought so. I was puzzled, because that would mean, that we want to wake > up from a GPIO, which is masked in GPIO_IRQ_mask, but enabled in PWER. > Is that the real scenario/usecase? If we/kernel has disabled IRQ > through _mask_irq, > I thought, we didn't expect events from that pin (including wakeup), did we?
So, if a device driver decides that it wants to be woken up by a GPIO and therefore calls enable_irq_wake() on it, but also calls disable_irq() on that same interrupt to avoid _receiving_ the interrupt until it's ready, does that mean that the system should _not_ be woken up? I doubt many systems work this way - later PXA devices certainly don't, where the wakeup is triggered from the silicon on the pad interface rather than the interrupt controller - where the state of the IRQ masks have no bearing what so ever on it. Please, stop thinking about changing the behaviour of any of the SA11x0 stuff. Treat the code as-is as authoritive on the way things should be done, and _carefully_ "adjust it" to how you'd like to see it - so we can have a higher confidence that stuff isn't being broken or behaviour isn't changed. Such behaviour changes would include looping differently while handling interrupts. And more importantly, treat SA11x0 as a reference implementation for IRQ stuff; that's the platform I developed the IRQ handling stuff on which became the basis for tglx's IRQ layer in the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
