Re: [PATCH 3/7] arm64: dts: qcom: sdm660-xiaomi-lavender: fix regulator and SD settings

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 1/25/26 12:10 PM, Dmitry Baryshkov wrote:
> On Fri, Jan 23, 2026 at 11:11:50PM +0300, Alexey Minnekhanov wrote:
>> On 23.01.2026 12:26, Konrad Dybcio wrote:
>>> On 1/22/26 5:44 PM, Alexey Minnekhanov wrote:
>>>> On 21.01.2026 14:27, Konrad Dybcio wrote:
>>>>> On 1/20/26 7:00 PM, Gianluca Boiano wrote:
>>>>>> Fix regulator configurations to ensure stable operation:
>>>>>> - vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY
>>>>>>     PLL operation
>>>>>
>>>>> The driver needs to be fixed instead, as it should perform a
>>>>> regulator_set_load()
>>>>
>>>>
>>>> Also change done by me in [1] with more detailed explanation:
>>>>
>>>> Since the commit f05ab10 ("arm64: dts: qcom: sdm660-lavender:
>>>> Add missing USB phy supply") previously untouched by Linux regulator
>>>> l10a is now used, but it exposed a bug from initial porting: when
>>>> booting with USB cable inserted, or booting without cable and
>>>> inserting it later, board reboots.
>>>
>>> FYI this shouldn't be required with the upstream driver, I don't think
>>> the core calls .set_load(0) and RPM isn't notified of a current
>>> requirement change unless that happens (qcom_smd-regulator.c)
>>>
>>> In the power grid, I see (current values representing the peak):
>>>
>>> -- USB2
>>> VDDA (3.1 V - vdda-phy-dpdm-supply) - 60mA
>>> VDDA (1.8 V - vdda-pll-supply) - 30mA
>>>
>>> VDD (?) - 11.4 mA
>>> VDDA_DVDD (?) - 35 mA
>>>
>>> -- USB3
>>> VDDA (1.8 V) - 14 mA
>>> VDDA_CORE - 68.6 mA
>>>
>>> +Dmitry poked at 660 in the past
>>>
>>> Konrad
>>>
>>
>> This is not needed e.g on sdm630-sony-nile-pioneer, it's booting fine
>> without system-load with USB cable inserted. Maybe IFC board doesn't
>> require this too. Seems to be xiaomi specific thing again?
>>
>> Alternative is to not touch L10A regulator (comment out vdda-pll-supply
>> from qusb2phy0 node and face the "phy@c012000: 'vdda-pll-supply' is a
>> required property" dtbs-check error again. Which we don't want to do of
>> course. And schematics say that vreg_l10a_1p8 is connected to at least:
>> VDD_USB1_HS_1P8, VDD_USB2_HS_1P8, QFPROM_PRG, VDDA_APC1_CS_1P8, VDD_PLL2_1,
>> VDD_PLL2_2.
> 
> It might be that there is an issue because of it being used for APC1
> too. I don't observe any issues on my IFC6560 board (where it is also
> connected to APC1).

Wait, what? The same line going to external ports and the CPU supply!?

> I'd suggest adding a dummy fixed regulator node as L10A and documenting
> that it is not to be touched by Linux on this device). We do this for
> some other "system" regulators on other devices.

I think that system-load may be fitting, but it needs a comment

Konrad