[Linux-stm32] stm32mp1xx: use of reg11, reg18 and vdd_usb rails

[Sean Nyekjaer]

Hi Fabrice,

[…]

> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> I can fix it by removing the vdd_usb from the usb33 supply[3]:
>>>> 
>>>> This will break all implementations that rely on ID/Vbus pins on MP15.
>>> 
>>> OK. So we will have to use Mark’s suggestion and force it on.
>> 
>> I noticed Mark's reply after I actually answered on friday.
>> 
>> If low power is out of scope, that may be a workaround. As he states,
>> it's not ideal.
>> 
> 
> We are running with this to avoid further hardware damage.
> 
>> Better approach (likely more reliable) would be to have some way to deal
>> with hardware constraints as he suggested, e.g. not to disable a
>> regulator (reg18), unless another regulator is off (vdd_usb).
> 
> Agree.

Should I add a lock in stm32_pwr.c to protect the stm32 hardware?

[…]

> 
>> 
>> static int stm32_usbphyc_regulators_enable(struct stm32_usbphyc *usbphyc)
>> {
>> + struct stm32_usbphyc_phy *usbphyc_phy = usbphyc->phys[0];
>> int ret;
>> 
>> ...
>> ret = regulator_enable(usbphyc->vdda1v8);
>> if (ret)
>> goto vdda1v1_disable;
>> 
>> + ret = regulator_enable(usbphyc_phy->phy->pwr);
>> + if (ret)
>> + goto vdda1v8_disable;
>> +
>> return 0;
>> 
>> +vdda1v8_disable:
>> + dev_info(usbphyc->dev, "vdda1v8 disable\n");
>> + regulator_disable(usbphyc->vdda1v8);
>> 
>> And the opposite in stm32_usbphyc_regulators_disable().
>> 
>> Doing it, will initialize vdd_usb regulator ref counting, e.g. 1 then 0
>> when registering the USBPHYC clock. So it will be managed in the correct
>> order (turned off before reg18).
>> 
>> It will work, if and only if, vdd_usb isn't shared on the board, with
>> another function, this could enforce from phy driver the correct
>> enable/disable sequence.
> 
> One could share the vdd_usb on the board. In those cases we need to avoid powering reg18 off.
> When entering stm32_usbphyc_regulators_disable() and the phy is still powered on we should block power off.
> In my first mail I added a warning if the this happens...
> 
>> 
>> If the vdd_usb regulator is share with some other function, then I see
>> no other way, but to look into Mark's suggestion to better control
>> hardware constraints.
>> 
>> Hope this helps,
>> Please clarify above points,
>> Best Regards,
>> Fabrice
>> 
> 
> 


/Sean

[…]