All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonard Crestez <leonard.crestez@nxp.com>
To: Marek Vasut <marex@denx.de>
Cc: 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>,
	Christoph Fritz <chf.fritz@googlemail.com>,
	Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
Date: Thu, 4 May 2017 12:42:23 +0300	[thread overview]
Message-ID: <1493890943.11226.42.camel@nxp.com> (raw)
In-Reply-To: <51fb1bd0-028d-c431-acc8-3c4f1d25fdba@denx.de>

On Wed, 2017-05-03 at 21:33 +0200, Marek Vasut wrote:
> On 05/03/2017 07:58 PM, Leonard Crestez wrote:
> > 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.

> Isn't it an established rule that Linux should not depend on bootloader
> settings ? Or did that change ?

I don't actually know. Is there a hard and fast rule about this, even when it comes to voltages?

In theory it is possible for a bootloader to set a low cpu frequency and low voltage and then have the chip fail when the cpufreq driver attempts to go higher. Setting vin-supply on reg_arm/reg_soc would fix that.

> Well the regulator(s) cannot be correctly configured if the kernel
> doesn't have the correct power distribution described in the DT .

It depends on your definition of "correctness". It it certainly
possible to get a functional system while only partially describing
regulator relationships.

I think there is a further misunderstanding here. I have a problem
where imx6sx-sdb rev C boards crash on boot with upstream (but are
reported to work fine with rev B). Removing the OPP overrides fixes
this specific issue.

I don't object to the second part of your patch, setting correct supply links is a good thing for various reasons. It is just not necessary for fixing the concrete crash mentioned above (and I tested this). It should probably go in a separate patch.

It might seem a pedantic difference but it's good to accurately describe the effect of patches in commit messages. For example it might help somebody looking to backport various fixes.

--
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: Thu, 4 May 2017 12:42:23 +0300	[thread overview]
Message-ID: <1493890943.11226.42.camel@nxp.com> (raw)
In-Reply-To: <51fb1bd0-028d-c431-acc8-3c4f1d25fdba@denx.de>

On Wed, 2017-05-03 at 21:33 +0200, Marek Vasut wrote:
> On 05/03/2017 07:58 PM, Leonard Crestez wrote:
> > 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.

> Isn't it an established rule that Linux should not depend on bootloader
> settings ? Or did that change ?

I don't actually know. Is there a hard and fast rule about this, even when it comes to voltages?

In theory it is possible for a bootloader to set a low cpu frequency and low voltage and then have the chip fail when the cpufreq driver attempts to go higher. Setting vin-supply on reg_arm/reg_soc would fix that.

> Well the regulator(s) cannot be correctly configured if the kernel
> doesn't have the correct power distribution described in the DT .

It depends on your definition of "correctness". It it certainly
possible to get a functional system while only partially describing
regulator relationships.

I think there is a further misunderstanding here. I have a problem
where imx6sx-sdb rev C boards crash on boot with upstream (but are
reported to work fine with rev B). Removing the OPP overrides fixes
this specific issue.

I don't object to the second part of your patch, setting correct supply links is a good thing for various reasons. It is just not necessary for fixing the concrete crash mentioned above (and I tested this). It should probably go in a separate patch.

It might seem a pedantic difference but it's good to accurately describe the effect of patches in commit messages. For example it might help somebody looking to backport various fixes.

--
Regards,
Leonard

  reply	other threads:[~2017-05-04  9:42 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
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 [this message]
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=1493890943.11226.42.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.