Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman
[off-list ref] wrote:

[Me]

quoted

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