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.
--

[ message continues ]

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
--

[ message continues ]

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.
--

[ message continues ]

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

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

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.
--

[ message continues ]

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
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
"Optimum" was a bad choice of words. Seems that a new API isn't
preferred, so let's scrap this option.

--

[ message continues ]

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

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.
--

[ message continues ]

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?
--

[ message continues ]

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.
--

[ message continues ]