On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
