lkml.org 
[lkml]   [2017]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force a state
* Florian Fainelli <f.fainelli@gmail.com> [171129 17:37]:
> On 11/29/2017 09:01 AM, Tony Lindgren wrote:
> > * Florian Fainelli <f.fainelli@gmail.com> [171102 23:18]:
> >> It may happen that a device needs to force applying a state, e.g:
> >> because it only defines one state of pin states (default) but loses
> >> power/register contents when entering low power modes. Add a
> >> pinctrl_dev::flags bitmask to help describe future quirks and define
> >> PINCTRL_FLG_FORCE_STATE as such a settable flag.
> >
> > It makes sense to tag the existing state with the context loss
> > information as otherwise we'll be duplicating the state in the
> > pinctrl driver potentially for hundreds of pins.
> >
> > Maybe this patch description should clarify that it's the
> > pinctrl device restoring the pin state, not the pinctrl
> > consumer devices?
> >
> > So maybe just "a pinctrl device needs to force apply a state"
> > instead of just device above?
>
> It's a bit more involved than that, the pinctrl consumer device might
> want to restore a particular state by calling pinctrl_select_state(),
> however, because of the (p->state == state)check, the pinctrl provider
> driver has no chance of making that call do the actual HW programming.

Hmm but isn't it the pinctrl provider device losing context here?
I think the restore of the pin state should somehow happen automatically
by the pinctrl provider driver without a need for the pinctrl consumer
drivers to do anything.

Or what's the use case for pinctrl consumer driver wanting to store
a pin?

Regards,

Tony

\
 
 \ /
  Last update: 2017-11-29 18:45    [W:0.100 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site