[PATCH 0/5] AXP803 regulator support for Pine64 and SoPine

[PATCH 0/5] AXP803 regulator support for Pine64 and SoPine

[Icenowy Zheng]

The Pine64 and SoPine w/ baseboard boards have an AXP803 PMIC, and the
regulators of the PMIC are used.

This patchset adds the regulators to the device tree of these two boards.

The first patch introduces proper AXP803 regulators to Pine64 DT, and the
second patch removed dummy regulators in the Pine64 DT.

The third patch enables AXP803 PMIC for SoPine.

The fourth patch and fifth patch are like the first and the second, but
they're for SoPine w/ baseboard.

Icenowy Zheng (5):
  arm64: allwinner: a64: enable AXP803 regulators for Pine64
  arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT
  arm64: allwinner: a64: add AXP803 PMIC to SoPine DTSI
  arm64: allwinner: a64: add AXP803 regulators support for SoPine
  arm: allwinner: a64: drop vcc3v3 and vcc1v8 dummy regulators for
    SoPine

 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 105 +++++++++++++++++++--
 .../dts/allwinner/sun50i-a64-sopine-baseboard.dts  |  34 +++++--
 .../boot/dts/allwinner/sun50i-a64-sopine.dtsi      |  91 ++++++++++++++++--
 3 files changed, 203 insertions(+), 27 deletions(-)

-- 
2.13.0

--
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

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

[Icenowy Zheng]

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 <icenowy-h8G6r0blFSE@public.gmane.org>
---
 .../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

--
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

[PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[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.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
 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

Re: [linux-sunxi] [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[Andre Przywara]

Hi,

On 19/07/17 17:10, Icenowy Zheng wrote:
> 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.

> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
>  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;
> 
--
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

Re: [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[Icenowy Zheng]

于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>Hi,
>
>On 19/07/17 17:10, Icenowy Zheng wrote:
>> 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?

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.

>
>Cheers,
>Andre.
>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>>  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;
>> 

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[Andre Przywara]

Hi,

On 21/07/17 13:49, Icenowy Zheng wrote:
> 
> 
> 于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>> Hi,
>>
>> On 19/07/17 17:10, Icenowy Zheng wrote:
>>> 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?
> 
> 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.

>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> ---
>>>  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;
>>>
--
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

Re: [linux-sunxi] [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[icenowy-h8G6r0blFSE]

在 2017-07-21 21:02，Andre Przywara 写道：
> Hi,
> 
> On 21/07/17 13:49, Icenowy Zheng wrote:
>> 
>> 
>> 于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara 
>> <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>> Hi,
>>> 
>>> On 19/07/17 17:10, Icenowy Zheng wrote:
>>>> 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?
>> 
>> 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.

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.

> 
> 
> Cheers,
> Andre.
> 
>>> 
>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>> ---
>>>>  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;
>>>> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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

Re: [linux-sunxi] [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[Alexander Graf]

On 07/21/2017 03:51 PM, icenowy-h8G6r0blFSE@public.gmane.org wrote:
> 在 2017-07-21 21:02，Andre Przywara 写道：
>> Hi,
>>
>> On 21/07/17 13:49, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara 
>>> <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>>> Hi,
>>>>
>>>> On 19/07/17 17:10, Icenowy Zheng wrote:
>>>>> 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?
>>>
>>> 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.
>
> 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 :).

> 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

--
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

Re: [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

On Fri, Jul 21, 2017 at 02:02:18PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 21/07/17 13:49, Icenowy Zheng wrote:
> > 
> > 
> > 于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> >> Hi,
> >>
> >> On 19/07/17 17:10, Icenowy Zheng wrote:
> >>> 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?
> > 
> > 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.

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

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[Andre Przywara]

Hi,

On 21/07/17 15:38, Maxime Ripard wrote:
> On Fri, Jul 21, 2017 at 02:02:18PM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 21/07/17 13:49, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>>> Hi,
>>>>
>>>> On 19/07/17 17:10, Icenowy Zheng wrote:
>>>>> 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?
>>>
>>> 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.
> 
> We've been discussing this over and over and over again.

Don't tell me ;-)
But apart from "We don't care" I haven't got a real solution out of this
discussion.

> You're using the pinebook as an example, fine.

I believe the current approach for supporting Allwinner boards is rooted
in some embedded world, where shipping firmware together with some
kernel is standard, especially if there is no on-board storage anyway.

But the Pinebook is clearly not embedded and comes with SPI flash to
boot from, so people might expect to install some Linux distribution on it.
And with the UEFI support in U-Boot we have a good solution for this
(check the debian-testing arm64 installer), and so far this works: every
extension we did to the DT was still fine with older kernels - this
particular feature might not work (say Ethernet in kernels < 2.13-rc1),
but at least it doesn't hurt or introduces regressions.

> 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.

It's not about *changes* per se, it's about breaking compatibility,
which can be avoided.
As long as we just *add* features (DE2/HDMI, for instance) and don't
introduce regressions, touching the DT is fine.

And yes: I expect some hiccups with this, but also would hope for
finding some solutions (like the ones sketched in my original email).

Cheers,
Andre.

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[Icenowy Zheng]

于 2017年7月21日 GMT+08:00 下午11:08:42, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>Hi,
>
>On 21/07/17 15:38, Maxime Ripard wrote:
>> On Fri, Jul 21, 2017 at 02:02:18PM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 21/07/17 13:49, Icenowy Zheng wrote:
>>>>
>>>>
>>>> 于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara
><andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>>>> Hi,
>>>>>
>>>>> On 19/07/17 17:10, Icenowy Zheng wrote:
>>>>>> 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?
>>>>
>>>> 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.
>> 
>> We've been discussing this over and over and over again.
>
>Don't tell me ;-)
>But apart from "We don't care" I haven't got a real solution out of
>this
>discussion.
>
>> You're using the pinebook as an example, fine.
>
>I believe the current approach for supporting Allwinner boards is
>rooted
>in some embedded world, where shipping firmware together with some
>kernel is standard, especially if there is no on-board storage anyway.
>
>But the Pinebook is clearly not embedded and comes with SPI flash to
>boot from, so people might expect to install some Linux distribution on
>it.

In fact current version of Pinebook has no SPI Flash.

>And with the UEFI support in U-Boot we have a good solution for this
>(check the debian-testing arm64 installer), and so far this works:
>every
>extension we did to the DT was still fine with older kernels - this
>particular feature might not work (say Ethernet in kernels < 2.13-rc1),
>but at least it doesn't hurt or introduces regressions.
>
>> 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.
>
>It's not about *changes* per se, it's about breaking compatibility,
>which can be avoided.
>As long as we just *add* features (DE2/HDMI, for instance) and don't
>introduce regressions, touching the DT is fine.
>
>And yes: I expect some hiccups with this, but also would hope for
>finding some solutions (like the ones sketched in my original email).
>
>Cheers,
>Andre.

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 6566 bytes --]

On Fri, Jul 21, 2017 at 04:08:42PM +0100, Andre Przywara wrote:
> On 21/07/17 15:38, Maxime Ripard wrote:
> > On Fri, Jul 21, 2017 at 02:02:18PM +0100, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 21/07/17 13:49, Icenowy Zheng wrote:
> >>>
> >>>
> >>> 于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> >>>> Hi,
> >>>>
> >>>> On 19/07/17 17:10, Icenowy Zheng wrote:
> >>>>> 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?
> >>>
> >>> 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.
> > 
> > We've been discussing this over and over and over again.
> 
> Don't tell me ;-)
> But apart from "We don't care" I haven't got a real solution out of this
> discussion.

You're looking for a solution to an industry-wide problem, without
fixing the industry first. Make the thousands-engineers companies
heavily involved in mainlining their stuff (you know, the Qualcomm,
Mediatek [1], Microchip [2], Marvell [3], Rockchip, you name it)
comply with these arbitrarily made up rules.

And then the handful people working on their spare time will follow.

> > You're using the pinebook as an example, fine.
> 
> I believe the current approach for supporting Allwinner boards is rooted
> in some embedded world, where shipping firmware together with some
> kernel is standard, especially if there is no on-board storage anyway.
> 
> But the Pinebook is clearly not embedded and comes with SPI flash to
> boot from, so people might expect to install some Linux distribution on it.
> And with the UEFI support in U-Boot we have a good solution for this
> (check the debian-testing arm64 installer), and so far this works: every
> extension we did to the DT was still fine with older kernels - this
> particular feature might not work (say Ethernet in kernels < 2.13-rc1),
> but at least it doesn't hurt or introduces regressions.

Unless $distribution put some man power in supporting and mainlining
whatever they are interested in, yeah, I don't care what they think is
best. We're not their slaves.

And what would distributions think if we're all just tired of this and
just quit? How would they feel about having to use a 4 years old
kernel, without any security updates, rigged with bugs and mostly
unmaintained?

It's really time to get serious about this. Some of our most important
contributors already quit because of the sh*t we take every day, I've
thought about quitting several times in the last year. And yet, you
regularly criticize whatever we do on our evenings without real
documentation (adding your fair shair to the pile we take), want to
put more maintainance burden on us, all of that without contributing
anything significant else than "rules" that no-one else comply with?

Be reasonable for a minute.

I did that once, because it seemed important to some people at the
moment. It just gave us more ugly hacks, and just made our lives
harder.

> > 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.
> 
> It's not about *changes* per se, it's about breaking compatibility,
> which can be avoided.
> As long as we just *add* features (DE2/HDMI, for instance) and don't
> introduce regressions, touching the DT is fine.
> 
> And yes: I expect some hiccups with this, but also would hope for
> finding some solutions (like the ones sketched in my original email).

I'm going to merge this patch unless I can see a written rule
somewhere in our device tree documentation that prevent me from doing
so.

Maxime



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

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

[André Przywara]

On 21/07/17 21:39, Maxime Ripard wrote:

Hi Maxime,

sorry for causing some frustration on your side.
I am trying to answer to some of your comments. Just be aware that I am
leaving for holidays in a few hours (and trying to stay away as much
from computers as possible), so don't expect any replies in the next
three weeks.

> On Fri, Jul 21, 2017 at 04:08:42PM +0100, Andre Przywara wrote:
>> On 21/07/17 15:38, Maxime Ripard wrote:
>>> On Fri, Jul 21, 2017 at 02:02:18PM +0100, Andre Przywara wrote:
>>>> On 21/07/17 13:49, Icenowy Zheng wrote:
>>>>> 于 2017年7月21日 GMT+08:00 下午8:45:39, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>>>>> On 19/07/17 17:10, Icenowy Zheng wrote:
>>>>>>> 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?
>>>>>
>>>>> 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.
>>>
>>> We've been discussing this over and over and over again.
>>
>> Don't tell me ;-)
>> But apart from "We don't care" I haven't got a real solution out of this
>> discussion.

I just see that "We don't care" might be (mis-)understood as offensive,
apologies for that. What I meant is that in the past there was no answer
to the problem of how to handle *multiple* kernels with *one* DTB
provided by *firmware*. I consider this approach actually the actual
(original) DT use case, though I see that for many ARM platforms this
was never adopted this way.
So "We don't care" referred to the problem being dismissed as being a
real issue, which I find quite sad.

> You're looking for a solution to an industry-wide problem, without
> fixing the industry first. Make the thousands-engineers companies
> heavily involved in mainlining their stuff (you know, the Qualcomm,
> Mediatek [1], Microchip [2], Marvell [3], Rockchip, you name it)
> comply with these arbitrarily made up rules.
> 
> And then the handful people working on their spare time will follow.

I see that this is indeed part of a bigger discussion, but I am not sure
this should prevent me from commenting on this and pointing to the problems.
And by providing possible solutions I was hoping for being not too pesky.

>>> You're using the pinebook as an example, fine.
>>
>> I believe the current approach for supporting Allwinner boards is rooted
>> in some embedded world, where shipping firmware together with some
>> kernel is standard, especially if there is no on-board storage anyway.
>>
>> But the Pinebook is clearly not embedded and comes with SPI flash to
>> boot from, so people might expect to install some Linux distribution on it.
>> And with the UEFI support in U-Boot we have a good solution for this
>> (check the debian-testing arm64 installer), and so far this works: every
>> extension we did to the DT was still fine with older kernels - this
>> particular feature might not work (say Ethernet in kernels < 2.13-rc1),
>> but at least it doesn't hurt or introduces regressions.
> 
> Unless $distribution put some man power in supporting and mainlining
> whatever they are interested in, yeah, I don't care what they think is
> best. We're not their slaves.

To be honest I don't see how distributions would be involved in this, in
a "real computers" world there certainly aren't. Here they just rely on
standard firmware interfaces to boot and find device descriptions,
without being required for explicitly support or spoon-feed particular
systems.
I understand that because of the lack of alternatives (for boards
without any on-board storage) some distributions took care of providing
firmware and device descriptions for selected (ARM based) boards, but my
impression is also that this was never really loved by them. Also this
has the nasty implication of duplicating a lot of effort.
For ARM64 it seems like most distributions never adopted this scheme,
instead relying on UEFI and firmware provided DTBs, for instance.

> And what would distributions think if we're all just tired of this and
> just quit? How would they feel about having to use a 4 years old
> kernel, without any security updates, rigged with bugs and mostly
> unmaintained?
> 
> It's really time to get serious about this. Some of our most important
> contributors already quit because of the sh*t we take every day, I've
> thought about quitting several times in the last year. And yet, you
> regularly criticize whatever we do on our evenings without real
> documentation (adding your fair shair to the pile we take), want to
> put more maintainance burden on us, all of that without contributing
> anything significant else than "rules" that no-one else comply with?

I am not really sure what to answer here, my intention actually was to
decrease a lot of the maintenance burden we currently have (for instance
being required to add a lot of explicit kernel code for each now SoC).
And I was hoping that with the advent of the new ARM64 architecture we
could seize the chance of changing some things.

> Be reasonable for a minute.
> 
> I did that once, because it seemed important to some people at the
> moment. It just gave us more ugly hacks, and just made our lives
> harder.
> 
>>> 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.
>>
>> It's not about *changes* per se, it's about breaking compatibility,
>> which can be avoided.
>> As long as we just *add* features (DE2/HDMI, for instance) and don't
>> introduce regressions, touching the DT is fine.
>>
>> And yes: I expect some hiccups with this, but also would hope for
>> finding some solutions (like the ones sketched in my original email).
> 
> I'm going to merge this patch unless I can see a written rule
> somewhere in our device tree documentation that prevent me from doing
> so.

I see that many more server oriented ARM64 platforms (AMD Seattle,
Cavium ThunderX, APM XGene) actually provide their DTs in firmware and
rely on stability there. But yes, I see that this is not really
documented, and I think this was considered a per-platform decision in
the past. Hopefully we actually see some more generic DT discussions and
documentation in the near future.

And merging this patch is a fair decision as a maintainer, though you
could have used fewer words to say this ;-)

Cheers,
Andre.

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[PATCH 3/5] arm64: allwinner: a64: add AXP803 PMIC to SoPine DTSI

[Icenowy Zheng]

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 <icenowy-h8G6r0blFSE@public.gmane.org>
---
 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: pmic@3a3 {
+		compatible = "x-powers,axp803";
+		reg = <0x3a3>;
+		interrupt-parent = <&r_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
-- 
2.13.0

[PATCH 4/5] arm64: allwinner: a64: add AXP803 regulators support for SoPine

[Icenowy Zheng]

The SoPine SoM has an AXP803 PMIC chip, and the regulators of this chip
are used both on the SoM itself and the baseboard.

Add regulators nodes to the SoPine DTSI and the SoPine baseboard DT.
Regulators used by the SoM itself are added to the SoPine DTSI, and
regulators left free for the baseboard are added to the baseboard DT.

The phy-handle of the emac node in baseboard DT is also fixed, with the
same reason of the fix on Pine64 DT.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
 .../dts/allwinner/sun50i-a64-sopine-baseboard.dts  | 23 ++++++++
 .../boot/dts/allwinner/sun50i-a64-sopine.dtsi      | 69 ++++++++++++++++++++++
 2 files changed, 92 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
index 17eb1cc5bf6b..834a5d249bb2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -81,6 +81,7 @@
 	pinctrl-0 = <&rgmii_pins>;
 	phy-mode = "rgmii";
 	phy-handle = <&ext_rgmii_phy>;
+	phy-supply = <&reg_dc1sw>;
 	status = "okay";
 };
 
@@ -110,6 +111,28 @@
 	status = "okay";
 };
 
+&reg_dc1sw {
+	regulator-name = "vcc-phy";
+};
+
+&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";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
index ab9464dd50c5..7adfd013fd60 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -74,3 +74,72 @@
 		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
 	};
 };
+
+#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_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 */
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dcdc6 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_eldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vdd-1v8-lpddr";
+};
+
+/*
+ * 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";
+};
-- 
2.13.0

[PATCH 5/5] arm: allwinner: a64: drop vcc3v3 and vcc1v8 dummy regulators for SoPine

[Icenowy Zheng]

The device tree of SoPine SoM and its baseboard used to contain two
dummy regulators: vcc3v3 and vcc1v8.

As proper AXP803 regulator support is added, drop the dummy regulators,
and use the correct ones.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts | 11 ++---------
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi          | 11 +----------
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
index 834a5d249bb2..58346381e486 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -59,13 +59,6 @@
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
-
-	reg_vcc1v8: vcc1v8 {
-		compatible = "regulator-fixed";
-		regulator-name = "vcc1v8";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-	};
 };
 
 &ehci0 {
@@ -95,8 +88,8 @@
 &mmc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_pins>;
-	vmmc-supply = <&reg_vcc3v3>;
-	vqmmc-supply = <&reg_vcc1v8>;
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_eldo1>;
 	bus-width = <8>;
 	non-removable;
 	cap-mmc-hw-reset;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
index 7adfd013fd60..a7eb9c197023 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -45,19 +45,10 @@
 
 #include "sun50i-a64.dtsi"
 
-/ {
-	reg_vcc3v3: vcc3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "vcc3v3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-	};
-};
-
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
-	vmmc-supply = <&reg_vcc3v3>;
+	vmmc-supply = <&reg_dcdc1>;
 	non-removable;
 	disable-wp;
 	bus-width = <4>;
-- 
2.13.0

--
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

Re: [PATCH 0/5] AXP803 regulator support for Pine64 and SoPine

[Chen-Yu Tsai]

On Thu, Jul 20, 2017 at 12:10 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> The Pine64 and SoPine w/ baseboard boards have an AXP803 PMIC, and the
> regulators of the PMIC are used.
>
> This patchset adds the regulators to the device tree of these two boards.
>
> The first patch introduces proper AXP803 regulators to Pine64 DT, and the
> second patch removed dummy regulators in the Pine64 DT.
>
> The third patch enables AXP803 PMIC for SoPine.
>
> The fourth patch and fifth patch are like the first and the second, but
> they're for SoPine w/ baseboard.
>
> Icenowy Zheng (5):
>   arm64: allwinner: a64: enable AXP803 regulators for Pine64
>   arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT
>   arm64: allwinner: a64: add AXP803 PMIC to SoPine DTSI
>   arm64: allwinner: a64: add AXP803 regulators support for SoPine
>   arm: allwinner: a64: drop vcc3v3 and vcc1v8 dummy regulators for
>     SoPine

The related drivers are all merged. There's really no reason to split
these into separate patches. Patch 1 & 2 can be squashed together.
Patch 3, 4 & 5 can be squashed together.

The patches themselves look good, though I have not checked them
against the schematics.

ChenYu

>
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 105 +++++++++++++++++++--
>  .../dts/allwinner/sun50i-a64-sopine-baseboard.dts  |  34 +++++--
>  .../boot/dts/allwinner/sun50i-a64-sopine.dtsi      |  91 ++++++++++++++++--
>  3 files changed, 203 insertions(+), 27 deletions(-)
>
> --
> 2.13.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/5] AXP803 regulator support for Pine64 and SoPine

[icenowy-h8G6r0blFSE]

在 2017-07-20 12:11，Chen-Yu Tsai 写道：
> On Thu, Jul 20, 2017 at 12:10 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> 
> wrote:
>> The Pine64 and SoPine w/ baseboard boards have an AXP803 PMIC, and the
>> regulators of the PMIC are used.
>> 
>> This patchset adds the regulators to the device tree of these two 
>> boards.
>> 
>> The first patch introduces proper AXP803 regulators to Pine64 DT, and 
>> the
>> second patch removed dummy regulators in the Pine64 DT.
>> 
>> The third patch enables AXP803 PMIC for SoPine.
>> 
>> The fourth patch and fifth patch are like the first and the second, 
>> but
>> they're for SoPine w/ baseboard.
>> 
>> Icenowy Zheng (5):
>>   arm64: allwinner: a64: enable AXP803 regulators for Pine64
>>   arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT
>>   arm64: allwinner: a64: add AXP803 PMIC to SoPine DTSI
>>   arm64: allwinner: a64: add AXP803 regulators support for SoPine
>>   arm: allwinner: a64: drop vcc3v3 and vcc1v8 dummy regulators for
>>     SoPine
> 
> The related drivers are all merged. There's really no reason to split
> these into separate patches. Patch 1 & 2 can be squashed together.
> Patch 3, 4 & 5 can be squashed together.
> 
> The patches themselves look good, though I have not checked them
> against the schematics.

In fact I prefer to split out the patch that removes the dummy
regulators, but if you think squashing them is better, I will
do it.

Squash 3 into 4 is of course okay.

> 
> ChenYu
> 
>> 
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 105 
>> +++++++++++++++++++--
>>  .../dts/allwinner/sun50i-a64-sopine-baseboard.dts  |  34 +++++--
>>  .../boot/dts/allwinner/sun50i-a64-sopine.dtsi      |  91 
>> ++++++++++++++++--
>>  3 files changed, 203 insertions(+), 27 deletions(-)
>> 
>> --
>> 2.13.0
>> 
>> --
>> You received this message because you are subscribed to the Google 
>> Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.