From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751999AbdGRC7S convert rfc822-to-8bit (ORCPT ); Mon, 17 Jul 2017 22:59:18 -0400 Received: from smtp.csie.ntu.edu.tw ([140.112.30.61]:41122 "EHLO smtp.csie.ntu.edu.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751503AbdGRC7Q (ORCPT ); Mon, 17 Jul 2017 22:59:16 -0400 MIME-Version: 1.0 In-Reply-To: <77045320-c19a-6c18-ed68-108fa5416c2a@arm.com> References: <20170518071653.36561-1-icenowy@aosc.io> <20170518071653.36561-9-icenowy@aosc.io> <98ae1ea8-ef08-8859-63d8-57c56a6348a6@arm.com> <4B129FD0-4AEB-4DC3-AF33-C279468BD197@aosc.io> <77045320-c19a-6c18-ed68-108fa5416c2a@arm.com> From: Chen-Yu Tsai Date: Tue, 18 Jul 2017 10:58:52 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64 To: Icenowy Zheng Cc: Andre Przywara , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Maxime Ripard , Chen-Yu Tsai , Lee Jones , Liam Girdwood , Mark Brown , linux-kernel , devicetree , linux-arm-kernel , linux-sunxi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 19, 2017 at 4:55 PM, Andre Przywara wrote: > Hi, > > On 19/05/17 09:29, Icenowy Zheng wrote: >> >> >> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara 写到: >>> Hi, >>> >>> On 18/05/17 08:16, Icenowy Zheng wrote: >>>> Add support of AXP803 regulators in the Pine64 device tree, in order >>> to >>>> enable many future functionalities, e.g. Wi-Fi. >>>> >>>> Signed-off-by: Icenowy Zheng >>>> --- >>>> Changes in v6: >>>> - Rebased on next-20170517. >>>> >>>> .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 >>> +++++++++++++++++++++ >>>> 1 file changed, 109 insertions(+) >>>> >>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> index 36001884ed33..40921bacb39c 100644 >>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> @@ -118,6 +118,115 @@ >>>> }; >>>> }; >>>> >>>> +#include "axp803.dtsi" >>>> + >>>> +®_aldo1 { >>>> + regulator-min-microvolt = <2800000>; >>>> + regulator-max-microvolt = <2800000>; >>>> + regulator-name = "vcc-csi"; >>>> +}; >>>> + >>>> +®_aldo2 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <1800000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-pl"; >>>> +}; >>>> + >>>> +®_aldo3 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <2700000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-pll-avcc"; >>>> +}; > > The schematic puts this at a fixed 3.0V, so why the range here? Are we > expected to tune the voltage of the PLLs? Normally these would describe the operating limits. We did this in the past for most boards. I'm fine with fixing it to 3.0V though. > >>>> + >>>> +®_dc1sw { >>>> + regulator-name = "vcc-phy"; >>>> +}; >>>> + >>>> +®_dcdc1 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-3v3"; >>>> +}; >>>> + >>>> +®_dcdc2 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <1000000>; >>>> + regulator-max-microvolt = <1300000>; >>>> + regulator-name = "vdd-cpux"; >>>> +}; >>>> + >>>> +/* DCDC3 is polyphased with DCDC2 */ >>>> + >>>> +®_dcdc5 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <1500000>; >>>> + regulator-max-microvolt = <1500000>; >>>> + regulator-name = "vcc-dram"; >>>> +}; >>> >>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which >>> is >>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP). >>> The reset value is even (wrongly?) configured to 1.24V. >>> >>> So is there any reason you set the voltage to 1.5V? Is that what the >>> BSP >>> does? Or did you see any problems with 1.36V? >> >> I just set it based on the schematics. > > I wouldn't trust the schematics too much. They are rather generic, see > the Ethernet page, for instance, showing *different* PHYs, not just the > ones used. > For the DRAM the Pine64 schematic does not even tell the DRAM chip used, > the name under the chip is just describing the package. > >> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-) > > Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV > more is well within the tolerance ;-) > >>>> +®_dcdc6 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <1100000>; >>>> + regulator-max-microvolt = <1100000>; >>>> + regulator-name = "vdd-sys"; >>>> +}; >>>> + >>>> +®_dldo1 { >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-hdmi"; >>>> +}; >>>> + >>>> +®_dldo2 { >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-mipi"; >>>> +}; >>>> + >>>> +®_dldo3 { >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "avdd-csi"; >>>> +}; > > If you stick to the schematic, this should be 2.8V. Agreed. But... >>>> + >>>> +®_dldo4 { >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-wifi"; >>>> +}; >>>> + >>>> +®_eldo1 { >>>> + regulator-min-microvolt = <1800000>; >>>> + regulator-max-microvolt = <1800000>; >>>> + regulator-name = "cpvdd"; >>>> +}; >>>> + >>>> +®_eldo3 { >>>> + regulator-min-microvolt = <1800000>; >>>> + regulator-max-microvolt = <1800000>; >>>> + regulator-name = "vdd-1v8-csi"; >>>> +}; > > The schematic lists 1.2V/1.5V/1.8V here, so should we have a range? This and avdd-csi really depends on the camera module used. Maybe this should be left to an overlay. > >>>> + >>>> +®_fldo1 { >>>> + regulator-min-microvolt = <1200000>; >>>> + regulator-max-microvolt = <1200000>; >>>> + regulator-name = "vcc-1v2-hsic"; >>>> +}; >>>> + >>>> +®_fldo2 { >>>> + regulator-always-on; > > Why do we need to turn this on? Upstream firmware does not use the > arisc, so it can stay off. > Also in general I think Linux should not tinker with the management > processor at all. I'm not sure, but I think at least one SoC had failed to work without this powered on. If that is the case with the A64, then please leave a comment saying so. Otherwise let it stay off. ChenYu > Cheers, > Andre. > >>>> + regulator-min-microvolt = <1100000>; >>>> + regulator-max-microvolt = <1100000>; >>>> + regulator-name = "vdd-cpus"; >>>> +}; >>>> + >>>> +®_rtc_ldo { >>>> + regulator-name = "vcc-rtc"; >>>> +}; >>>> + >>>> /* On Exp and Euler connectors */ >>>> &uart0 { >>>> pinctrl-names = "default"; >>>> From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chen-Yu Tsai Subject: Re: [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64 Date: Tue, 18 Jul 2017 10:58:52 +0800 Message-ID: References: <20170518071653.36561-1-icenowy@aosc.io> <20170518071653.36561-9-icenowy@aosc.io> <98ae1ea8-ef08-8859-63d8-57c56a6348a6@arm.com> <4B129FD0-4AEB-4DC3-AF33-C279468BD197@aosc.io> <77045320-c19a-6c18-ed68-108fa5416c2a@arm.com> Reply-To: wens-jdAy2FN1RRM@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <77045320-c19a-6c18-ed68-108fa5416c2a-5wv7dgnIgG8@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Icenowy Zheng Cc: Andre Przywara , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Maxime Ripard , Chen-Yu Tsai , Lee Jones , Liam Girdwood , Mark Brown , linux-kernel , devicetree , linux-arm-kernel , linux-sunxi List-Id: devicetree@vger.kernel.org On Fri, May 19, 2017 at 4:55 PM, Andre Przywara wr= ote: > Hi, > > On 19/05/17 09:29, Icenowy Zheng wrote: >> >> >> =E4=BA=8E 2017=E5=B9=B45=E6=9C=8819=E6=97=A5 GMT+08:00 =E4=B8=8B=E5=8D= =884:27:21, Andre Przywara =E5=86=99=E5=88=B0: >>> Hi, >>> >>> On 18/05/17 08:16, Icenowy Zheng wrote: >>>> Add support of AXP803 regulators in the Pine64 device tree, in order >>> to >>>> enable many future functionalities, e.g. Wi-Fi. >>>> >>>> Signed-off-by: Icenowy Zheng >>>> --- >>>> Changes in v6: >>>> - Rebased on next-20170517. >>>> >>>> .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 >>> +++++++++++++++++++++ >>>> 1 file changed, 109 insertions(+) >>>> >>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> index 36001884ed33..40921bacb39c 100644 >>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> @@ -118,6 +118,115 @@ >>>> }; >>>> }; >>>> >>>> +#include "axp803.dtsi" >>>> + >>>> +®_aldo1 { >>>> + regulator-min-microvolt =3D <2800000>; >>>> + regulator-max-microvolt =3D <2800000>; >>>> + regulator-name =3D "vcc-csi"; >>>> +}; >>>> + >>>> +®_aldo2 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt =3D <1800000>; >>>> + regulator-max-microvolt =3D <3300000>; >>>> + regulator-name =3D "vcc-pl"; >>>> +}; >>>> + >>>> +®_aldo3 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt =3D <2700000>; >>>> + regulator-max-microvolt =3D <3300000>; >>>> + regulator-name =3D "vcc-pll-avcc"; >>>> +}; > > The schematic puts this at a fixed 3.0V, so why the range here? Are we > expected to tune the voltage of the PLLs? Normally these would describe the operating limits. We did this in the past for most boards. I'm fine with fixing it to 3.0V though. > >>>> + >>>> +®_dc1sw { >>>> + regulator-name =3D "vcc-phy"; >>>> +}; >>>> + >>>> +®_dcdc1 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt =3D <3300000>; >>>> + regulator-max-microvolt =3D <3300000>; >>>> + regulator-name =3D "vcc-3v3"; >>>> +}; >>>> + >>>> +®_dcdc2 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt =3D <1000000>; >>>> + regulator-max-microvolt =3D <1300000>; >>>> + regulator-name =3D "vdd-cpux"; >>>> +}; >>>> + >>>> +/* DCDC3 is polyphased with DCDC2 */ >>>> + >>>> +®_dcdc5 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt =3D <1500000>; >>>> + regulator-max-microvolt =3D <1500000>; >>>> + regulator-name =3D "vcc-dram"; >>>> +}; >>> >>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which >>> is >>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP). >>> The reset value is even (wrongly?) configured to 1.24V. >>> >>> So is there any reason you set the voltage to 1.5V? Is that what the >>> BSP >>> does? Or did you see any problems with 1.36V? >> >> I just set it based on the schematics. > > I wouldn't trust the schematics too much. They are rather generic, see > the Ethernet page, for instance, showing *different* PHYs, not just the > ones used. > For the DRAM the Pine64 schematic does not even tell the DRAM chip used, > the name under the chip is just describing the package. > >> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whet= her to use 1.34v or 1.36v ;-) > > Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV > more is well within the tolerance ;-) > >>>> +®_dcdc6 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt =3D <1100000>; >>>> + regulator-max-microvolt =3D <1100000>; >>>> + regulator-name =3D "vdd-sys"; >>>> +}; >>>> + >>>> +®_dldo1 { >>>> + regulator-min-microvolt =3D <3300000>; >>>> + regulator-max-microvolt =3D <3300000>; >>>> + regulator-name =3D "vcc-hdmi"; >>>> +}; >>>> + >>>> +®_dldo2 { >>>> + regulator-min-microvolt =3D <3300000>; >>>> + regulator-max-microvolt =3D <3300000>; >>>> + regulator-name =3D "vcc-mipi"; >>>> +}; >>>> + >>>> +®_dldo3 { >>>> + regulator-min-microvolt =3D <3300000>; >>>> + regulator-max-microvolt =3D <3300000>; >>>> + regulator-name =3D "avdd-csi"; >>>> +}; > > If you stick to the schematic, this should be 2.8V. Agreed. But... >>>> + >>>> +®_dldo4 { >>>> + regulator-min-microvolt =3D <3300000>; >>>> + regulator-max-microvolt =3D <3300000>; >>>> + regulator-name =3D "vcc-wifi"; >>>> +}; >>>> + >>>> +®_eldo1 { >>>> + regulator-min-microvolt =3D <1800000>; >>>> + regulator-max-microvolt =3D <1800000>; >>>> + regulator-name =3D "cpvdd"; >>>> +}; >>>> + >>>> +®_eldo3 { >>>> + regulator-min-microvolt =3D <1800000>; >>>> + regulator-max-microvolt =3D <1800000>; >>>> + regulator-name =3D "vdd-1v8-csi"; >>>> +}; > > The schematic lists 1.2V/1.5V/1.8V here, so should we have a range? This and avdd-csi really depends on the camera module used. Maybe this should be left to an overlay. > >>>> + >>>> +®_fldo1 { >>>> + regulator-min-microvolt =3D <1200000>; >>>> + regulator-max-microvolt =3D <1200000>; >>>> + regulator-name =3D "vcc-1v2-hsic"; >>>> +}; >>>> + >>>> +®_fldo2 { >>>> + regulator-always-on; > > Why do we need to turn this on? Upstream firmware does not use the > arisc, so it can stay off. > Also in general I think Linux should not tinker with the management > processor at all. I'm not sure, but I think at least one SoC had failed to work without this powered on. If that is the case with the A64, then please leave a comment saying so. Otherwise let it stay off. ChenYu > Cheers, > Andre. > >>>> + regulator-min-microvolt =3D <1100000>; >>>> + regulator-max-microvolt =3D <1100000>; >>>> + regulator-name =3D "vdd-cpus"; >>>> +}; >>>> + >>>> +®_rtc_ldo { >>>> + regulator-name =3D "vcc-rtc"; >>>> +}; >>>> + >>>> /* On Exp and Euler connectors */ >>>> &uart0 { >>>> pinctrl-names =3D "default"; >>>> --=20 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 e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 From: wens@csie.org (Chen-Yu Tsai) Date: Tue, 18 Jul 2017 10:58:52 +0800 Subject: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64 In-Reply-To: <77045320-c19a-6c18-ed68-108fa5416c2a@arm.com> References: <20170518071653.36561-1-icenowy@aosc.io> <20170518071653.36561-9-icenowy@aosc.io> <98ae1ea8-ef08-8859-63d8-57c56a6348a6@arm.com> <4B129FD0-4AEB-4DC3-AF33-C279468BD197@aosc.io> <77045320-c19a-6c18-ed68-108fa5416c2a@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, May 19, 2017 at 4:55 PM, Andre Przywara wrote: > Hi, > > On 19/05/17 09:29, Icenowy Zheng wrote: >> >> >> ? 2017?5?19? GMT+08:00 ??4:27:21, Andre Przywara ??: >>> Hi, >>> >>> On 18/05/17 08:16, Icenowy Zheng wrote: >>>> Add support of AXP803 regulators in the Pine64 device tree, in order >>> to >>>> enable many future functionalities, e.g. Wi-Fi. >>>> >>>> Signed-off-by: Icenowy Zheng >>>> --- >>>> Changes in v6: >>>> - Rebased on next-20170517. >>>> >>>> .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 >>> +++++++++++++++++++++ >>>> 1 file changed, 109 insertions(+) >>>> >>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> index 36001884ed33..40921bacb39c 100644 >>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts >>>> @@ -118,6 +118,115 @@ >>>> }; >>>> }; >>>> >>>> +#include "axp803.dtsi" >>>> + >>>> +®_aldo1 { >>>> + regulator-min-microvolt = <2800000>; >>>> + regulator-max-microvolt = <2800000>; >>>> + regulator-name = "vcc-csi"; >>>> +}; >>>> + >>>> +®_aldo2 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <1800000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-pl"; >>>> +}; >>>> + >>>> +®_aldo3 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <2700000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-pll-avcc"; >>>> +}; > > The schematic puts this at a fixed 3.0V, so why the range here? Are we > expected to tune the voltage of the PLLs? Normally these would describe the operating limits. We did this in the past for most boards. I'm fine with fixing it to 3.0V though. > >>>> + >>>> +®_dc1sw { >>>> + regulator-name = "vcc-phy"; >>>> +}; >>>> + >>>> +®_dcdc1 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-3v3"; >>>> +}; >>>> + >>>> +®_dcdc2 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <1000000>; >>>> + regulator-max-microvolt = <1300000>; >>>> + regulator-name = "vdd-cpux"; >>>> +}; >>>> + >>>> +/* DCDC3 is polyphased with DCDC2 */ >>>> + >>>> +®_dcdc5 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <1500000>; >>>> + regulator-max-microvolt = <1500000>; >>>> + regulator-name = "vcc-dram"; >>>> +}; >>> >>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which >>> is >>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP). >>> The reset value is even (wrongly?) configured to 1.24V. >>> >>> So is there any reason you set the voltage to 1.5V? Is that what the >>> BSP >>> does? Or did you see any problems with 1.36V? >> >> I just set it based on the schematics. > > I wouldn't trust the schematics too much. They are rather generic, see > the Ethernet page, for instance, showing *different* PHYs, not just the > ones used. > For the DRAM the Pine64 schematic does not even tell the DRAM chip used, > the name under the chip is just describing the package. > >> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-) > > Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV > more is well within the tolerance ;-) > >>>> +®_dcdc6 { >>>> + regulator-always-on; >>>> + regulator-min-microvolt = <1100000>; >>>> + regulator-max-microvolt = <1100000>; >>>> + regulator-name = "vdd-sys"; >>>> +}; >>>> + >>>> +®_dldo1 { >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-hdmi"; >>>> +}; >>>> + >>>> +®_dldo2 { >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-mipi"; >>>> +}; >>>> + >>>> +®_dldo3 { >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "avdd-csi"; >>>> +}; > > If you stick to the schematic, this should be 2.8V. Agreed. But... >>>> + >>>> +®_dldo4 { >>>> + regulator-min-microvolt = <3300000>; >>>> + regulator-max-microvolt = <3300000>; >>>> + regulator-name = "vcc-wifi"; >>>> +}; >>>> + >>>> +®_eldo1 { >>>> + regulator-min-microvolt = <1800000>; >>>> + regulator-max-microvolt = <1800000>; >>>> + regulator-name = "cpvdd"; >>>> +}; >>>> + >>>> +®_eldo3 { >>>> + regulator-min-microvolt = <1800000>; >>>> + regulator-max-microvolt = <1800000>; >>>> + regulator-name = "vdd-1v8-csi"; >>>> +}; > > The schematic lists 1.2V/1.5V/1.8V here, so should we have a range? This and avdd-csi really depends on the camera module used. Maybe this should be left to an overlay. > >>>> + >>>> +®_fldo1 { >>>> + regulator-min-microvolt = <1200000>; >>>> + regulator-max-microvolt = <1200000>; >>>> + regulator-name = "vcc-1v2-hsic"; >>>> +}; >>>> + >>>> +®_fldo2 { >>>> + regulator-always-on; > > Why do we need to turn this on? Upstream firmware does not use the > arisc, so it can stay off. > Also in general I think Linux should not tinker with the management > processor at all. I'm not sure, but I think at least one SoC had failed to work without this powered on. If that is the case with the A64, then please leave a comment saying so. Otherwise let it stay off. ChenYu > Cheers, > Andre. > >>>> + regulator-min-microvolt = <1100000>; >>>> + regulator-max-microvolt = <1100000>; >>>> + regulator-name = "vdd-cpus"; >>>> +}; >>>> + >>>> +®_rtc_ldo { >>>> + regulator-name = "vcc-rtc"; >>>> +}; >>>> + >>>> /* On Exp and Euler connectors */ >>>> &uart0 { >>>> pinctrl-names = "default"; >>>>