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

[Linus Walleij]

On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman
<khilman at 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