From: Leonard Crestez <leonard.crestez-3arQi8VN3Tc@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Viresh Kumar
<viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Leonard Crestez <leonard.crestez-3arQi8VN3Tc@public.gmane.org>,
Robin Gong <yibin.gong-3arQi8VN3Tc@public.gmane.org>,
Anson Huang <Anson.Huang-3arQi8VN3Tc@public.gmane.org>,
Irina Tirdea <irina.tirdea-3arQi8VN3Tc@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>,
Octavian Purdila <octavian.purdila-3arQi8VN3Tc@public.gmane.org>,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [RFC 0/8] ARM: imx: Upstream fsl,ldo-bypass
Date: Wed, 22 Mar 2017 18:53:02 +0200 [thread overview]
Message-ID: <cover.1490199005.git.leonard.crestez@nxp.com> (raw)
Freescale imx socs have three built-in regulators LDO_ARM LDO_SOC and LDO_PU
used to control internal chip voltages. "ldo-bypass" mode refers to placing
these regulators in bypass mode and controlling voltages from an external power
management chip instead. The intention is to save power (at the expense of an
extra PMIC on the board).
Looking through commit messages and emails it seems that there are other users
of unusual power configurations for imx but there doesn't appear to be any
board dts file using this mode. This is an attempt to upstream this feature
based on how the freescale BSP does it. This series only enables it for the
imx6qdl-sabresd boards for simplicity.
Versions of u-boot shipped by freescale for imx partially handle this in the
bootloader. His patch series tries to detect if the bootloader did this and
takes advantage of it but it is not required. This series works fine with
upstream u-boot. The binding is odd because it's shared with those versions of
uboot.
The LDO regulators have a minimum dropout of 125mv and this is removed when
bypass mode is entered. This results in a brief increase in voltage. The bypass
code sets the minimum frequency before enabling LDO bypass to avoid
overvolting. Some new checks are added in the regulator core to check for this
(patch 4) and the checks would trigger without lowering the frequency.
Issues that need to be discussed:
* I'm not happy with the regulator_allow_bypass API. It claims to "allow the
regulator to go into bypass mode if all other consumers for the regulator also
enable bypass mode" but it doesn't seem to properly handle the case when
additional consumers show up after bypass mode is enabled. It's not even clear
how it should be done, should regulator_get on a bypassed regulator disable
bypass mode?
There are only 2 other users of this and they don't seem to use multiple
consumers. For imx the gpc driver is a secondary consumer for vddpu so this
needs to be handled somehow. There is a hack in patch 7 which forces gpc to
always probe after cpufreq and rely on it to perform the bypass procedure.
Having both gpc and cpufreq call regulator_allow_bypass would sort of work but
it would be ugly. If gpc probes first it would attempt bypass and get an error
(because of the supply voltage check), bypass would later be performed
successfully by cpufreq.
I think it would be better to have an imperative regulator_set_bypass API. I
think it might even be reasonable for it to completely replace the current
regulator_allow_bypass API.
It would also make the code a lot simpler, there would no longer be a need to
check regulator_is_bypass after regulator_allow_bypass.
* There is an anatop patch which dynamically modifies regulator_desc to
zero-out "min_dropout_uV" in bypass mode, despite the fact that documentation
claims that regulator_desc should be read-only. Perhaps the core should handle
this or this should be replaced with a function in regulator_ops?
Irina Tirdea (2):
cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator
regulator: anatop: fix min dropout for bypass mode
Leonard Crestez (6):
ARM: imx: gpc: Do not print error message for EPROBE_DEFER
cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend
regulator: core: Check enabling bypass respects constraints
regulator: core: Add regulator_is_bypass function
cpufreq: imx6q: Initialize LDO bypass
ARM: dts: imx6qdl-sabresd: Enable fsl,ldo-bypass
.../devicetree/bindings/power/fsl,imx-gpc.txt | 4 +
arch/arm/boot/dts/imx6dl-sabresd-ldo.dts | 13 ++
arch/arm/boot/dts/imx6q-sabresd-ldo.dts | 13 ++
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 19 +++
arch/arm/boot/dts/imx6qdl.dtsi | 6 +-
arch/arm/boot/dts/imx6qp-sabresd-ldo.dts | 13 ++
arch/arm/boot/dts/imx6qp-sabresd.dts | 4 +-
arch/arm/mach-imx/gpc.c | 13 +-
drivers/cpufreq/imx6q-cpufreq.c | 180 +++++++++++++++++++++
drivers/regulator/anatop-regulator.c | 9 +-
drivers/regulator/core.c | 78 ++++++++-
include/linux/regulator/consumer.h | 1 +
12 files changed, 344 insertions(+), 9 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6dl-sabresd-ldo.dts
create mode 100644 arch/arm/boot/dts/imx6q-sabresd-ldo.dts
create mode 100644 arch/arm/boot/dts/imx6qp-sabresd-ldo.dts
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2017-03-22 16:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 16:53 Leonard Crestez [this message]
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
[not found] ` <7f2618363d43b30db29f5f8ae822df413392f99d.1490199005.git.leonard.crestez-3arQi8VN3Tc@public.gmane.org>
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
[not found] ` <1edff9bc610969b0c53fa1080d5db021c8e00b2d.1490199005.git.leonard.crestez-3arQi8VN3Tc@public.gmane.org>
2017-03-24 12:52 ` Mark Brown
2017-03-28 12:39 ` Leonard Crestez
[not found] ` <1490704781.3546.57.camel-3arQi8VN3Tc@public.gmane.org>
2017-03-28 16:47 ` Mark Brown
2017-03-28 19:49 ` Leonard Crestez
[not found] ` <1490730595.15830.1.camel-3arQi8VN3Tc@public.gmane.org>
2017-04-06 18:52 ` Mark Brown
[not found] ` <20170406185202.uixxcv3dgucrddgc-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2017-04-07 10:51 ` Leonard Crestez
2017-04-07 11:22 ` Mark Brown
[not found] ` <20170407112212.gzv3p7ldkh62657m-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
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
[not found] ` <e74c2f4d2b452cbe01aa2a48edde5c024212ffcb.1490199005.git.leonard.crestez-3arQi8VN3Tc@public.gmane.org>
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
[not found] ` <1490202585.29056.5.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
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
[not found] ` <1490202830.29056.8.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
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=cover.1490199005.git.leonard.crestez@nxp.com \
--to=leonard.crestez-3arqi8vn3tc@public.gmane.org \
--cc=Anson.Huang-3arQi8VN3Tc@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=fabio.estevam-3arQi8VN3Tc@public.gmane.org \
--cc=irina.tirdea-3arQi8VN3Tc@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=octavian.purdila-3arQi8VN3Tc@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=yibin.gong-3arQi8VN3Tc@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).