Messages in this thread | | | Date | Thu, 1 Nov 2012 14:22:11 +0100 | Subject | Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support | From | Linus Walleij <> |
| |
On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman <khilman@deeprootsystems.com> wrote: > [Me] >> Well, the pinctrl grabbers in these drivers are using these states also >> for platforms that do not even select CONFIG_PM. For example >> mach-nomadik is quite happy that the PL011 driver is thusly >> muxing in its pins. And would require refactoring to use PM >> domains. > > If CONFIG_PM is disabled, then is it safe to assume that the pins in > question are probably only done once at init time. I assume during > ->probe(). ?
Sadly no.
Consider drivers/tty/serial/amba-pl011.c
Many ARM platforms have several instances of PL011, and not all of them have CONFIG_PM & friends, so it's a good example.
Here the driver will probe and currently fetch a pinctrl handle and looks up two states: "default", which refers to the situation you describe, and optionally "sleep" which will put pins into a low-power state.
The driver will currently put the pins into the "sleep" state when .shutdown() is called by something (userspace or in-kernel users).
So in the new suggested scheme using runtime PM, this would have to be replaced by pm_runtime_get[_sync]() and pm_runtime_put() hints and the current pin handling deleted, and for each platform using this driver instead implement a PM domain to do the same thing.
Else you loose this runtime power optimization.
This is what I refer to the all-or-nothing charcter of runtime PM domains... but maybe it's a good thing, I haven't quite made my mind up about it.
> (...) if what we want/need are only ways to introduce SoC-specific > integration details into non-PM transitions (e.g. probe/remove), maybe > bus notifiers would suffice here. e.g. you'd get a bus notifier when > the device is added/attached and any init-time pinctrl setup could be > done then. This still keeps drivers clean of SoC-specific integration > data/code, and also allows that to happen whether or not PM features are > enabled.
It doesn't cut it for any of our drivers as shown above, but it would work for the patch in $SUBJECT.
It sounds like the way silicon clocks are handled on SH am I right?
Yours, Linus Walleij
| |