[PATCH 1/2] i2c: s3c2410: add optional pin configuration using pinctrl interface

[Linus Walleij]

On Thu, Sep 6, 2012 at 2:28 PM, Tomasz Figa <t.figa at samsung.com> wrote:
> Thanks for your comments.
>
> On Thursday 06 of September 2012 16:36:08 Thomas Abraham wrote:
>> > 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".
>
> What I suggested is that such default configuration would be applied just
> before binding a driver, i.e. when it's almost sure that the device will be
> actually used and the configuration will be needed.

In that case the pinctrl driver can poke down a default
register configuration, but just like Stephen remarks I do not see
the point either.

Hogs should work just fine?

> Of course such functionality would not have to be obligatory. For example,
> we could add new property, like pinctrl-set-default, to point in device
> tree that this device should have its pinctrl state set up automatically.

This doesn't have a semantic difference to a default hog AFAICT.

>> 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.
>
> In my opinion it should be saved and restored by pinctrl driver (as it was
> done in case of GPIO subsystem previously).

This is one way to do it. I see Stephen has the same idea.

Another way is actually to go to the default state from the
default state. Or from any state to itself rather.

Currently pinctrl_select_state_locked() contains this:

        if (p->state == state)
                return 0;

If we just add pinctrl_select_state_force() excluding that
clause we can force re-poking of the state at any time.

Compare regulator_force_disable() and similar.

Maybe this is actually more helpful?

Yours,
Linus Walleij