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

[icenowy at aosc.io]

在 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 at arm.com> 写到:
>>> 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 at 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;
>>>> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel