On 09/06/2012 05:06 AM, Thomas Abraham wrote:

On 6 September 2012 15:04, Tomasz Figa [off-list ref] wrote:

quoted

Hi,

This patch shows the problem of the need to explicitly migrate all drivers
to pinctrl.

Maybe we should consider extending the pinctrl subsystem to set the default
state automatically before binding a driver to a device, at least in case
of DT-based platforms?

The pinctrl driver allows for activating default pin configuration
when the pinctrl driver loads. This is referred to as "hogging". But
should hog be used or not is something that needs to be decided. Some
of the factors which favor the driver explicitly setting up the pin
configuration are

1. After a suspend and resume cycle, the pin configuration registers
may be reset to default values. Hence, during resume, the pin
configuration has be redone.

I'd think it's the pinctrl driver's responsibility to make hogging work
correctly across suspend/resume.

2. Runtime muxing/config is possible.

The "client" driver would definitely have to be involved there, I agree.

3. Setting some of the config options such as pull-up by default might
start consuming power from boot time itself, which could be avoided if
such setup is done only when needed.

Well, the difference in time between "just before driver binding" and
"during probe" is minimal. If the driver/HW really needs to explicitly
differentiate between those states to save power, I'd assert that it's
covered by case (2) above.

Adding pinctrl driver support in device drivers seems to be simple
task. And it is just one time effort which can be reused on multiple
SoC's.

quoted

This would be similar to what is done currently with samsung-gpio bindings
- the pin is being configured by custom xlate callback based on additional
cells in GPIO specifier, when the driver retrieves the pin using
of_get{_named,}_gpio without the need of setting it up in the driver.

The Samsung gpio dt bindings was just a bootstrap method to get device
tree support going for Samsung platforms. The gpio xlate callback was
used as a back door to setup the pinmux/pinconfig due to lack of
generic driver interface to setup the pinmux/pinconfig for Samsung
platforms. From a linux perspective, gpio and pinmux/pinconfig are
separate entities. So using gpio xlate to setup pinmux/pinconfig was
not correct but helped getting device tree enabled for Samsung
platforms. With the pinctrl framework available now, there are generic
interfaces to setup gpio and pinmux /pinconfig.

I agree; the Samsung GPIO bindings were surprising to me when I first
realized what was in the GPIO specifiers...