On Fri, Sep 21, 2012 at 6:23 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 09/21/2012 07:16 AM, Peter Ujfalusi wrote:
pinctrl_get_select() returns with a pointer to struct pinctrl. If the platform does not have CONFIG_PINCTRL enabled it will return with NULL. If no pinctrl has been specified for the device it will return with error (-ENODEV). Neither of these cases should be considered as error. We do print out with dev_info() to notify the developer, but having pinctrl mux should not be mandatory.
Indeed - what about a platform like Tegra which has pinctrl enabled, yet doesn't specify any pinctrl configuration for any device other than the pin controller itself?
It would be fixed by calling pinctrl_provide_dummies() right?
Not that it's elegant or anything ...
What it all boils down to in the end (IMO) is whether a centralized or decentralized approach to the control handles should be used. The same problem will arise with runtime PM I think.
For example the shmobile will get and gate all it's clocks in a centralized fashion in drivers/base/power/clock_ops.c, and this doesn't work with all other systems so in other drivers you find clk_prepare/enable/disable/unprepare distributed in the drivers.
(I think someone could attempt to do the same thing with regulators with the same centralization failure, we know regulator voltages need to be switched at runtime, take an SD card and centralized regulators breaks apart immediately.)
Some time I thought the level of centralization may be dependent on actual hardware architecture, that the centralized approach would work for some. I'm not so sure anymore...
For advanced pin configuration, where we (in ux500) need to switch pins from default to sleep state at runtime to save power, it doesn't work do do it with hogs, we need to distribute it, because the pinctrl driver doesn't know when the UART wants to go to sleep (which is not always the same as when the system as a whole wants to sleep, incidentally) so in this case the decentralized approach is the only thing that works. We are now merging the same approach to our SPI driver, and plan to continue with I2C etc. We really want to relax the pins for these blocks between individual transfers, sometimes with delayed autosuspend via runtime PM to avoid jittering.
I don't know if this helps anything for this ASoC case though :-/
Yours, Linus Walleij