[PATCH 1/2] i2c: s3c2410: add optional pin configuration using pinctrl interface
linus.walleij at linaro.org
Mon Sep 10 15:55:32 EDT 2012
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)
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?
More information about the linux-arm-kernel