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

Hi Simon,

>>>>>
>>>>> This is reading a lot of DT stuff very early, which may be slow. It is
>>>>> also reading from the DT in the bind() step which we sometimes have to
>>>>> do, but try to avoid.
>>>>
>>>> Could we set up the livetree pre-bind? What about MMU? On armv8 at least
>>>> this would have a huge impact on performance. I've done some
>>>> measurements and there is at least 1 order of magnitude difference
>>>> between parsing FDT with no caches vs parsing livetree with, it's huge.
>>>
>>> That seems like a great idea to me, in general. The fact that SPL sets
>>> up the MMU on armv8 makes it more practical.
>>
>> Well, on qcom we don't use SPL (yet?), we did have a cyclical dependency
>> since we rely on DTB for the memory layout, although I have some patches
>> to do all the memory parsing in board_fdt_blob_setup() since that's
>> needed for multi-dtb FIT. So I guess we could enable caches at the same
>> time.
> 
> Yes...it seems that enabling cache in SPL has become common on armv8.
> 
> As to the memory layout, I'm not sure what is happening there, but it
> seems that the DT does not describe it in general (at least not until
> U-Boot adds the nodes).

I suppose this depends on the platform. On Qualcomm we use DT as the 
source of truth as it lets us support many platforms (with totally 
different memory maps) with a single U-Boot binary, at least for 
development this is quite nice.
> 
>>>
>>> But for this series I believe we are going to have to define what
>>> happens in what phase. We have power_init_board() which is the old way
>>> of doing this...but perhaps we could use that as a way to start up
>>> regulators which are needed.
>>>
>>> As to my question about whether this happens in SPL / pre-reloc /
>>> proper, I forgot that we have the bootph tags for that, so it should
>>> be fine. The main issue is that in U-Boot proper we will re-init the
>>> regulators even though that has already been done. Probably that can
>>> be handled by Kconfig or a flag in SPL handoff.
>>
>> Ensuring that it isn't done multiple times sounds like the right
>> approach to me.
> 
> OK...I wonder how we can solve this. Needs some though.
> 
> 
>>>
>>>
>>>>>
>>>>> Also this seems to happen in SPL and again pre-reloc and again in
>>>>> U-Boot post-reloc?
>>>>>
>>>>> Should we have a step in the init sequence where we set up the
>>>>> regulators, by calling regulators_enable_boot_on() ?
> 
> Regards,
> Simon

-- 
// Caleb (they/them)