[alsa-devel] [PATCH] ASoC: core: Configure pin muxing via pinctrl when registering a DAI

Linus Walleij linus.walleij at linaro.org
Tue Sep 25 13:56:13 CEST 2012


On Tue, Sep 25, 2012 at 1:43 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Tue, Sep 25, 2012 at 02:24:23PM +0300, Peter Ujfalusi wrote:
>>
>> For this to work it would be ideal to use the pm_runtime as a centralized
>> place to handle clocks, pinctrl, etc...
>> But again, what to do with the cases when this is not needed (the pinctrl part
>> for the devices)?
>
> It's also not massively clear to me that generic pm_runtime code is a
> good place to put all this stuff - it's too coarse grained for a lot of
> things.

I tend to agree. If you think of things like the clock handling in
drivers/base/power/clock_ops.c that shmobile is relying upon.
This is just not working with our platforms because different
drivers need different semantics.

In ux500 drivers we use *specific* (as opposed to generic) runtime PM
code to e.g. get some hysteresis before a drivers clock and pins
(etc) are put to sleep. Pure driver business.

So these are runtime suspend/resume calls in the driver itself.

>  Devices that can be wake sources are an example here, if they
> are doing that then turning them completely off may break functionality
> but you can still turn some of the device (possibly a varying selection
> depending on usage) off.  For simple cases it works well and it'd be
> good to have it but you end up back into ignoring errors...

Our ux500 "sleep" state on the pins will put them into the apropriate
wakeup mode where applicable. Since this may vary across boards
it's even machine-specific.

Configuring wakeup sources when going to a state named "sleep"
seems intuitive to me atleast.

Then we have this (currently unused) "idle" state, which is intended
as a power-saving state without going to sleep. So this is for the
case when the system needs to be relaxed on power but not
yet put to sleep. On some systems and for some drivers this
state and the "sleep" state will likely be the same, but I'm
just philosophizing here.

These are just defined as strings in
include/linux/pinctrl/pinctrl-state.h
with some kind of semantics.

The pinctrl handle can be moved into any state at any time,
it's not like it's a state machine or something, so the subsystems
and drivers need to know what they are doing.

Yours,
Linus Walleij


More information about the Alsa-devel mailing list