On Wed, Feb 21, 2024 at 12:44 AM Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Tue, Feb 20, 2024 at 10:21:04PM +0100, Konrad Dybcio wrote: > > On 20.02.2024 13:47, Mark Brown wrote: > > > > Are you *sure* this actually happens (and that the regulators don't > > > figure it out by themselves), especially given that the consumers are > > > just specifying the load once rather than varying it dynamically at > > > runtime which is supposed to be the use case for this API? This API is > > > intended to be used dynamically, if the regulator always needs to be in > > > a particular mode just configure that statically. > > > *AFAIU* > > > The regulators aggregate the requested current (there may be > > multiple consumers) and then it's decided if it's high enough > > to jump into HPM. > > Yes, that's the theory - I just question if it actually does something > useful in practice. Between regulators getting more and more able to > figure out mode switching autonomously based on load monitoring and them > getting more efficient it's become very unclear if this actually > accomplishes anything, the only usage is the Qualcomm stuff and that's > all really unsophisticated and has an air of something that's being > cut'n'pasted forwards rather than delivering practical results. There > is some value at ultra low loads, but that's more for suspend modes than > for actual use. Removing it would be out of scope for this series and I don't really want to introduce any undefined behavior when doing a big development like that. I'll think about it separately. Bart
