From: Andre Przywara <andre.przywara@arm.com>
To: Samuel Holland <samuel@sholland.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>, u-boot@lists.denx.de
Subject: Re: [PATCH v2 0/3] power: X-Powers PMIC regulator support
Date: Mon, 23 Jan 2023 01:38:32 +0000 [thread overview]
Message-ID: <20230123013832.339fbbf8@slackpad.lan> (raw)
In-Reply-To: <20230121231307.42628-1-samuel@sholland.org>
On Sat, 21 Jan 2023 17:13:03 -0600
Samuel Holland <samuel@sholland.org> wrote:
Hi Samuel,
thanks for re-spinning this!
> This series adds a driver for the regulators in X-Powers AXPxxx PMICs.
> It supports everything except regulators shared with GPIO pins. Those
> have a different register interface, so they may need a separate driver.
>
> Regulator setup in U-Boot proper is needed for Ethernet and HDMI/LCD
> display output.
So I used a BL31 with SUNXI_SETUP_REGULATORS=0 on a Pine64, and with
some tweaking of the .config, your HDMI series, my patch to parse
phy-supply in sun8i-emac.c, and some delay after that, I could get both
Ethernet and HDMI to work. So that seems to be working!
Given that this series does not enable this in any defconfig, I guess
there is little risk in merging this. We can then bring this into wider
circulation with defconfig/Kconfig patches, after a bit more testing.
I am a bit uneasy seeing this code bringing up regulators/setting
voltages that were disabled before, so my plan was to let people enable
this on their boards manually and report back whether this works, then
rolling this maybe by SoC, starting with the A64, maybe H6 (for our
beloved OPi PC 3).
> For some SoCs (H616), this driver could possibly be used
> for the DRAM regulator setup done in SPL. Older SoCs do all of their
> regulator setup in SPL. Some of that is probably necessary, but I think
> a lot of it is not and can be deferred to U-Boot proper or Linux; that's
> just where it was convenient to initialize the PMIC at the time.
I agree, it sounds quite beneficial to get rid of this ad-hoc SPL AXP
setup we do for the older SoCs, but I guess we cannot defer everything
to U-Boot proper without further rework. For instance we bump up DCDC2
on A20 to allow clocking the CPU higher, which is done in SPL, but
could also wait.
Anyway, it's indeed an optimisation for later, I guess we have bigger
fish to fry first.
> The main goal here is to replace the corresponding code in TF-A, both
> because of TF-A size constraints, and because the TF-A code is too
> simple/overzealous and breaks EPHY power sequencing on some boards.
I totally agree, and I would focus on the A64 and H6 for this reason
first.
So I merged this series, should be part of the first PR for 2023.04.
Cheers,
Andre
>
> Changes in v2:
> - Dual-license the driver
> - Add a comment about the requirements for the voltage table
> - Fix AXP22x ALDO3 enable bit position
>
> Samuel Holland (3):
> power: pmic: axp: Provide a variant ID in the driver data
> power: regulator: Add a driver for AXP PMIC regulators
> power: pmic: axp: Bind regulators from the DT
>
> drivers/power/pmic/axp.c | 36 ++-
> drivers/power/regulator/Kconfig | 14 ++
> drivers/power/regulator/Makefile | 1 +
> drivers/power/regulator/axp_regulator.c | 312 ++++++++++++++++++++++++
> include/axp_pmic.h | 12 +
> 5 files changed, 366 insertions(+), 9 deletions(-)
> create mode 100644 drivers/power/regulator/axp_regulator.c
>
prev parent reply other threads:[~2023-01-23 1:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 23:13 [PATCH v2 0/3] power: X-Powers PMIC regulator support Samuel Holland
2023-01-21 23:13 ` [PATCH v2 1/3] power: pmic: axp: Provide a variant ID in the driver data Samuel Holland
2023-01-21 23:13 ` [PATCH v2 2/3] power: regulator: Add a driver for AXP PMIC regulators Samuel Holland
2023-01-22 0:10 ` Andre Przywara
2023-01-23 18:49 ` Simon Glass
2023-01-23 19:54 ` Andre Przywara
2023-01-21 23:13 ` [PATCH v2 3/3] power: pmic: axp: Bind regulators from the DT Samuel Holland
2023-01-22 17:39 ` Andre Przywara
2023-01-23 1:38 ` Andre Przywara [this message]
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=20230123013832.339fbbf8@slackpad.lan \
--to=andre.przywara@arm.com \
--cc=jh80.chung@samsung.com \
--cc=samuel@sholland.org \
--cc=u-boot@lists.denx.de \
/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