Re: [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization

[Boris Brezillon]

On Mon, 19 Sep 2016 11:12:12 -0700
Doug Anderson <dianders@xxxxxxxxxxxx> wrote:

> Hi,
> 
> On Mon, Sep 19, 2016 at 11:06 AM, Boris Brezillon
> <boris.brezillon@xxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, 19 Sep 2016 10:52:51 -0700
> > Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> >  
> >> Hi,
> >>
> >> On Mon, Sep 19, 2016 at 10:48 AM, Boris Brezillon
> >> <boris.brezillon@xxxxxxxxxxxxxxxxxx> wrote:  
> >> > The PWM chip has always claimed the pins and muxed them to the PWM IP.
> >> > So, this means it's broken from the beginning, and my patch is only
> >> > uncovering the problem (unless the pins stay configured as input until
> >> > the PWM is enabled, which I'm not sure is the case).  
> >>
> >> Such a solution is achievable with the pinctrl APIs pretty easily.
> >> You might not be able to use the automatic "init" state but you can do
> >> something similar and switch to an "active" state once the PWM is
> >> actually turned on the first time.  
> >
> > But is it really the case here (I don't see any code requesting a
> > specific pinmux depending on the PWM state)?  
> 
> It is not happening right now as far as I know.  ...but that's a bug.
> 
> > Anyway, we really need to handle this case, we should define the
> > typical voltage when the PWM is disabled. Same as what you suggested
> > with voltage-when-input, but with a different naming (since the concept
> > of pinmux is PWM hardware/driver specific).
> >
> >         voltage-when-pwm-disabled = <...>;  
> 
> Voltage when disabled and voltage when input are two different states.
> A disabled PWM will typically either drive high or low (depending on
> where it was when you turned it off).  Not all "disabled" states will
> mean that the pin is configured as an input.

Okay, after reading again your first answer, I think I understand why
you want to differentiate the when-disabled and when-input cases. You
want to use the "init" and "default" pinctrl states. The "init" state
(applied at probe time) would keep the PWM pin in gpio+input mode and
the "default" state (applied when the PWM device is enabled for the
first time) would mux the pin to the PWM device.
Your solution requires that the pwm-regulator device knows in which
state the pin attached to the PWM is, which IMO is breaking the
layering we have right now: a PWM-regulator is assigned a PWM device
which is assigned a pin and a pinmux config.
Another solution would be to expose an additional information in the
pwm_state: whether the PWM is in the INIT state (probed, but not yet
configured by its user) or DEFAULT state (probed and already
configured by its user). But again, by doing that we also expose
internal PWM details to its user, which I'm not sure will help keep
the PWM API simple.

Actually, I had something slightly different in mind. I thought about
having two new pinctrl states ("enabled" and "disabled"). The "enabled"
state (pin muxed to the PWM device) would be applied each time the PWM
is enabled, and "disabled" state (gpio+input mode) would be applied each
time the PWM is disabled.
This way we can guarantee that even when the PWM is disabled, the
PWM-driven regulator is configured to output a non-destructive voltage.
Hence my suggestion to name the property 'voltage-when-pwm-disabled'.