[PATCH] arm: dts: sun50i-h6-orangepi-3: disable aldo2 regulator

[Maxim Karasev]

Hi. Thanks for explanation, I'm new to mailing lists, so I appreciate this.

Also I'm happy to hear that any work is done to address that issue.

>I was thinking about adding a TF-A build option that would skip regulator
>setup altogether, which would then become standard in some happy feature
>when U-Boot takes proper care of regulators.
>Maybe you can just disable this already in your TF-A build, to see if that
>fixes your issues?

It believe it should fix that exact issue, but in my situation (I'm a distro packager) such solutions (having a several atf versions) are unacceptable.

>In any case your patch below is unfortunately not a solution.

It's rather the most painless workaround in my case.

On October 13, 2021 7:25:36 PM GMT+03:00, Andre Przywara <andre.przywara at arm.com> wrote:
>On Tue,  7 Sep 2021 19:23:26 +0300
>Maxim Karasev <begs at disroot.org> wrote:
>
>Hi Maxim,
>
>please add the respective maintainers in To: or CC:, as reported by
>scripts/get_maintainer.pl.
>Also please add at least "sunxi" or "allwinner" somewhere in the subject
>line, that helps the reduce the response time ;-)
>
>> Mainline TF-A has a broken behavior - it enables all used AXP regulator
>> outputs, without much reason.
>
>Without that code you could not use most peripherals powered by the PMIC
>in U-Boot, the PHY being the most prominent one.
>But yes, it's a long standing issue - at least for the OPi3, which seems
>to be one of the few boards really having an issue with that.
>And the real solution is to drop the regulator handling in TF-A, and use a
>DM compliant AXP driver in U-Boot. Samuel's recent work should have
>brought that a bit closer, but it's still quite some work ahead:
>https://oftc.irclog.whitequark.org/linux-sunxi/2021-10-11#30291278;
>
>> It breaks PHY on Orange Pi 3 and other boards, because they a specific
>> power-on sequence is required. aldo2 which is enabled by TF-A is just a
>> half of PHY's power and the other half that is untouched by TF-A must be
>> enabled simultaneously (even a small difference may cause a break-down).
>
>I wish OrangePi would have designed a bit less of a special snowflake
>here.
>
>> If not TF-A, kernel driver would do everything correctly.
>> 
>> However, some boards rely on this behavior, so it's impossible to get
>> rid of it.
>> 
>> TF-A recently started checking regulator status, and now it enables a
>> regulator only if it's status is "okay". Disabling regulator in U-Boot's
>> dts workarounds the problem.
>
>The problem is that there is no such thing as "U-Boot's dts". I always use
>that DT to pass it on to the kernel (via $fdtcontroladdr), and this is the
>designated way to use UEFI. And that is just one reason we don't accept DT
>hacks just in U-Boot.
>

>
>Cheers,
>Andre
>
>> ---
>>  arch/arm/dts/sun50i-h6-orangepi-3.dts | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/arch/arm/dts/sun50i-h6-orangepi-3.dts b/arch/arm/dts/sun50i-h6-orangepi-3.dts
>> index 7e83f6146f..9f91e4ec88 100644
>> --- a/arch/arm/dts/sun50i-h6-orangepi-3.dts
>> +++ b/arch/arm/dts/sun50i-h6-orangepi-3.dts
>> @@ -207,6 +207,10 @@
>>  				regulator-min-microvolt = <3300000>;
>>  				regulator-max-microvolt = <3300000>;
>>  				regulator-name = "vcc33-audio-tv-ephy-mac";
>> +				/* This regulator must be enabled by the kernel,
>> +				 * not by u-boot or TF-A, otherwise power-on
>> +				 * sequence will be wrong and PHY won't work */
>> +				status = "disabled";
>>  			};
>>  
>>  			/* ALDO3 is shorted to CLDO1 */
>