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@xxxxxx> 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:
signature.asc
Description: This is a digitally signed message part
