All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Doug Anderson <dianders@chromium.org>
Cc: Andy Yan <andy.yan@rock-chips.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
Date: Mon, 19 Sep 2016 18:15:23 +0200	[thread overview]
Message-ID: <2318029.f7g774Bk76@phil> (raw)
In-Reply-To: <CAD=FV=VawAOWBF_PoXqSj3oiVgfF8SnCBp56p8F==XsaVLmMcg@mail.gmail.com>

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?


> Once you have this property you should ideally be able to read whether
> the pin is currently configured as an input or as a special function
> at bootup.  Note that I don't actually know if this is possible with
> the current pinctrl API, but it does seem like the ideal way to do it
> since it means you'll work even if the BIOS changes (AKA: if the BIOS
> leaves the pin as an input you can keep the voltage the same and if
> the BIOS leaves the pin as PWM you can keep the voltage the same).
> 
> It's also possible that you could just add a property that says "init
> to a certain value at bootup no matter what the BIOS left it as".  As
> long as that voltage is the maximum (and you'll lower it later) this
> ought to be safe and you shouldn't risk temporarily undervolting
> things.
> 
> 
> Note that, if you haven't already done so, you almost certainly want
> to make sure your pinctrl species an "init" state in addition to a
> "default" state.  See <https://patchwork.kernel.org/patch/7454311/>.
> 
> -Doug

WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
Date: Mon, 19 Sep 2016 18:15:23 +0200	[thread overview]
Message-ID: <2318029.f7g774Bk76@phil> (raw)
In-Reply-To: <CAD=FV=VawAOWBF_PoXqSj3oiVgfF8SnCBp56p8F==XsaVLmMcg@mail.gmail.com>

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?


> Once you have this property you should ideally be able to read whether
> the pin is currently configured as an input or as a special function
> at bootup.  Note that I don't actually know if this is possible with
> the current pinctrl API, but it does seem like the ideal way to do it
> since it means you'll work even if the BIOS changes (AKA: if the BIOS
> leaves the pin as an input you can keep the voltage the same and if
> the BIOS leaves the pin as PWM you can keep the voltage the same).
> 
> It's also possible that you could just add a property that says "init
> to a certain value at bootup no matter what the BIOS left it as".  As
> long as that voltage is the maximum (and you'll lower it later) this
> ought to be safe and you shouldn't risk temporarily undervolting
> things.
> 
> 
> Note that, if you haven't already done so, you almost certainly want
> to make sure your pinctrl species an "init" state in addition to a
> "default" state.  See <https://patchwork.kernel.org/patch/7454311/>.
> 
> -Doug

  reply	other threads:[~2016-09-19 16:15 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-19  8:43 [PATCH 0/1] fix rk3066a based boards boot issue on linux-4.8 Andy Yan
2016-09-19  8:43 ` Andy Yan
2016-09-19  8:44 ` [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization Andy Yan
2016-09-19  8:44   ` Andy Yan
2016-09-19  9:25   ` Boris Brezillon
2016-09-19  9:25     ` Boris Brezillon
2016-09-19  9:38     ` Andy Yan
2016-09-19  9:38       ` Andy Yan
2016-09-19  9:44       ` Boris Brezillon
2016-09-19  9:44         ` Boris Brezillon
2016-09-19  9:59         ` Andy Yan
2016-09-19 15:15   ` Doug Anderson
2016-09-19 15:15     ` Doug Anderson
2016-09-19 16:15     ` Heiko Stuebner [this message]
2016-09-19 16:15       ` Heiko Stuebner
2016-09-19 16:38       ` Doug Anderson
2016-09-19 16:38         ` Doug Anderson
2016-09-19 17:13         ` Boris Brezillon
2016-09-19 17:13           ` Boris Brezillon
2016-09-19 17:22           ` Doug Anderson
2016-09-19 17:22             ` Doug Anderson
2016-09-19 17:48             ` Boris Brezillon
2016-09-19 17:48               ` Boris Brezillon
2016-09-19 17:52               ` Doug Anderson
2016-09-19 17:52                 ` Doug Anderson
2016-09-19 18:06                 ` Boris Brezillon
2016-09-19 18:06                   ` Boris Brezillon
2016-09-19 18:12                   ` Doug Anderson
2016-09-19 18:12                     ` Doug Anderson
2016-09-19 18:31                     ` Boris Brezillon
2016-09-19 18:31                       ` Boris Brezillon
2016-09-19 20:43                     ` Boris Brezillon
2016-09-19 20:43                       ` Boris Brezillon
2016-09-19 21:15                       ` Doug Anderson
2016-09-19 21:15                         ` Doug Anderson
2016-09-22 15:12                         ` Boris Brezillon
2016-09-22 15:12                           ` Boris Brezillon
2016-09-22 16:47                           ` Mark Brown
2016-09-22 16:47                             ` Mark Brown
     [not found]                             ` <20160922164752.GP7994-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-09-22 18:13                               ` Boris Brezillon
2016-09-22 18:13                                 ` Boris Brezillon
2016-09-22 18:13                                 ` Boris Brezillon
2016-09-22 19:26                                 ` Mark Brown
2016-09-22 19:26                                   ` Mark Brown
2016-09-19 17:25           ` Heiko Stuebner
2016-09-19 17:25             ` Heiko Stuebner
2016-09-19  9:21 ` [PATCH 0/1] fix rk3066a based boards boot issue on linux-4.8 Boris Brezillon
2016-09-19  9:21   ` Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2318029.f7g774Bk76@phil \
    --to=heiko@sntech.de \
    --cc=andy.yan@rock-chips.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=dianders@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.