[PATCH 1/5] arm64: allwinner: a64: enable AXP803 regulators for Pine64

Discussion:

Icenowy Zheng

2017-07-19 16:10:15 UTC

Add support of AXP803 regulators in the Pine64 device tree.

The phy-supply regulator is also set in EMAC device node, in order to
prevent Ethernet regression by regulator get disabled by regulator
framework.

Signed-off-by: Icenowy Zheng <***@aosc.io>
---
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 96 ++++++++++++++++++++++
1 file changed, 96 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 64cce0d68cae..ac31c9477b25 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -83,6 +83,7 @@
pinctrl-0 = <&rmii_pins>;
phy-mode = "rmii";
phy-handle = <&ext_rmii_phy1>;
+ phy-supply = <&reg_dc1sw>;
status = "okay";

};
@@ -134,6 +135,101 @@
};
};

+#include "axp803.dtsi"
+
+&reg_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pl";
+};
+
+&reg_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dc1sw {
+ regulator-name = "vcc-phy";
+};
+
+&reg_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+/*
+ * The DRAM chips used by Pine64 boards are DDR3L-compatible, so they can
+ * work at 1.35V with less power consumption.
+ * As AXP803 DCDC5 cannot reach 1.35V accurately, use 1.36V instead.
+ */
+&reg_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1360000>;
+ regulator-max-microvolt = <1360000>;
+ regulator-name = "vcc-dram";
+};
+
+&reg_dcdc6 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-sys";
+};
+
+&reg_dldo1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-hdmi";
+};
+
+&reg_dldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-mipi";
+};
+
+&reg_dldo4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi";
+};
+
+&reg_eldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "cpvdd";
+};
+
+/*
+ * The A64 chip cannot work without this regulator off, although
+ * it seems to be only driving the AR100 core.
+ * Maybe we don't still know well about CPUs domain.
+ */
+&reg_fldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-cpus";
+};
+
+&reg_rtc_ldo {
+ regulator-name = "vcc-rtc";
+};
+
/* On Exp and Euler connectors */
&uart0 {
pinctrl-names = "default";

--
2.13.0

Icenowy Zheng

2017-07-19 16:10:17 UTC

Permalink

The SoPine SoM has an AXP803 PMIC connected to the RSB bus of the A64
SoC.

Add its device tree node to the DTSI.

Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
index 475518b031dd..ab9464dd50c5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -63,3 +63,14 @@
bus-width = <4>;
status = "okay";
};
+
+&r_rsb {
+ status = "okay";
+
+ axp803: ***@3a3 {
+ compatible = "x-powers,axp803";
+ reg = <0x3a3>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};

--
2.13.0

Icenowy Zheng

2017-07-19 16:10:16 UTC

Permalink

The Pine64 DT used to contain a dummy vcc3v3 regulator, in order to
satisfy some device nodes when proper AXP803 regulator support is
available. It's in fact the DCDC1 regulator of AXP803.

Drop the dummy regulator, and fix the reference of this regulator to
DCDC1.

Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index ac31c9477b25..68a47d9b07d9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -61,13 +61,6 @@
chosen {
stdout-path = "serial0:115200n8";
};
-
- reg_vcc3v3: vcc3v3 {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
};

&ehci0 {
@@ -108,7 +101,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
- vmmc-supply = <&reg_vcc3v3>;
+ vmmc-supply = <&reg_dcdc1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
cd-inverted;
disable-wp;

--
2.13.0

Andre Przywara

2017-07-21 12:45:39 UTC

Permalink

Hi,

Post by Icenowy Zheng
The Pine64 DT used to contain a dummy vcc3v3 regulator, in order to
satisfy some device nodes when proper AXP803 regulator support is
available. It's in fact the DCDC1 regulator of AXP803.
Drop the dummy regulator, and fix the reference of this regulator to
DCDC1.

Do we really need to have this?
While I see that this is technically correct, it breaks older kernels,
which miss the AXP driver. So we can't use this DT for syncing it into
U-Boot anymore, while still expecting various kernels (for instance from
distribution installers) to work via UEFI (for which U-Boot provides the
DT). That would be a shame, because we start to see generic arm64
distribution installers to work out of the box.

I see these solutions:
1) We drop this patch, instead add a comment that technically it's
DCDC1. I believe we can't really turn off DCDC1 anyway.
2) We keep theses patches, but don't sync them to U-Boot to have a
universal DT in there which works with every kernel.
3) We keep these patches *and* sync them to U-Boot, but add the fixed
regulator back in via a U-Boot specific .dtsi "overlay" snippet. This
would take care of the parts that break compatibility. The end result
would be similar to 2), then.

