On 2021-12-22 10:40, Sascha Hauer wrote:

On Mon, Dec 20, 2021 at 12:53:58PM +0000, Mark Brown wrote:

quoted

On Mon, Dec 20, 2021 at 10:44:35AM +0100, Sascha Hauer wrote:

quoted

Well, all true and on one specific board the regulator is indeed not
optional. However, on all other power domains that don't need a
regulator and all other boards and all other SoCs this driver is used we
now get:

This seems unlikely to be board specific, if the chip requires power the
chip requires power.  If there are power domains that don't take
external supplies then they shouldn't be requesting any regulators and
should be fixed.

quoted

[    0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator

It seems vanishingly unlikely that the SoC takes a single supply called
"power" shared by everything in the SoC but that is what the code
appears to be requesting - the power domains should be requesting the
supplies they actually use, and as ever the supplies should be named
such that someone looking at the schematic can hook them up.  The
general recommendation is to use the names used in the datasheet.

Ok. I'll change the patch in a way that only for the GPU power domain on
rk3568 a supply is requested. That's the one power domain I know that a
regulator is needed. I'm sure there are more, if not on rk3568 then
probably on other SoCs the driver handles. Once we notice that other
domains need a supply we'll have to add the supply name to driver data
for that domain.

Certainly RK3399 (and I guess RK3288 too) suffers from the same 
priority-inversion issue of being unaware that VD_GPU needs power before 
PD_GPU can be successfully turned on to probe the GPU to claim and 
enable the regulator (via "mali-supply" for DVFS purposes) that needed 
to be on in the first place. Currently all the boards are bodging around 
this with "regulator-always-on" (e.g. commit 06b2818678d9).

Thanks,
Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel