[PATCH 4/6] pinctrl: single: Add support for wake-up interrupts

[Tony Lindgren]

* Roger Quadros <rogerq at ti.com> [131011 02:04]:
> On 10/11/2013 11:00 AM, Linus Walleij wrote:
> > On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren <tony at atomide.com> wrote:
> >> * Linus Walleij <linus.walleij at linaro.org> [131010 09:19]:
> >>> On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren <tony at atomide.com> wrote:
> >>>> * Roger Quadros <rogerq at ti.com> [131010 06:32]:
> >>>>>
> >>>>> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
> >>>>> while the system is still running and only the EHCI controller is runtime suspended.
> >>>>>
> >>>>> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
> >>>>> whenever the pad wakeup_enable bit is changed.
> >>>>
> >>>> Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
> >>>> pcs_irq_handle() like the comments there suggest? At least for me that keeps
> >>>> the wake-up interrupts continuously running on omap3 instead of just idle modes.
> >>>
> >>> If the rearm() function is calling this _reconfigure_io_chain my comments
> >>> on the fact that this is something that should be handled by the pin
> >>> control driver still apply I think ....
> >>
> >> Yes, except that the reconfigure_io_chain registers are in the PRM module, not in
> >> the SCM module where the pinctrl registers are.. And that shared PRM interrupt is
> >> used mostly for the internal domain wake-ups, so we should keep that in the PRM
> >> driver.
> > 
> > That depends.
> > 
> > One-iorange-equals-one-driver is a fallacy, especially given that MFD for
> > memory-mapped things exist for a reason.
> 
> +1
> 
> Another place I faced a similar problem was the OMAP control module, which contains
> registers for a number of different non related peripherals. (e.g. PHY for USB, SATA,
> Display clock, etc)

Guys, we really need to keep the register access between hardware modules
under control because the hardware blocks can live separate life from clocking
and power state point of view.

Regmap could be probably used for the register access across various hardware
modules in a controlled way that is also aware of the clocking and PM state of
the hardware modules in question. As long as it's done sanely, I'm OK with that.

But for any other kind of random direct register tinkering between hardware
modules, that's a no no.

> > What the pin control driver should do is control the pins. Whether the registers
> > are spread out in the entire IO-memory does not matter. We did have one system
> > which placed the IO-muxing together with each peripheral (!) and I did
> > still want
> > that to be handled by a single pinctrl driver picking out windows to all these
> > IO-ranges.
> > 
> > Things like the PRM which has (my guess) a gazillion registers related to its
> > deep-core SoC stuff should be handled by things like
> > drivers/mfd/syscon.c, which means it is dead simple for some other driver
> > using "just this one register" in that range to get a handle at it and poke it
> > using syscon_node_to_regmap() (just derference an ampersand ref)
> > syscon_regmap_lookup_by_compatible() (use a compatible string)
> > all returning a regmap * that you can use to poke these registers.
> 
> The register handling is fine. But how do we deal with resource handling?
> e.g. the block that has the deep-core registers might need to be clocked or powered
> before the registers can be accessed.

Right, that's the key issue here. The register access would have to be conditional
based on the hardware modules PM state. Otherwise we'll have hard to trace hangs
and oopses.

Regards,

Tony