From: Leonard Crestez <leonard.crestez@nxp.com>
To: Mark Brown <broonie@kernel.org>, Sascha Hauer <kernel@pengutronix.de>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Shawn Guo" <shawnguo@kernel.org>,
Robin Gong <yibin.gong@nxp.com>,
Anson Huang <Anson.Huang@nxp.com>,
Irina Tirdea <irina.tirdea@nxp.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Fabio Estevam <fabio.estevam@nxp.com>,
Octavian Purdila <octavian.purdila@nxp.com>,
<linux-pm@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 4/8] regulator: core: Check enabling bypass respects constraints
Date: Tue, 28 Mar 2017 15:39:41 +0300 [thread overview]
Message-ID: <1490704781.3546.57.camel@nxp.com> (raw)
In-Reply-To: <20170324125212.vikgekqxsnu7htzl@sirena.org.uk>
On Fri, 2017-03-24 at 12:52 +0000, Mark Brown wrote:
> On Wed, Mar 22, 2017 at 06:53:06PM +0200, Leonard Crestez wrote:
>
> >
> > Enabling bypass mode makes a regulator passthrough the supply voltage
> > directly. It is possible that the supply voltage is set high enough that
> > it violates machine constraints so let's check for that.
> >
> > The supply voltage might be higher because of min_dropout_uV or maybe
> > there is just an unrelated consumer who requested a higher voltage.
> I would expect that if bypass is enabled then the constraints on the
> parent regulator would be set appropriately to support this, I wouldn't
> expect that we'd try to apply the operating constraints of the regulator
> to the supply. Usually bypass is used for low power retention modes
> with different settings to those used in normal operation that wouldn't
> be desired in normal operation, if we were going to have constraints for
> this I'd expect a separate set used during bypass.
In this particular case it's not possible to set constraints on the parent
regulator so that both ldo-enable and ldo-bypass modes work. The maximum allowed
voltage for ldo-bypass is lower than the minimum required to support the chip at
max frequency wit ldo-enable.
It would be possible to also change the constraint values on the PMIC together
with ldo-bypass in the .dts files but that seems awful.
I'm not sure I understand why you are against applying constraints to the parent
when in bypass mode, it seems like the obvious thing to do if you want to
support flexible configuration. The check I introduced is probably not enough to
cover all cases, for example it would still be possible to explicitly change
parent voltage afterwards.
A regulator_dev registers a consumer for the supply. Right now this is being
used to propagate minimum voltages upwards since commit fc42112c0eaa ("Propagate
voltage changes to supply regulators"). It seems to me like it would be
reasonable to also use it to propagate maximum voltage from constraints, right?
Instead of asking for [best_uV + min_dropout_uV, INT_MAX] it could instead ask
for [min_uV + bypass ? min_dropout_uV : 0, min(max_uV, constraints->max_uV)].
The _regulator_do_set_voltage call on the supply can deal with stuff like
mapping it to a selector, just like it does for regulator consumers.
If more elaborate constraints are required instead of this simple behavior it
could be handled by adding an interface for drivers to expose explicit dynamic
min/max constraints.
--
Regards,
Leonard
next prev parent reply other threads:[~2017-03-28 13:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 16:53 [RFC 0/8] ARM: imx: Upstream fsl,ldo-bypass Leonard Crestez
2017-03-22 16:53 ` [RFC 1/8] ARM: imx: gpc: Do not print error message for EPROBE_DEFER Leonard Crestez
2017-03-22 16:53 ` [RFC 2/8] cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator Leonard Crestez
2017-03-23 4:33 ` Viresh Kumar
2017-03-22 16:53 ` [RFC 3/8] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend Leonard Crestez
2017-03-23 4:34 ` Viresh Kumar
2017-03-28 20:03 ` Leonard Crestez
2017-03-28 20:50 ` Rafael J. Wysocki
2017-03-28 22:23 ` Rafael J. Wysocki
2017-03-22 16:53 ` [RFC 4/8] regulator: core: Check enabling bypass respects constraints Leonard Crestez
2017-03-24 12:52 ` Mark Brown
2017-03-28 12:39 ` Leonard Crestez [this message]
2017-03-28 16:47 ` Mark Brown
2017-03-28 19:49 ` Leonard Crestez
2017-04-06 18:52 ` Mark Brown
2017-04-07 10:51 ` Leonard Crestez
2017-04-07 11:22 ` Mark Brown
2017-04-13 20:46 ` Leonard Crestez
2017-03-22 16:53 ` [RFC 5/8] regulator: anatop: fix min dropout for bypass mode Leonard Crestez
2017-03-24 12:54 ` Mark Brown
2017-03-28 11:52 ` Leonard Crestez
2017-03-22 16:53 ` [RFC 6/8] regulator: core: Add regulator_is_bypass function Leonard Crestez
2017-03-24 12:55 ` Mark Brown
2017-03-28 14:53 ` Leonard Crestez
2017-03-22 16:53 ` [RFC 7/8] cpufreq: imx6q: Initialize LDO bypass Leonard Crestez
2017-03-22 17:09 ` Lucas Stach
2017-03-22 17:48 ` Leonard Crestez
2017-03-22 18:00 ` Lucas Stach
2017-03-22 16:53 ` [RFC 8/8] ARM: dts: imx6qdl-sabresd: Enable fsl,ldo-bypass Leonard Crestez
2017-03-22 17:13 ` Lucas Stach
2017-03-29 13:32 ` Leonard Crestez
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=1490704781.3546.57.camel@nxp.com \
--to=leonard.crestez@nxp.com \
--cc=Anson.Huang@nxp.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=irina.tirdea@nxp.com \
--cc=kernel@pengutronix.de \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=octavian.purdila@nxp.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=shawnguo@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=yibin.gong@nxp.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox