From: Leonard Crestez <leonard.crestez@nxp.com>
To: Shawn Guo <shawnguo@kernel.org>, 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>,
Sascha Hauer <kernel@pengutronix.de>,
Fabio Estevam <fabio.estevam@nxp.com>,
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: Fri, 5 May 2017 13:11:05 +0300 [thread overview]
Message-ID: <1493979065.3591.26.camel@nxp.com> (raw)
In-Reply-To: <20170505011834.GS18578@dragon>
On Fri, 2017-05-05 at 09:18 +0800, Shawn Guo wrote:
> On Thu, May 04, 2017 at 04:34:14PM +0200, Marek Vasut wrote:
> > If you model the
> > power distribution correctly, the OPP hackery can be removed.
> The OPP hackery can be removed even without reg_arm/reg_soc modeling.
> That's why we can do hackery dropping and reg_arm/reg_soc modeling in
> separate patches.
>
> @Leonard, if someday we support 'LDO bypass' mode in upstream kernel,
> the OPP hackery needs to be back in some way even with reg_arm/reg_soc
> modeling in place, right? Or will we have a better way to ensure SW1A
> rail can always feed a correct voltage directly to reg_arm®_soc?
Maybe? Or maybe the cpufreq driver could detect this situation and
handle it internally. In the vendor tree this the cpufreq driver has a
special fsl,arm-soc-shared property for this anyway.
I posted another RFC at upstreaming ldo-bypass recently but it did not
handle this particular case of a shared input rail. It can be handled
separately.
See: https://lkml.org/lkml/2017/3/22/640
But getting that series to an acceptable state might take a long time.
--
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: Fri, 5 May 2017 13:11:05 +0300 [thread overview]
Message-ID: <1493979065.3591.26.camel@nxp.com> (raw)
In-Reply-To: <20170505011834.GS18578@dragon>
On Fri, 2017-05-05 at 09:18 +0800, Shawn Guo wrote:
> On Thu, May 04, 2017 at 04:34:14PM +0200, Marek Vasut wrote:
> > If you model the
> > power distribution correctly, the OPP hackery can be removed.
> The OPP hackery can be removed even without reg_arm/reg_soc modeling.
> That's why we can do hackery dropping and reg_arm/reg_soc modeling in
> separate patches.
>
> @Leonard, if someday we support 'LDO bypass' mode in upstream kernel,
> the OPP hackery needs to be back in some way even with reg_arm/reg_soc
> modeling in place, right???Or will we have a better way to ensure SW1A
> rail can always feed a correct voltage directly to reg_arm?_soc?
Maybe? Or maybe the cpufreq driver could detect this situation and
handle it internally. In the vendor tree this the cpufreq driver has a
special fsl,arm-soc-shared property for this anyway.
I posted another RFC at upstreaming ldo-bypass recently but it did not
handle this particular case of a shared input rail. It can be handled
separately.
See:?https://lkml.org/lkml/2017/3/22/640
But getting that series to an acceptable state might take a long time.
--?
Regards,
Leonard
next prev parent reply other threads:[~2017-05-05 10:11 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
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 [this message]
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=1493979065.3591.26.camel@nxp.com \
--to=leonard.crestez@nxp.com \
--cc=Anson.Huang@nxp.com \
--cc=Peter.Chen@nxp.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.