[1/4] regulator: core: Support trying to get close to a certain voltage
diff mbox

Message ID 1418245085-9754-1-git-send-email-dianders@chromium.org
State New, archived
Headers show

Commit Message

Doug Anderson Dec. 10, 2014, 8:58 p.m. UTC
There are some cases where you'd like to set a voltage for a regulator
and a range of voltages are OK, but you'd really like to get as close
as you can to a specific voltage if at all possible.

The VQMMC (IO voltage) regulator for SD cards is the inspiration for
needing this function.  A few things about SD cards to justify its
need:

1. In old systems (before UHS), the VMMC and VQMMC were provided by
the same regulator.  That means that SD cards were all tested with
VMMC and VQMMC being exactly the same.  With UHS we need to have two
regulators providing VMMC and VQMMC.  For maximum compatibility, we'd
like to keep those two regulators providing the exact same voltage
when we're using "3.3V signaling".  Note: VMMC is managed with very
specific rules in the MMC core and we tend to pick the _highest_
supported voltage in range.

2. On UHS systems we'll eventually negotiate the IO voltage (VQMMC)
down to 1.8V.  Note that we don't provide a 1.8V reference voltage to
the SD card so it comes up with 1.8V on its own based on VMMC (perhaps
using an on-card LDO).  While the SD card spec says that VQMMC can be
1.7V to 1.95V, it seems best to try to get the closest voltage.
Trying to achieve 1.8V means that the card and controller drive the IO
lines (which are push-pull) with as close to the same voltage as
possible.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 drivers/regulator/core.c           | 62 ++++++++++++++++++++++++++++++++++++++
 include/linux/regulator/consumer.h |  9 ++++++
 2 files changed, 71 insertions(+)

Comments

Mark Brown Dec. 10, 2014, 11:53 p.m. UTC | #1
On Wed, Dec 10, 2014 at 12:58:02PM -0800, Doug Anderson wrote:
> There are some cases where you'd like to set a voltage for a regulator
> and a range of voltages are OK, but you'd really like to get as close
> as you can to a specific voltage if at all possible.

This looks like regulator_set_voltage_tol(), why not use that?  The spec
probably even has a number for the tolerance, or you can make one up.
Alexandru M Stan Dec. 11, 2014, 1:08 a.m. UTC | #2
The spec is from 1.7V to 1.95V, with 1.8V being ideal. It's not that
symmetric. But let's say that 0.1V is fine for tolerance(so 1.7-1.9V)

regulator_set_voltage_tol looks interesting, but i still think it's
not the appropriate thing to use in this case.

Imagine a board has a 1V-1.79 V regulator, we tell it to
regulator_set_voltage_tol(1800000,100000). It will try the 1.8V-1.9V
range, when it sees that it can't it'll fallback to 1.7V - 1.9V, and
it will just be lazy and pick the lowest of the range again:
1.7V(causing voltage drop issues because we're exactly at the minimum
of the spec). The correct voltage would be 1.79V

It's unfortunate that regulator_set_voltage was designed to always
pick the lowest voltage in that range. I understand that it's a power
efficiency thing, but it's not ideal in cases like this.

Alexandru Stan (amstan)


On Wed, Dec 10, 2014 at 3:53 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Dec 10, 2014 at 12:58:02PM -0800, Doug Anderson wrote:
>> There are some cases where you'd like to set a voltage for a regulator
>> and a range of voltages are OK, but you'd really like to get as close
>> as you can to a specific voltage if at all possible.
>
> This looks like regulator_set_voltage_tol(), why not use that?  The spec
> probably even has a number for the tolerance, or you can make one up.
Mark Brown Dec. 11, 2014, 12:31 p.m. UTC | #3
On Wed, Dec 10, 2014 at 05:08:37PM -0800, Alexandru Stan wrote:
> The spec is from 1.7V to 1.95V, with 1.8V being ideal. It's not that
> symmetric. But let's say that 0.1V is fine for tolerance(so 1.7-1.9V)

Don't top post so people reading your message have some context to give
them some idea what you are talking about.

> Imagine a board has a 1V-1.79 V regulator, we tell it to
> regulator_set_voltage_tol(1800000,100000). It will try the 1.8V-1.9V
> range, when it sees that it can't it'll fallback to 1.7V - 1.9V, and
> it will just be lazy and pick the lowest of the range again:
> 1.7V(causing voltage drop issues because we're exactly at the minimum
> of the spec). The correct voltage would be 1.79V

This is just an implementation detail, everything you're saying here
applies equally to any user specifying by tolerance rather than range.
If the reason for doing this is to fix that problem then a new API isn't
the way to go about it.
Doug Anderson Dec. 11, 2014, 4:09 p.m. UTC | #4
Mark,

On Thu, Dec 11, 2014 at 4:31 AM, Mark Brown <broonie@kernel.org> wrote:
> This is just an implementation detail, everything you're saying here
> applies equally to any user specifying by tolerance rather than range.
> If the reason for doing this is to fix that problem then a new API isn't
> the way to go about it.

