On Sun, Sep 23, 2012 at 5:23 AM, Stephen Warren swarren@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