Re: [PATCH 1/4] regulator: core: Support trying to get close to a certain voltage
From: Doug Anderson
Date: Mon Dec 15 2014 - 17:11:12 EST
On Fri, Dec 12, 2014 at 4:59 AM, Mark Brown <broonie@xxxxxxxxxx> wrote:
>> > There's also the potential
>> > performance considerations for the DVS type applications now I think
>> > about it.
>> Iterating through voltages is really that slow? If so, perhaps we
>> could add some caching to keep track of what voltage we actually got
>> last time... I could also add an optimization to try the exact
>> requested voltage right away...
> Applications like DVS get pretty performance sensitive and for a
> regulator with high resolution if you're trying to hit a voltage at the
> top of the range you could be iterating over a hundred or more values.
OK, you've convinced me. :)
> Perhaps doing something based on the various factorings out of the
> voltage mapping would do the trick, add a new op for getting to the
> closest voltage?
I'd really rather add a new op because I think it would mean that all
the old regulators that don't implement the op would be slow all of a
I looked at trying to refactor everything, but I think the answer is
that I should drop my patch and consider the existing
regulator_set_voltage_tol() experience good enough. While I could go
through and try to make regulator_set_voltage_tol() better:
1. It fixes no issues that I know of. On all boards that I've worked
with it is possible to make VMMC and VQMMC exactly equal.
2. As you said, regulator_set_voltage_tol() is on the critical path
for CPUfreq and the existing code is heavily optimized to work fast on
a large number of different types of regulators. Trying to replicate
that without huge code duplication and without any bugs would be
I'll spin my MMC patch to use regulator_set_voltage_tol(). If Ulf
responds and says that he'd like to more accurately specify the
min/max voltage then I'll post up a new function using a scheme like
regulator_set_voltage_tol() but asymmetric.
As always, thanks for your great feedback!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/