OK, I'll give a shot at taking my code and using it as a new
implementation for regulator_set_voltage_tol().  In the SD card code
I'll pick some reasonable tolerances--they won't be exactly what the
spec says, but they ought to be good enough.  If Ulf comes back and
yells at me then we can revisit adding a new API.

Thanks!

-Doug
Mark Brown Dec. 11, 2014, 5:09 p.m. UTC | #5
On Thu, Dec 11, 2014 at 08:09:13AM -0800, Doug Anderson wrote:
> On Thu, Dec 11, 2014 at 4:31 AM, Mark Brown <broonie@kernel.org> wrote:

> > This is just an implementation detail, everything you're saying here
> > applies equally to any user specifying by tolerance rather than range.
> > If the reason for doing this is to fix that problem then a new API isn't
> > the way to go about it.

> OK, I'll give a shot at taking my code and using it as a new
> implementation for regulator_set_voltage_tol().  In the SD card code
> I'll pick some reasonable tolerances--they won't be exactly what the
> spec says, but they ought to be good enough.  If Ulf comes back and
> yells at me then we can revisit adding a new API.

OK, thanks.  Even if a new interface does get added the implementation
needs to be shared with that for setting by tolerance, they're doing the
same thing.

Please also bear in mind the need to handle shared supplies in your
implementation.
Doug Anderson Dec. 11, 2014, 7:55 p.m. UTC | #6
Mark,

On Thu, Dec 11, 2014 at 9:09 AM, Mark Brown <broonie@kernel.org> wrote:
>> OK, I'll give a shot at taking my code and using it as a new
>> implementation for regulator_set_voltage_tol().  In the SD card code
>> I'll pick some reasonable tolerances--they won't be exactly what the
>> spec says, but they ought to be good enough.  If Ulf comes back and
>> yells at me then we can revisit adding a new API.
>
> OK, thanks.  Even if a new interface does get added the implementation
> needs to be shared with that for setting by tolerance, they're doing the
> same thing.

Yup, exactly.  I'll admit wasn't originally aware of the tolerance API
and my first thought after your email was to reimplement it atop my
patch.  ...but just having tolerance right now also seems sane.


> Please also bear in mind the need to handle shared supplies in your
> implementation.

I'm being dense, can you give more details?  Do you want me to grab
the mutex or do something smarter like track the voltage / tolerance
requested by multiple clients and resolve them, or ...?

I didn't grab any mutex because I thought all of the attributes I was
looking at were unchanging.  If they're not then
regulator_is_supported_voltage() probably has a bug since I'm reading
roughly the same attributes that it is.  ...and in fact the flow of my
code is also amost the same as regulator_is_supported_voltage()...

-Doug
Mark Brown Dec. 12, 2014, 12:24 a.m. UTC | #7
On Thu, Dec 11, 2014 at 11:55:55AM -0800, Doug Anderson wrote:
> On Thu, Dec 11, 2014 at 9:09 AM, Mark Brown <broonie@kernel.org> wrote:

> > Please also bear in mind the need to handle shared supplies in your
> > implementation.

> I'm being dense, can you give more details?  Do you want me to grab
> the mutex or do something smarter like track the voltage / tolerance
> requested by multiple clients and resolve them, or ...?

I mean the latter - what happens if more than one consumer is trying to
use the regulator?  This is IIRC why _set_voltage_tol() uses the cheap
and nasty implementation it does.  There's also the potential
performance considerations for the DVS type applications now I think
about it.
Doug Anderson Dec. 12, 2014, 3:31 a.m. UTC | #8
Mark,

On Thu, Dec 11, 2014 at 4:24 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Dec 11, 2014 at 11:55:55AM -0800, Doug Anderson wrote:
>> On Thu, Dec 11, 2014 at 9:09 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > Please also bear in mind the need to handle shared supplies in your
>> > implementation.
>
>> I'm being dense, can you give more details?  Do you want me to grab
>> the mutex or do something smarter like track the voltage / tolerance
>> requested by multiple clients and resolve them, or ...?
>
> I mean the latter - what happens if more than one consumer is trying to
> use the regulator?  This is IIRC why _set_voltage_tol() uses the cheap
> and nasty implementation it does.

Ah, I see.  I don't think I've ever encountered a case where there
were two consumers for a regulator that actually requested voltages...

...but isn't regulator_set_voltage_tol() broken there?  If you have
two clients, A and B and a regulator that can go 1.0V to 5.0V in .05V
increments:

A requests 1.8V +/- .1V.  We get 1.8V
B requests 1.7V +/- .05V.

The above could be achievable with a voltage of 1.75V but it won't
work with the current regulator_set_voltage_tol() I think.


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

-Doug
Mark Brown Dec. 12, 2014, 12:59 p.m. UTC | #9
On Thu, Dec 11, 2014 at 07:31:43PM -0800, Doug Anderson wrote:
> On Thu, Dec 11, 2014 at 4:24 PM, Mark Brown <broonie@kernel.org> wrote:

> > I mean the latter - what happens if more than one consumer is trying to
> > use the regulator?  This is IIRC why _set_voltage_tol() uses the cheap
> > and nasty implementation it does.

