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

[Svyatoslav Ryhel]

пн, 29 лип. 2024 р. о 13:42 Marek Vasut <marex at denx.de> пише:
>
> On 7/29/24 7:38 AM, Svyatoslav Ryhel wrote:
>
> [...]
>
> >> The PMIC is on I2C, DM_PMIC enabled in SPL, both buck4 and buck5
> >> regulators are enabled in SPL, have regulator-always-on and
> >> regulator-boot-on and bootph-pre-ram properties.
> >>
> >> This seems similar enough, right ?
> >>
> > Yes, though SPL must remain as small as possible and you propose add
> > there i2c driver,  PMIC driver, PMIC regulator drivers, PMIC GPIO
> > drivers along with relocation of all this stuff. It is not optimal at
> > all.
>
> Sure, if you do use DM_PMIC for PMIC on I2C bus, then you also need
> DM_I2C . You can also do non-DM PMIC configuration in SPL, non-DM in SPL
> is allowed.
>
Thanks for explaining an obvious stuff, it seems that we are talking
on different languages.

> >> What is the problem you observe on tegra 3 ?
> > i2c line fails since it probes in spl with your patch, but it does not
> > relocate and then probes once more after relocation. Probe fails along
> > with all devices on same line.
>
> Could it be that you either have to:
> - Add DM_I2C to tegra 3 SPL
> - Remove bootph-* from DT to remove the regulator node from SPL
> - /delete-property/ regulator-always-on; and /delete-property/
> regulator-boot-on; in -u-boot.dtsi to prevent the regulator from being
> enabled in SPL ?
>
Obviously NO, you propose nonsense. Same dts is used for both stages.
And I have to add hack-ish stuff just because you wanna introduce code
which causes known regressions.

> regulator-always-on means the regulator has to be enabled
> unconditionally, and the system software has no other way to test
> whether the regulator is enabled but access the PMIC, so that is why the
> regulator is probed, even if it is early.
Thanks for explaining an obvious stuff, it seems that we are talking
on different languages.

Anyway,

"We must not probe things as we go. There might be other
dependencies not yet bound. It may also take some time. This is not
following driver model design, sorry.

So please think of a way to do this properly."