The easiest and most maintainable would be 1), but I am OK with 3) as
well, though I am not sure this won't get messy in the future and will
work for every change that we make.

What do you think?

Cheers,
Andre.

Post by Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index ac31c9477b25..68a47d9b07d9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -61,13 +61,6 @@
chosen {
stdout-path = "serial0:115200n8";
};
-
- reg_vcc3v3: vcc3v3 {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
};
&ehci0 {
@@ -108,7 +101,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
- vmmc-supply = <&reg_vcc3v3>;
+ vmmc-supply = <&reg_dcdc1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
cd-inverted;
disable-wp;

Icenowy Zheng

2017-07-21 12:49:23 UTC

Permalink

Post by Andre Przywara
Hi,

Do we really need to have this?
While I see that this is technically correct, it breaks older kernels,
which miss the AXP driver. So we can't use this DT for syncing it into
U-Boot anymore, while still expecting various kernels (for instance from
distribution installers) to work via UEFI (for which U-Boot provides the
DT). That would be a shame, because we start to see generic arm64
distribution installers to work out of the box.
1) We drop this patch, instead add a comment that technically it's
DCDC1. I believe we can't really turn off DCDC1 anyway.
2) We keep theses patches, but don't sync them to U-Boot to have a
universal DT in there which works with every kernel.
3) We keep these patches *and* sync them to U-Boot, but add the fixed
regulator back in via a U-Boot specific .dtsi "overlay" snippet. This
would take care of the parts that break compatibility. The end result
would be similar to 2), then.
The easiest and most maintainable would be 1), but I am OK with 3) as
well, though I am not sure this won't get messy in the future and will
work for every change that we make.
What do you think?

4) Do nothing.

We only promise old DTs will run with newer kernel, but
we don't promise newer DTs to run with old kernel. And
U-Boot is intended to update less frequently than Linux.

When updateing U-Boot, please update kernel as well.

Post by Andre Przywara
Cheers,
Andre.

b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

Post by Icenowy Zheng
index ac31c9477b25..68a47d9b07d9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -61,13 +61,6 @@
chosen {
stdout-path = "serial0:115200n8";
};
-
- reg_vcc3v3: vcc3v3 {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
};
&ehci0 {
@@ -108,7 +101,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
- vmmc-supply = <&reg_vcc3v3>;
+ vmmc-supply = <&reg_dcdc1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
cd-inverted;
disable-wp;

Andre Przywara

2017-07-21 13:02:18 UTC

Permalink

Hi,

Post by Icenowy Zheng

Post by Andre Przywara
Hi,

Do we really need to have this?
While I see that this is technically correct, it breaks older kernels,
which miss the AXP driver. So we can't use this DT for syncing it into
U-Boot anymore, while still expecting various kernels (for instance from
distribution installers) to work via UEFI (for which U-Boot provides the
DT). That would be a shame, because we start to see generic arm64
distribution installers to work out of the box.
1) We drop this patch, instead add a comment that technically it's
DCDC1. I believe we can't really turn off DCDC1 anyway.
2) We keep theses patches, but don't sync them to U-Boot to have a
universal DT in there which works with every kernel.
3) We keep these patches *and* sync them to U-Boot, but add the fixed
regulator back in via a U-Boot specific .dtsi "overlay" snippet. This
would take care of the parts that break compatibility. The end result
would be similar to 2), then.
The easiest and most maintainable would be 1), but I am OK with 3) as
well, though I am not sure this won't get messy in the future and will
work for every change that we make.
What do you think?

4) Do nothing.
We only promise old DTs will run with newer kernel, but
we don't promise newer DTs to run with old kernel.And
U-Boot is intended to update less frequently than Linux.
When updateing U-Boot, please update kernel as well.

Which means you tie your firmware to a kernel. I know this is the old
embedded approach, but we should really get rid of this, as I don't see
how this will work nicely with the Pinebook, for instance (which is not
really "embedded" anymore).
U-Boot sits on the SPI flash there, and you are expected to just run any
(not only Linux) distribution from a USB pen drive, for instance, with
that one firmware version, using UEFI. This already works today, but is
only sustainable if we have forward DT compatibility as well.

Cheers,
Andre.

Post by Icenowy Zheng

Post by Andre Przywara

b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

i***@aosc.io

2017-07-21 13:51:16 UTC

Permalink

在 2017-07-21 21:02，Andre Przywara 写道：

Post by Andre Przywara
Hi,

于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara

Post by Andre Przywara
Hi,

