All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonard Crestez <leonard.crestez@nxp.com>
To: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>,
	Sascha Hauer <kernel@pengutronix.de>,
	Peter Chen <Peter.Chen@nxp.com>,
	Anson Huang <Anson.Huang@nxp.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Christoph Fritz <chf.fritz@googlemail.com>,
	Shawn Guo <shawnguo@kernel.org>
Subject: Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
Date: Wed, 3 May 2017 20:58:18 +0300	[thread overview]
Message-ID: <1493834298.11226.40.camel@nxp.com> (raw)
In-Reply-To: <e46a57c2-4a28-a8b6-445e-299dd9d8659c@denx.de>

On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> > On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> > > 2) It actually fixes a problem with the voltage rails such that the DVFS
> > >    works without leaving the system in unstable or dead state. You do
> > >    need the second part of my patch if you drop the OPP hackery, without
> > >    it the power framework cannot correctly configure the core voltages,
> > >    so the patch from Leonard makes things worse.
> > No, I think there is a misunderstanding here. The second part of your
> > patch will cause cpufreq poking at LDOs to indirectly adjust the input
> > from the PMIC to the minimum required (this is LDO target +
> > min_dropout_uv). Without it by default VDD_ARM_SOC_IN will remain fixed
> > as 1375mV from boot.

> Who sets / guarantees that default value for ARM and SOC rails ?

I think it's from the PMIC hardware itself (but maybe uboot plays with
it). VDD_ARM_SOC_IN on this board is tied to SW1AB from MMPF0200:

http://www.nxp.com/assets/documents/data/en/data-sheets/MMPF0200.pdf

It seems reasonable to rely on such voltages set externally.

> With the OPP override in place, there's at least the guarantee that both
> rails will have the same voltage requirement. If you remove the OPP
> override without modeling the actual regulator wiring, the guarantee is
> gone.

The imx6sx chip has internal LDO_ARM and LDO_SOC regulators which can
generate separate voltages for arm/soc. The fact that these regulators
share the same supply is only an issue when they are set in bypass
mode.

However the boot issues happen on REV C but apparently not REV B of the
board. I don't have a good explanation for this so maybe I am missing
something.

-- 
Regards,
Leonard

WARNING: multiple messages have this Message-ID (diff)
From: leonard.crestez@nxp.com (Leonard Crestez)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
Date: Wed, 3 May 2017 20:58:18 +0300	[thread overview]
Message-ID: <1493834298.11226.40.camel@nxp.com> (raw)
In-Reply-To: <e46a57c2-4a28-a8b6-445e-299dd9d8659c@denx.de>

On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> > On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> > > 2) It actually fixes a problem with the voltage rails such that the DVFS
> > > ???works without leaving the system in unstable or dead state. You do
> > > ???need the second part of my patch if you drop the OPP hackery, without
> > > ???it the power framework cannot correctly configure the core voltages,
> > > ???so the patch from Leonard makes things worse.
> > No, I think there is a misunderstanding here. The second part of your
> > patch will cause cpufreq poking at LDOs to indirectly adjust the input
> > from the PMIC to the minimum required (this is LDO target +
> > min_dropout_uv). Without it by default VDD_ARM_SOC_IN will remain fixed
> > as 1375mV from boot.

> Who sets / guarantees that default value for ARM and SOC rails ?

I think it's from the PMIC hardware itself (but maybe uboot plays with
it). VDD_ARM_SOC_IN on this board is tied to SW1AB from MMPF0200:

http://www.nxp.com/assets/documents/data/en/data-sheets/MMPF0200.pdf

It seems reasonable to rely on such voltages set externally.

> With the OPP override in place, there's at least the guarantee that both
> rails will have the same voltage requirement. If you remove the OPP
> override without modeling the actual regulator wiring, the guarantee is
> gone.

The imx6sx chip has internal LDO_ARM and LDO_SOC regulators which can
generate separate voltages for arm/soc. The fact that these regulators
share the same supply is only an issue when they are set in bypass
mode.

