[PATCH 1/4] power: regulator: Trigger probe of regulators which are always-on or boot-on

[Marek Vasut]

On 9/12/24 3:00 AM, Simon Glass wrote:

Hello Simon,

>>>>> Also this seems to happen in SPL and again pre-reloc and again in
>>>>> U-Boot post-reloc?
>>>>
>>>> What does, the uclass post_bind ?
>>>
>>> I mean that this code will be called in SPL (if the regulators are in
>>> the DT there), U-Boot pre-reloc and post-reloc, each time turning on
>>> the regulators. We need a way to control that, don't we?
>>
>> I would assume that if those regulators are turned on once in the
>> earliest stage , turning them on again in the follow up stage would be a
>> noop ? This is the point of regulator-*-on, to keep the regulators on.
> 
> No, there is sometimes a particular sequence needed.

If the regulators are already enabled, enabling them again will be a 
noop, do you agree ?

[...]

>>> My concern is that this might cause us ordering problems. We perhaps
>>> want the regulators to be done first. If drivers are probed which use
>>> regulators, then presumably they will enable them. Consider this:
>>>
>>> - LED driver auto-probes
>>>      - probes I2C bus 2
>>>      - probes LDO1 which is autoset so turns on
>>> - LDO1 probes, but is already running
>>> - LDO2 probes, which is autoset so turns on
>>>
>>> So long as it is OK to enable the regulators in any order, then this
>>> seems fine. But is it? How do we handle the case where are particular
>>> sequence is needed?
>>
>> Did we finally arrive at the point where we need -EPROBE_DEFER alike
>> mechanism ?
> 
> Nope. But I am concerned that this patch is leading us there. bind()
> really needs to be as clean as possible. It is one of the design
> elements of driver model which Linux should adopt.
> 
> There is always a race to be the first to init something, move the
> init earlier, etc... I don't see any general need to init the
> regulators right at the start. It should be done in a separate
> function and be optional. I am happy to send a patch if you like.
I strongly disagree that regulators which are marked in DT as 
always-on/boot-on should somehow be treated as optional-on in U-Boot , 
no , they should not. They should be enabled by the regulator uclass 
core code, for every regulator which is marked that way. If they are not 
to be enabled, they should not be marked that way in DT.

While the board code may exercise some control over enabling regulators 
earlier, it should still be the default in the core code to enable such 
regulators unconditionally.

If the concern is ordering problems between regulators, then regulators 
have to define vin-supply to describe their upstream supply in DT, which 
should address the ordering problem. DTTO for clock and pinmux etc.