Re: Powering OMAP's pins

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2795 bytes --]

On Wed, 2012-09-26 at 13:46 +0200, Linus Walleij wrote:
> On Tue, Sep 25, 2012 at 7:05 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> 
> > So when I call pm_runtime_get in the omapdss driver, I imagine that the
> > runtime PM and pinctrl would together handle muxing the pins for
> > omapdss's use, and also enable the relevant regulators to make the pins
> > usable.
> 
> So we do something like this in the recent patch to the PL022
> SPI driver by setting the pinctrl states inside the runtime suspend
> and resume callbacks:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=20120920130240.GR17666%40opensource.wolfsonmicro.com&forum_name=spi-devel-general
> 
> You can very well do clocks and regulators in these functions as well.

That's not really what I mean. The regulators in question are OMAP
version specific, so the driver shouldn't know which regulators are
needed.

The regulators for each pin could be passed to the driver from platform
data, and the driver could enable the regulators in the runtime resume
callback. But then each driver that may use the pins would require the
same code and the same platform data to be duplicated.

> Other platforms like shmobile will use runtime pm notifications
> to do all this orthogonally in a central place, which may be
> applicable for OMAP.

What notifications do you refer to? The PM notifiers (PM_RESTORE_PREPARE
etc) are global, so they are not of help here.

I was going through the pinctrl code to understand it better. If I read
it right, there's a default pin configuration that is set at boot time,
and if that configuration needs to be changed later, the drivers use
pinctrl_get() & pinctrl_select_state() to change it.

How I thought that it works (before going through the code) is that at
boot time a default pin configuration is set, and for many pins this
default config is disabled/safe mode. When a driver, that has been
assigned those pins, is loaded and uses pm_runtime_get() to start its
hardware, the pins would also be enabled and muxed for the proper
operation, without the driver doing any pinctrl calls. And when the
driver does pm_runtime_put(), the pins would be disabled and changed to
safe-mode.

Is there a reason the pin control cannot be automatic as I described
above? The pl022 change you linked seems to do the same, but manually.
Again, I'm not so familiar with pin control, so perhaps all this can be
implemented in platform code.

It sounds easier to me (from driver's perspective), and should preserve
some minimal power also if the pins are disabled when not in use. Of
course, "disabled" here is platform and board specific, on some boards a
pin must be kept alive and, say, pulled down even when not in use.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]