However the boot issues happen on REV C but apparently not REV B of the
board. I don't have a good explanation for this so maybe I am missing
something.

--?
Regards,
Leonard

  reply	other threads:[~2017-05-03 17:58 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-25 16:57 [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override Leonard Crestez
2017-04-25 16:57 ` Leonard Crestez
2017-04-25 16:57 ` Leonard Crestez
2017-04-25 17:02 ` Fabio Estevam
2017-04-25 17:02   ` Fabio Estevam
2017-04-25 17:02   ` Fabio Estevam
2017-04-25 17:02     ` Fabio Estevam
2017-04-25 17:23     ` Leonard Crestez
2017-04-25 17:23       ` Leonard Crestez
2017-04-25 17:26       ` Fabio Estevam
2017-04-25 17:26         ` Fabio Estevam
2017-04-25 17:28       ` Marek Vasut
2017-04-25 17:28         ` Marek Vasut
2017-04-25 17:28         ` Marek Vasut
2017-05-03 13:57         ` Shawn Guo
2017-05-03 13:57           ` Shawn Guo
2017-05-03 14:26           ` Marek Vasut
2017-05-03 14:26             ` Marek Vasut
2017-05-03 14:32             ` Marek Vasut
2017-05-03 14:32               ` Marek Vasut
2017-05-03 14:41               ` Shawn Guo
2017-05-03 14:41                 ` Shawn Guo
2017-05-03 14:51                 ` Marek Vasut
2017-05-03 14:51                   ` Marek Vasut
2017-05-03 14:58             ` Leonard Crestez
2017-05-03 14:58               ` Leonard Crestez
2017-05-03 15:59               ` Marek Vasut
2017-05-03 15:59                 ` Marek Vasut
2017-05-03 17:58                 ` Leonard Crestez [this message]
2017-05-03 17:58                   ` Leonard Crestez
2017-05-03 19:33                   ` Marek Vasut
2017-05-03 19:33                     ` Marek Vasut
2017-05-04  9:42                     ` Leonard Crestez
2017-05-04  9:42                       ` Leonard Crestez
2017-05-04 10:06                       ` Marek Vasut
2017-05-04 10:06                         ` Marek Vasut
2017-05-04 12:44                         ` Shawn Guo
2017-05-04 12:44                           ` Shawn Guo
2017-05-04 13:08                           ` Marek Vasut
2017-05-04 13:08                             ` Marek Vasut
2017-05-04 13:41                             ` Shawn Guo
2017-05-04 13:41                               ` Shawn Guo
2017-05-04 14:34                               ` Marek Vasut
2017-05-04 14:34                                 ` Marek Vasut
2017-05-04 14:34                                 ` Marek Vasut
2017-05-05  1:18                                 ` Shawn Guo
2017-05-05  1:18                                   ` Shawn Guo
2017-05-05 10:11                                   ` Leonard Crestez
2017-05-05 10:11                                     ` Leonard Crestez
2017-04-27  1:17 ` Peter Chen
2017-04-27  1:17   ` Peter Chen
2017-04-27  1:17   ` Peter Chen
2017-05-04 11:43   ` Shawn Guo
2017-05-04 11:43     ` Shawn Guo
2017-05-04 11:46     ` Fabio Estevam
2017-05-04 11:46       ` Fabio Estevam
2017-05-04 12:50 ` Shawn Guo
2017-05-04 12:50   ` Shawn Guo

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=1493834298.11226.40.camel@nxp.com \
    --to=leonard.crestez@nxp.com \
    --cc=Anson.Huang@nxp.com \
    --cc=Peter.Chen@nxp.com \
    --cc=chf.fritz@googlemail.com \
    --cc=fabio.estevam@nxp.com \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=rjw@rjwysocki.net \
    --cc=shawnguo@kernel.org \
    --cc=viresh.kumar@linaro.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.