On Thu, Sep 6, 2012 at 2:28 PM, Tomasz Figa <t.figa@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