> Ah, I see.  I don't think I've ever encountered a case where there
> were two consumers for a regulator that actually requested voltages...

> ...but isn't regulator_set_voltage_tol() broken there?  If you have
> two clients, A and B and a regulator that can go 1.0V to 5.0V in .05V
> increments:

> A requests 1.8V +/- .1V.  We get 1.8V
> B requests 1.7V +/- .05V.

> The above could be achievable with a voltage of 1.75V but it won't
> work with the current regulator_set_voltage_tol() I think.

Yeah, it's not perfect but it'll work most of the time.

> > 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.
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?
Doug Anderson Dec. 15, 2014, 10:11 p.m. UTC | #10
Mark,

On Fri, Dec 12, 2014 at 4:59 AM, Mark Brown <broonie@kernel.org> 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
sudden.  :(


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


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!

-Doug
Mark Brown Dec. 16, 2014, 1:13 p.m. UTC | #11
On Mon, Dec 15, 2014 at 02:11:02PM -0800, Doug Anderson wrote:
> On Fri, Dec 12, 2014 at 4:59 AM, Mark Brown <broonie@kernel.org> wrote:

> > 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
> sudden.  :(

Assuming there's a not missing there...  I don't think it's quite that
bad, most regulators do use one of the standard mapping functions and
for those that are likely to matter for performance there's usually a
calculation rather than a lookup table.  That said...

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

...I do agree that the current situation is probably adequate though,
the optimisation would be nice but it's mainly going to benefit corner
cases.

Patch
diff mbox

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e225711..ce91b20 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2664,6 +2664,68 @@  out2:
 EXPORT_SYMBOL_GPL(regulator_set_voltage);
 
 /**
+ * regulator_set_closest_voltage - set voltage trying to reach a certain one.
+ * @regulator: regulator source
+ * @min_uV: Minimum required voltage in uV
+ * @ideal_uV: Try to get as close to this voltage as possible
+ * @max_uV: Maximum acceptable voltage in uV
+ *
+ * This function is useful in cases where we want to try to get as close to
+ * a target voltage as possible but we would accept other voltages as fallback.
+ */
+int regulator_set_closest_voltage(struct regulator *regulator, int min_uV,
+				  int ideal_uV, int max_uV)
+{
+	int best_uV, delta, best_delta;
+	int i, voltages, ret;
+	struct regulator_dev *rdev = regulator->rdev;
+
+	if (ideal_uV < min_uV || ideal_uV > max_uV)
+		return -EINVAL;
+
+	/* Handle continuous ranges */
+	if (rdev->desc->continuous_voltage_range) {
+		min_uV = max(min_uV, rdev->constraints->min_uV);
+		max_uV = min(max_uV, rdev->constraints->max_uV);
+
+		if (min_uV > max_uV)
+			return -EINVAL;
+
+		best_uV = min(max(ideal_uV, min_uV), max_uV);
+		return regulator_set_voltage(regulator, best_uV, best_uV);
+	}
+
+	ret = regulator_count_voltages(regulator);
+	if (ret < 0)
+		return ret;
+	voltages = ret;
+
+	best_uV = 0;
+	best_delta = INT_MAX;
+	for (i = 0; i < voltages; i++) {
+		ret = regulator_list_voltage(regulator, i);
+
+		if (ret < min_uV || ret > max_uV)
+			continue;
+
+		delta = ideal_uV - ret;
+		delta = abs(delta);
+
+		if (delta < best_delta) {
+			best_delta = delta;
+			best_uV = ret;
+		}
+	}
+
+	/* If no voltages, let regulator_set_voltage() decide if we're OK */
+	if (best_uV == 0)
+		return regulator_set_voltage(regulator, min_uV, max_uV);
+
+	return regulator_set_voltage(regulator, best_uV, best_uV);
+}
+EXPORT_SYMBOL_GPL(regulator_set_closest_voltage);
+
+/**
  * regulator_set_voltage_time - get raise/fall time
  * @regulator: regulator source
  * @old_uV: starting voltage in microvolts
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index d17e1ff..71c9ec2 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -228,6 +228,8 @@  int regulator_is_supported_voltage(struct regulator *regulator,
 				   int min_uV, int max_uV);
 unsigned int regulator_get_linear_step(struct regulator *regulator);
 int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV);
+int regulator_set_closest_voltage(struct regulator *regulator, int min_uV,
+				  int ideal_uV, int max_uV);
 int regulator_set_voltage_time(struct regulator *regulator,
 			       int old_uV, int new_uV);
 int regulator_get_voltage(struct regulator *regulator);
@@ -440,6 +442,13 @@  static inline int regulator_set_voltage(struct regulator *regulator,
 	return 0;
 }
 
+static inline int regulator_set_closest_voltage(struct regulator *regulator,
+						int min_uV, int ideal_uV,
+						int max_uV)
+{
+	return 0;
+}
+
 static inline int regulator_set_voltage_time(struct regulator *regulator,
 					     int old_uV, int new_uV)
 {