On 11/28/19 12:33 PM, Maxime Ripard wrote:
Hi Maxime,
Hi Stefan,
On Wed, Nov 27, 2019 at 09:07:40AM +0200, Stefan Mavrodiev wrote:
On 11/26/19 6:27 PM, Maxime Ripard wrote:
Hi Stefan,
On Tue, Nov 26, 2019 at 01:05:08PM +0200, Stefan Mavrodiev wrote:
On A64-OLinuXino boards, PG9 is used for USB1 enable/disable. The
port is supplied by DLDO4, which is disabled by default. The patch
adds the regulator as vcc-pg, which is later used by the pinctrl.
Signed-off-by: Stefan Mavrodiev <stefan@xxxxxxxxxx>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index 01a9a52edae4..c9d8c9c4ef20 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -163,6 +163,10 @@
status = "okay";
};
+&pio {
+ vcc-pg-supply=<®_dldo4>;
The equal sign should have spaces around it.
Also, can you please list all the bank supplies while you're at it?
Sure. Should the supplies defined as regulators names be added also to the
pio node?
For example reg_aldo1 is named "vcc-pe".
As far as I can tell, the A64 has regulators for PC, PD, PE, PG and
PL, so you should list those (PL being under r_pio)
After quick check I've found a bug (maybe?). It's not possible to specify
vcc-pl-supply, because of this:
https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/sunxi/pinctrl-sunxi.c#L778
During the probe of the pmu, the pinctrl tries to get a regulator, that
doesn't exist yet.
Because of this the system doesn't start (as expected).
I've tried to ignore -EPROBE_DEFER. This seems to work, but only because
the regulator for
PL is defined as "regulator-always-on". The problem is that the refcount
is not incremented.
So if you export one gpio and the unexport it, the regulator will be
disabled. I'm not sure
how this can be resolved.
Should I skip vcc-pl-supply for now and list the other bank supplies?
Stefan
Also, since the commit message will be different for better representation
of the changes, should I send the next
patch as v2 or as a new one?
Either way works for me as long as the commit message matches the changes.
Thanks!
Maxime
