lkml.org 
[lkml]   [2016]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
On Mon, 19 Sep 2016 09:38:34 -0700
Doug Anderson <dianders@chromium.org> wrote:

> Hi,
>
> On Mon, Sep 19, 2016 at 9:15 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> > Am Montag, 19. September 2016, 08:15:30 CEST schrieb Doug Anderson:
> >> Hi,
> >>
> >> On Mon, Sep 19, 2016 at 1:44 AM, Andy Yan <andy.yan@rock-chips.com> wrote:
> >> > The current rk3066a based boards(Rayeager, Bqcurie2, Marsboard) use
> >> > pwm modulate vdd_logic voltage, but the pwm is default disabled and
> >> > the pwm pin acts as a gpio before pwm regulator probed, so the pwm
> >> > regulator driver will get a zero dutycycle at probe time, so change
> >> > the initial dutycycle to zero to match pwm_regulator_init_state check.
> >> >
> >> > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> >> >
> >> > ---
> >> >
> >> > arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 +-
> >> > arch/arm/boot/dts/rk3066a-marsboard.dts | 2 +-
> >> > arch/arm/boot/dts/rk3066a-rayeager.dts | 2 +-
> >> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> >> > b/arch/arm/boot/dts/rk3066a-bqcurie2.dts index bc674ee..618450d 100644
> >> > --- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> >> > +++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> >> > @@ -61,7 +61,7 @@
> >> >
> >> > regulator-min-microvolt = <1200000>;
> >> > regulator-max-microvolt = <1200000>;
> >> > regulator-always-on;
> >> >
> >> > - voltage-table = <1000000 100>,
> >> > + voltage-table = <1000000 0>,
> >>
> >> In my opinion this isn't quite the right answer. I think that you
> >> should add a new property describing the voltage in the case that the
> >> pin is an input and you should fill that property in, like:
> >>
> >> voltage-when-input = <1000000>;
> >
> > I'd think this would be more of a pwm issue, not something the pwm-regulator
> > should need to care about.
> >
> > Ideally the pwm driver should be able to return some state information even if
> > disabled? I.e. deriving a duty-cycle value from its pin state similar to what
> > Doug described below (it's either 0% or 100%)
> >
> > But right now I have a hard time understanding how the pwm could return any
> > duty-cycle information for an input gpio to the pwm-regulator, as I assume the
> > pwm-driver has to probe (and thus set pinctrl to the pwm function) before the
> > pwm-regulator is able to get the pwm handle?
>
> Hrm, right. The PWM ought to own the pinctrl, not the regulator.
> Hrm. Then I guess this gets more complicated.
>
> One thing to point out, though, is that an EE I talked to said that
> the "voltage when input" is actually a well defined property and is
> unrelated to the min/max voltage. AKA: it's not guaranteed to be
> equal to the 50% duty cycle. ...so adding a property to the PWM
> regulator that includes this value is something very sane. The
> "voltage when input" is defined by the pile of resistors and
> capacitors that are used to actually make the PWM control the
> regulator.
>
> The "voltage when input" is super important because this is the
> voltage that's used at bootup (when all pins are configured as inputs,
> possible with a pull applied) and that's used during suspend time when
> the PWM stops.

Correct me if I'm wrong, but the main problem here is that, when we try
to detect the initial regulator state, we ran into a "missing entry in
the duty-cycle <-> voltage table" error, which then triggers an -EINVAL
error preventing the PWM regulator probe to succeed.

Of course, adding an entry for the 0% dutycle case would solve the
issue, but I wonder if we should not allow "unknown value" at probe
time, and let the regulator user set the voltage output when it claims
it.

Another option would be to fake a valid value in this case (choose the
closest entry in the voltage table?).

\
 
 \ /
  Last update: 2016-09-19 19:14    [W:0.074 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site