| Message ID | 1418245085-9754-1-git-send-email-dianders@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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.
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.
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
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.
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
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.
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
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?
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
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.
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) {
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(+)