Do we really need to have this?
While I see that this is technically correct, it breaks older kernels,
which miss the AXP driver. So we can't use this DT for syncing it into
U-Boot anymore, while still expecting various kernels (for instance from
distribution installers) to work via UEFI (for which U-Boot provides the
DT). That would be a shame, because we start to see generic arm64
distribution installers to work out of the box.
1) We drop this patch, instead add a comment that technically it's
DCDC1. I believe we can't really turn off DCDC1 anyway.
2) We keep theses patches, but don't sync them to U-Boot to have a
universal DT in there which works with every kernel.
3) We keep these patches *and* sync them to U-Boot, but add the fixed
regulator back in via a U-Boot specific .dtsi "overlay" snippet. This
would take care of the parts that break compatibility. The end result
would be similar to 2), then.
The easiest and most maintainable would be 1), but I am OK with 3) as
well, though I am not sure this won't get messy in the future and will
work for every change that we make.
What do you think?

4) Do nothing.
We only promise old DTs will run with newer kernel, but
we don't promise newer DTs to run with old kernel.And
U-Boot is intended to update less frequently than Linux.
When updateing U-Boot, please update kernel as well.

Old firmware suit both old and new kernels, and for newer firmwares,
use newer kernels.

This is an intended behavior, and will exist not only on ARM if the
firmware gains something new.

Post by Andre Przywara
Cheers,
Andre.

Post by Andre Przywara

b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

_______________________________________________
linux-arm-kernel mailing list
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Alexander Graf

2017-07-21 14:03:36 UTC

Permalink

Post by i***@aosc.io
在 2017-07-21 21:02，Andre Przywara 写道：

Post by Andre Przywara
Hi,

于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara

Post by Andre Przywara
Hi,

Do we really need to have this?
While I see that this is technically correct, it breaks older kernels,
which miss the AXP driver. So we can't use this DT for syncing it into
U-Boot anymore, while still expecting various kernels (for instance from
distribution installers) to work via UEFI (for which U-Boot provides the
DT). That would be a shame, because we start to see generic arm64
distribution installers to work out of the box.
1) We drop this patch, instead add a comment that technically it's
DCDC1. I believe we can't really turn off DCDC1 anyway.
2) We keep theses patches, but don't sync them to U-Boot to have a
universal DT in there which works with every kernel.
3) We keep these patches *and* sync them to U-Boot, but add the fixed
regulator back in via a U-Boot specific .dtsi "overlay" snippet. This
would take care of the parts that break compatibility. The end result
would be similar to 2), then.
The easiest and most maintainable would be 1), but I am OK with 3) as
well, though I am not sure this won't get messy in the future and will
work for every change that we make.
What do you think?

4) Do nothing.
We only promise old DTs will run with newer kernel, but
we don't promise newer DTs to run with old kernel.And
U-Boot is intended to update less frequently than Linux.
When updateing U-Boot, please update kernel as well.

Old firmware suit both old and new kernels, and for newer firmwares,
use newer kernels.

Congratulations, you basically just broke any Linux distribution out
there :).

Post by i***@aosc.io
This is an intended behavior, and will exist not only on ARM if the
firmware gains something new.

For new features it's some times required to update to new kernels. Once
a platform is out in the market, that should really get limited to
drivers though.

Alex

Maxime Ripard

2017-07-21 14:38:58 UTC

Permalink

Post by Andre Przywara
Hi,

Post by Icenowy Zheng

Post by Andre Przywara
Hi,

Do we really need to have this?
While I see that this is technically correct, it breaks older kernels,
which miss the AXP driver. So we can't use this DT for syncing it into
U-Boot anymore, while still expecting various kernels (for instance from
distribution installers) to work via UEFI (for which U-Boot provides the
DT). That would be a shame, because we start to see generic arm64
distribution installers to work out of the box.
1) We drop this patch, instead add a comment that technically it's
DCDC1. I believe we can't really turn off DCDC1 anyway.
2) We keep theses patches, but don't sync them to U-Boot to have a
universal DT in there which works with every kernel.
3) We keep these patches *and* sync them to U-Boot, but add the fixed
regulator back in via a U-Boot specific .dtsi "overlay" snippet. This
would take care of the parts that break compatibility. The end result
would be similar to 2), then.
The easiest and most maintainable would be 1), but I am OK with 3) as
well, though I am not sure this won't get messy in the future and will
work for every change that we make.
What do you think?

4) Do nothing.
We only promise old DTs will run with newer kernel, but
we don't promise newer DTs to run with old kernel.And
U-Boot is intended to update less frequently than Linux.
When updateing U-Boot, please update kernel as well.

We've been discussing this over and over and over again. You're using
the pinebook as an example, fine. Please give me the full documented,
reviewed and acked-by binding for all the features the pinebook has.

If you can't, this discussion is pointless, since you will expect
changes in the DT.

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Andre Przywara

2017-07-21 15:08:42 UTC

Permalink

Hi,