On Tue, Feb 20, 2024 at 12:22:42PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 6:50 PM Mark Brown <[email protected]> wrote:
> > On Fri, Feb 16, 2024 at 09:32:11PM +0100, Bartosz Golaszewski wrote:
> > > +static struct pci_pwrctl_wcn7850_vreg pci_pwrctl_wcn7850_vregs[] = {
> > > + {
> > > + .name = "vdd",
> > > + .load_uA = 16000,
> > > + },
> > I know a bunch of the QC stuff includes these load numbers but are they
> > actually doing anything constructive? It keeps coming up that they're
> > causing a bunch of work and it's not clear that they have any great
> > effect on modern systems.
> Yes, we have what is called a high-power mode and a low-power mode in
> regulators and these values are used to determine which one to use.
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.
On 20.02.2024 13:47, Mark Brown wrote:
> On Tue, Feb 20, 2024 at 12:22:42PM +0100, Bartosz Golaszewski wrote:
>> On Mon, Feb 19, 2024 at 6:50 PM Mark Brown <[email protected]> wrote:
>>> On Fri, Feb 16, 2024 at 09:32:11PM +0100, Bartosz Golaszewski wrote:
>
>>>> +static struct pci_pwrctl_wcn7850_vreg pci_pwrctl_wcn7850_vregs[] = {
>>>> + {
>>>> + .name = "vdd",
>>>> + .load_uA = 16000,
>>>> + },
>
>>> I know a bunch of the QC stuff includes these load numbers but are they
>>> actually doing anything constructive? It keeps coming up that they're
>>> causing a bunch of work and it's not clear that they have any great
>>> effect on modern systems.
>
>> Yes, we have what is called a high-power mode and a low-power mode in
>> regulators and these values are used to determine which one to use.
>
> 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.
Konrad
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.