On 5/2/23 13:53, Marek Vasut wrote:
On 5/2/23 12:41, Eugen Hristev wrote:
On 5/2/23 12:18, Marek Vasut wrote:
On 5/2/23 08:51, Eugen Hristev wrote:
regulator_set_enable_if_allowed already handles cases when the
regulator is already enabled, or already disabled, and does not
treat these as errors.
With this change, the driver can work correctly even if the regulator
is already taken or already disabled by another consumer.
Can that ever happen for Vbus supply (the 5V coming out of USB port) ?
Can you elaborate how ?
Hi Marek,
Hi,
Recently I developed a series of patches to add a reference counter
for regulators :
https://marc.info/?l=u-boot&m=168191189309879&w=2
Ah yes, this is super cool stuff, thanks !
But with this series, having a regulator already enabled or already
disabled results in an error returned by regulator_set_enable
Hence, one option is to replace calls with
regulator_set_enable_if_allowed
There is a discussion ongoing here:
https://marc.info/?l=u-boot&m=168295920316621&w=2
Pardon my ignorance, but uh ... how does Linux deal with regulators
which are enabled by prior stage, like U-Boot ? Does it set their enable
refcount to =1 or =0 ?
Please correct me if I am wrong, I did not dig too much into regulators,
but , from my understanding :
Normally software(in this case Linux) reads the state of the regulator
when it's probed, and sets the refcount accordingly. If the state cannot
be read then regulator-boot-on tells Linux that it should have been left
enabled by prior stage
In Uboot I believe that regulators that have 'regulator-boot-on' are
added to a list and set to enable during probe, and the probe is forced
even if Uboot normally uses lazy probing (should have the same behavior
for regulator-always-on property)
So if a regulator is enabled by an initial stage but it's not described
with 'regulator-boot-on' , appears to be a bad hardware description in DT.
