regulator voltage aggregation

regulator voltage aggregation

[Bobby Crabtree]

I'm looking to upstream a new feature in which the regulator core
aggregates voltage requests from multiple consumers and applies the best
fitting voltage (e.g. max voltage) to a shared supply. The core would
recompute the best fitting voltage when a consumer requests a voltage
change or requests to enable/disable the regulator (similar logic to
DRMS).

The reason we need this feature is for power savings. It would allow two
or more consumers to "vote" on a voltage that's lower than the normal
operating voltage.

I've got a couple implementations in mind.

1. Introduce a new API:

int regulator_set_optimum_voltage(struct regulator *regulator,
                int min_uV, int max_uV);

2. Add a flag to the regulation_constraints structure and reuse the
existing regulator_set_voltage API.

struct regulation_constraints {
        ...
        unsigned aggregate_uV:1;
        ...
};

Does this sound like a reasonable feature? And if so, are there any
preferences as to how the feature is implemented and exposed?

Bobby Crabtree

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: regulator voltage aggregation

[Mark Brown]

On Tue, Aug 17, 2010 at 11:06:10AM -0700, Bobby Crabtree wrote:
> I'm looking to upstream a new feature in which the regulator core
> aggregates voltage requests from multiple consumers and applies the best
> fitting voltage (e.g. max voltage) to a shared supply. The core would

It's unlikely that the highest voltage would ever be the best choice...

> recompute the best fitting voltage when a consumer requests a voltage
> change or requests to enable/disable the regulator (similar logic to
> DRMS).

> The reason we need this feature is for power savings. It would allow two
> or more consumers to "vote" on a voltage that's lower than the normal
> operating voltage.

This was actually a feature of the regulator API when originally
proposed, it got dropped for ease of review but there's some remanants
of this in the code so it shouldn't be hard to resurrect.  Whenever a
voltage was set the code stored the range on the consumer then iterated
over all consumers applying their ranges plus the machine constraints
rather than just using the immediate value.

> 1. Introduce a new API:

> int regulator_set_optimum_voltage(struct regulator *regulator,
>                 int min_uV, int max_uV);

Why would you want to do this?  This is just the same arguments as the
standard regulator_set_voltage() call and if we're ever setting anything
other than the optimal voltage we probably ought to just stop doing
that.

> 2. Add a flag to the regulation_constraints structure and reuse the
> existing regulator_set_voltage API.

> struct regulation_constraints {
>         ...
>         unsigned aggregate_uV:1;
>         ...
> };

> Does this sound like a reasonable feature? And if so, are there any
> preferences as to how the feature is implemented and exposed?

If we were going to add something for this it should be a capability,
however I don't think there's any need to add anything to the API since
this is the only sane interpretation of allowing voltage changes on a
regulator with more than one consumer.

Re: regulator voltage aggregation

[Bobby Crabtree]

