[alsa-devel] [PATCH] ASoC: core: Configure pin muxing via pinctrl when registering a DAI
Linus Walleij
linus.walleij at linaro.org
Mon Sep 24 11:20:16 CEST 2012
On Sun, Sep 23, 2012 at 5:23 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> I think the errors shouldn't be ignored at all; it's an error for a
> driver to explicitly go out and request a pinctrl state if that state is
> not defined. In turn, this means that no generic code should be going
> out and requesting a pinctrl state on behalf of the driver; it has no
> idea if the driver has defined that it needs pinctrl set up for it.
This makes perfect sense to me, right now atleast.
So the problem with the patch we're discussing is that it's
"too far up" in the framework, and handling pinctrl should be done
somewhere below.
> For any pinctrl configuration that is static, that configuration should
> be applied one time as the system boots using the "hog" feature of the
> pin controller itself,
Agreed. Even in the docs luckily :-)
> i.e. the pin controller driver should apply that
> state during its own probe(). Individual drivers should only ever
> request a pinctrl state if they need to dynamically switch between
> different states at run-time. This is (a) likely to be fairly rare,
The Ux500 smash this completely by having almost no static
configurations at all and needing to switch everything at runtime,
tied in with runtime PM. This is how we save some microamps.
Sorry for this, I'm happy for you if Tegra is simpler to handle for
low-power :-)
> and
> (b) the need is likely to be defined directly by the kind of protocol
> that the driver/HW is implementing.
Yes. This is 100% true. It needs to be close to the driver and
its subsystem. (I don't know if the patch under disussion is at
the right level, seems controversial...)
> So in other words, I'd expect to see an almost complete system-wide
> "default" pinctrl state defined for the pin controller, and quite
> possibly no other drivers with pinctrl states defined at all.
Hehe not for us :-)
Yours,
Linus Walleij
More information about the Alsa-devel
mailing list