[PATCH 2/4] pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events

[Tony Lindgren]

* Linus Walleij <linus.walleij at linaro.org> [130722 14:50]:
> On Mon, Jun 10, 2013 at 5:36 PM, Tony Lindgren <tony at atomide.com> wrote:
> 
> > At least on omaps, each board typically has at least one device
> > configured as wake-up capable from deeper idle modes. In the
> > deeper idle modes the normal interrupt wake-up path won't work
> > as the logic is powered off and separate wake-up hardware is
> > available either via IO ring or GPIO hardware.
> 
> What I do not understand is why the irq_set_wake() should
> not fall through to that IO ring / GPIO hardware.

That certainly makes sense.

> For example: a composite GPIO+irqchip driver should surely
> set the wake up for a certain line for irq_set_wake()?

Yes we might be able to make it all transparent to consumer
drivers. Although irq_set_wake() is for suspend/resume only
AFAIK, but ideally we would not have to configure anything
from the consumer drivers for runtime PM.

For the GPIO wake-up events, GPIO + irqchip driver is not
enough as we also need the mapping between pinctrl registers
and GPIO numbers. And to stay out of the database business,
that mapping should ideally come from device tree as it's
only needed for the pins used, not for all hundreds of pins
on a SoC.
 
> > The wake-up
> > event can be device specific, or may need to be dynamically
> > remuxed to GPIO input for wake-up events. When the wake-up
> > event happens, it's IRQ need to be called so the device won't
> > lose interrupts.
> 
> I recognize this hardware type. The name I use for these
> things are "latent interrupts".

OK
 
> What I think is that they should maybe be modeled as
> irqchip from end to end, so that we don't orthogonally use
> any pinctrl states to set this up.

OK I'll take a look.

Regards,

Tony