Mark Brown wrote:
> On Tue, Aug 17, 2010 at 11:06:10AM -0700, Bobby Crabtree wrote:
>> I'm looking to upstream a new feature in which the regulator core
>> aggregates voltage requests from multiple consumers and applies the best
>> fitting voltage (e.g. max voltage) to a shared supply. The core would
> 
> It's unlikely that the highest voltage would ever be the best choice...
> 
We do need the highest voltage. Let's say we have two consumers
(A and B). Both require 1.3V for "normal" operations. Then let's
say that consumer A can save power by reducing the voltage to 1.1V
(but it doesn't require 1.1V). If the core were to immediately apply
1.1V, then the 1.3V requirement of consumer B would not be satisfied.

>> recompute the best fitting voltage when a consumer requests a voltage
>> change or requests to enable/disable the regulator (similar logic to
>> DRMS).
> 
>> The reason we need this feature is for power savings. It would allow two
>> or more consumers to "vote" on a voltage that's lower than the normal
>> operating voltage.
> 
> This was actually a feature of the regulator API when originally
> proposed, it got dropped for ease of review but there's some remanants
> of this in the code so it shouldn't be hard to resurrect.  Whenever a
> voltage was set the code stored the range on the consumer then iterated
> over all consumers applying their ranges plus the machine constraints
> rather than just using the immediate value.
> 
I noticed some of the remnants. But I'm not sure I follow what you
are saying. What range would the core actually propagate to the
driver? The minimum min_uV and the maximum max_uV? We need the core
to propagate the maximum min_uV and the maximum max_uV.

>> 1. Introduce a new API:
> 
>> int regulator_set_optimum_voltage(struct regulator *regulator,
>>                 int min_uV, int max_uV);
> 
> Why would you want to do this?  This is just the same arguments as the
> standard regulator_set_voltage() call and if we're ever setting anything
> other than the optimal voltage we probably ought to just stop doing
> that.
> 
"Optimum" was a bad choice of words. Seems that a new API isn't
preferred, so let's scrap this option.

Re: regulator voltage aggregation

[Mark Brown]

On Tue, Aug 17, 2010 at 12:33:33PM -0700, Bobby Crabtree wrote:
> Mark Brown wrote:

> > It's unlikely that the highest voltage would ever be the best choice...

> We do need the highest voltage. Let's say we have two consumers
> (A and B). Both require 1.3V for "normal" operations. Then let's
> say that consumer A can save power by reducing the voltage to 1.1V
> (but it doesn't require 1.1V). If the core were to immediately apply
> 1.1V, then the 1.3V requirement of consumer B would not be satisfied.

That's not the highest voltage, that's the minimum voltage that
satisfies all the requests that the consumers have made.  The consumer
which requires 1.1V will have requested 1.1V up to, say, 3.3V.  The
consumer that requested 1.3V will have requested, say, 1.3-1.8V and
let's say the machine constraints will allow at least these ranges.
1.3V is the lowest voltage that hits all the constraints, but it's still
lower than any of the maxima.  When you've got multiple things
specifying a voltage constraint you need to apply the most restrictive
combination of constraints but it still makes sense to pick the minimum
voltage we can deliver from the range that's left after doing that.

> > This was actually a feature of the regulator API when originally
> > proposed, it got dropped for ease of review but there's some remanants
> > of this in the code so it shouldn't be hard to resurrect.  Whenever a
> > voltage was set the code stored the range on the consumer then iterated
> > over all consumers applying their ranges plus the machine constraints
> > rather than just using the immediate value.

> I noticed some of the remnants. But I'm not sure I follow what you
> are saying. What range would the core actually propagate to the
> driver? The minimum min_uV and the maximum max_uV? We need the core
> to propagate the maximum min_uV and the maximum max_uV.

No, it'd be the maximum min_uV and the minimum max_uV - this is already
happening when the constraints from the machine are applied, it'd just
be applying a wider set of constraints.  In principle all we need to do
is remember the voltage constraints that individual consumers set and
then iterate over all the enabled consumers when one of them changes its
range (or is enabled/disabled) instead of just taking the immediate
values from the consumer.

Re: regulator voltage aggregation

[Bobby Crabtree]

Mark Brown wrote:
> On Tue, Aug 17, 2010 at 12:33:33PM -0700, Bobby Crabtree wrote:
>> Mark Brown wrote:
> 
>>> It's unlikely that the highest voltage would ever be the best choice...
> 
>> We do need the highest voltage. Let's say we have two consumers
>> (A and B). Both require 1.3V for "normal" operations. Then let's
>> say that consumer A can save power by reducing the voltage to 1.1V
>> (but it doesn't require 1.1V). If the core were to immediately apply
>> 1.1V, then the 1.3V requirement of consumer B would not be satisfied.
> 
> That's not the highest voltage, that's the minimum voltage that
> satisfies all the requests that the consumers have made.  The consumer
> which requires 1.1V will have requested 1.1V up to, say, 3.3V.  The
> consumer that requested 1.3V will have requested, say, 1.3-1.8V and
> let's say the machine constraints will allow at least these ranges.
> 1.3V is the lowest voltage that hits all the constraints, but it's still
> lower than any of the maxima.
> 
Aah. I get it now.

>>> This was actually a feature of the regulator API when originally
>>> proposed, it got dropped for ease of review but there's some remanants
>>> of this in the code so it shouldn't be hard to resurrect.  Whenever a
>>> voltage was set the code stored the range on the consumer then iterated
>>> over all consumers applying their ranges plus the machine constraints
>>> rather than just using the immediate value.
> 
>> I noticed some of the remnants. But I'm not sure I follow what you
>> are saying. What range would the core actually propagate to the
>> driver? The minimum min_uV and the maximum max_uV? We need the core
>> to propagate the maximum min_uV and the maximum max_uV.
> 
> No, it'd be the maximum min_uV and the minimum max_uV - this is already
> happening when the constraints from the machine are applied, it'd just
> be applying a wider set of constraints.  In principle all we need to do
> is remember the voltage constraints that individual consumers set and
> then iterate over all the enabled consumers when one of them changes its
> range (or is enabled/disabled) instead of just taking the immediate
> values from the consumer.

Got it.

Only remaining question I have is if the aggregation of
multiple consumer constraints should be the default (and only)
behavior. Or should we introduce a new flag to the
regulator_constraints structure that tells the core to aggregate
consumer voltages constraints?

Re: regulator voltage aggregation

[Mark Brown]

On Tue, Aug 17, 2010 at 01:44:36PM -0700, Bobby Crabtree wrote:

> Only remaining question I have is if the aggregation of
> multiple consumer constraints should be the default (and only)
> behavior. Or should we introduce a new flag to the
> regulator_constraints structure that tells the core to aggregate
> consumer voltages constraints?

I'd say make it the only behaviour - if there is only one consumer it
decays into the same behaviour as we have currently, and since voltage
changes need to be explicitly enabled by the machine constraints it
should not affect any existing machines.

One thing to take account of is an attempt to set a constraint which
can't be accomodated by the other enabled devices, or enable a device
which has constraints outside the currently allowed range.

Re: regulator voltage aggregation

[Alan Cox]

O> int regulator_set_optimum_voltage(struct regulator *regulator,
>                 int min_uV, int max_uV);

Pedantic hat on - how can it be optimum if its a range ? (and an
adjective but that is really pedantic) ;))

Surely it's not the optimal value, it's the range at which it works at
all you are defining (between off, and escaping smoke).

set_voltage_range() sounds rather more natural to me.

Alan

Re: regulator voltage aggregation

[Mark Brown]

On Tue, Aug 17, 2010 at 07:28:06PM +0100, Alan Cox wrote:
> O> int regulator_set_optimum_voltage(struct regulator *regulator,
> >                 int min_uV, int max_uV);

> Pedantic hat on - how can it be optimum if its a range ? (and an
> adjective but that is really pedantic) ;))

> Surely it's not the optimal value, it's the range at which it works at
> all you are defining (between off, and escaping smoke).

> set_voltage_range() sounds rather more natural to me.

The regulator API always specifies voltages in ranges, picking the
lowest possible voltage from the range.

One reason for this is that it allows us to finesse the mismatches
between the fixed steps that regulators offer and the requirements of
consumers - we don't needlessly fail to set a voltage due to a few
milivolts difference that the consumer doesn't care about.  The other
reason is that it maps very well onto a lot of applications which do
have fairly wide acceptable ranges.  For things like DVFS lowering the
frequency will typically reduce the minimum voltage required by the
device but will not affect the maximum voltage it can tolerate so we
allow the driver to specify the full range it can operate at and then
deliver the maximum power saving we can within the constraints of the
system.