drivers/regulator/core.c | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-)
The regulator_set_voltage() function may exhibit unexpected behavior if the
target regulator has a maximum voltage step constraint. With such a
constraint, the regulator core may clamp the requested voltage to a lesser
value, to ensure that the voltage delta stays under the specified limit.
This means that the resulting regulator voltage depends on the current
voltage, as well as the requested range, which invalidates the assumption
that a repeated request for a specific voltage range will amount to a noop.
Considering the case of a regulator with a maximum voltage step constraint
of 1V:
initial voltage: 2.5V
consumer requests 4V
expected result: 3.5V
resulting voltage: 3.5V
consumer requests 4V again
expected result: 4V
actual result: 3.5V
Correct this by repeating attempts to balance the regulator voltage until
the result converges.
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
drivers/regulator/core.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index cbd6d53ebfb5ef21b5dfc8b0f1f1f033772a886c..8ed9b96518cf5186c0db147a6895a92bc59fae4e 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3797,6 +3797,16 @@ static int _regulator_do_set_suspend_voltage(struct regulator_dev *rdev,
return 0;
}
+static int regulator_get_voltage_delta(struct regulator_dev *rdev, int uV)
+{
+ int current_uV = regulator_get_voltage_rdev(rdev);
+
+ if (current_uV < 0)
+ return current_uV;
+
+ return abs(current_uV - uV);
+}
+
static int regulator_set_voltage_unlocked(struct regulator *regulator,
int min_uV, int max_uV,
suspend_state_t state)
@@ -3804,8 +3814,8 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
struct regulator_dev *rdev = regulator->rdev;
struct regulator_voltage *voltage = ®ulator->voltage[state];
int ret = 0;
+ int current_uV, delta, new_delta;
int old_min_uV, old_max_uV;
- int current_uV;
/* If we're setting the same range as last time the change
* should be a noop (some cpufreq implementations use the same
@@ -3852,6 +3862,37 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
voltage->max_uV = old_max_uV;
}
+ if (rdev->constraints->max_uV_step > 0) {
+ /* For regulators with a maximum voltage step, reaching the desired
+ * voltage might take a few retries.
+ */
+ ret = regulator_get_voltage_delta(rdev, min_uV);
+ if (ret < 0)
+ goto out;
+
+ delta = ret;
+
+ while (delta > 0) {
+ ret = regulator_balance_voltage(rdev, state);
+ if (ret < 0)
+ goto out;
+
+ ret = regulator_get_voltage_delta(rdev, min_uV);
+ if (ret < 0)
+ goto out;
+
+ new_delta = ret;
+
+ /* check that voltage is converging quickly enough */
+ if (new_delta - delta > rdev->constraints->max_uV_step) {
+ ret = -EWOULDBLOCK;
+ goto out;
+ }
+
+ delta = new_delta;
+ }
+ }
+
out:
return ret;
}
---
base-commit: ef616b9763e374454957a8785a068479fa5665a6
change-id: 20250718-regulator-stepping-c01a696dbafc
Best regards,
--
Romain Gantois <romain.gantois@bootlin.com>Hi Romain,
On 18/07/2025 15:11, Romain Gantois wrote:
> The regulator_set_voltage() function may exhibit unexpected behavior if the
> target regulator has a maximum voltage step constraint. With such a
> constraint, the regulator core may clamp the requested voltage to a lesser
> value, to ensure that the voltage delta stays under the specified limit.
>
> This means that the resulting regulator voltage depends on the current
> voltage, as well as the requested range, which invalidates the assumption
> that a repeated request for a specific voltage range will amount to a noop.
>
> Considering the case of a regulator with a maximum voltage step constraint
> of 1V:
>
> initial voltage: 2.5V
>
> consumer requests 4V
> expected result: 3.5V
> resulting voltage: 3.5V
>
> consumer requests 4V again
> expected result: 4V
> actual result: 3.5V
>
> Correct this by repeating attempts to balance the regulator voltage until
> the result converges.
>
> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
> ---
> drivers/regulator/core.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index cbd6d53ebfb5ef21b5dfc8b0f1f1f033772a886c..8ed9b96518cf5186c0db147a6895a92bc59fae4e 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -3797,6 +3797,16 @@ static int _regulator_do_set_suspend_voltage(struct regulator_dev *rdev,
> return 0;
> }
>
> +static int regulator_get_voltage_delta(struct regulator_dev *rdev, int uV)
> +{
> + int current_uV = regulator_get_voltage_rdev(rdev);
> +
> + if (current_uV < 0)
> + return current_uV;
> +
> + return abs(current_uV - uV);
> +}
> +
> static int regulator_set_voltage_unlocked(struct regulator *regulator,
> int min_uV, int max_uV,
> suspend_state_t state)
> @@ -3804,8 +3814,8 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
> struct regulator_dev *rdev = regulator->rdev;
> struct regulator_voltage *voltage = ®ulator->voltage[state];
> int ret = 0;
> + int current_uV, delta, new_delta;
> int old_min_uV, old_max_uV;
> - int current_uV;
>
> /* If we're setting the same range as last time the change
> * should be a noop (some cpufreq implementations use the same
> @@ -3852,6 +3862,37 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
> voltage->max_uV = old_max_uV;
> }
>
> + if (rdev->constraints->max_uV_step > 0) {
> + /* For regulators with a maximum voltage step, reaching the desired
> + * voltage might take a few retries.
> + */
> + ret = regulator_get_voltage_delta(rdev, min_uV);
> + if (ret < 0)
> + goto out;
> +
> + delta = ret;
> +
> + while (delta > 0) {
> + ret = regulator_balance_voltage(rdev, state);
> + if (ret < 0)
> + goto out;
> +
> + ret = regulator_get_voltage_delta(rdev, min_uV);
> + if (ret < 0)
> + goto out;
> +
> + new_delta = ret;
> +
> + /* check that voltage is converging quickly enough */
> + if (new_delta - delta > rdev->constraints->max_uV_step) {
> + ret = -EWOULDBLOCK;
> + goto out;
> + }
> +
> + delta = new_delta;
> + }
> + }
Since this patch was added to -next, I have observed a boot regression
on our Tegra30 cardhu-a04 board. Bisect pointed to this commit and
reverting this does resolve the problem.
Looking at better closer at the issue, I noticed that it is the
'tps62361-vout' regulator that change is causing problem for. On boot
I see regulator_set_voltage_unlocked() called for this regulator and
min/max voltage requested is ...
regulator regulator.5: min_uV 1000000 max_uV 1350000
The min delta is 300000, but in this case the delta never reaches 0
and in fact never converges at all and so remains at 300000.
Looking at the above, if the delta never changes, then we get stuck
in the above loop forever because 'new_delta - delta' is always 0
and this is never greater than 'rdev->constraints->max_uV_step'.
There are two things that is not clear to me in the above change ...
1. Why do we 'new_delta - delta' instead of 'delta - new_delta'?
Assuming that we should converge, then I would expect that
'new_delta' should be getting smaller as we converge.
2. If difference in the delta is greater than then 'max_uV_step'
doesn't this imply that we are converging quickly?
I am wondering if we need something like ...
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 8ed9b96518cf..554d83c4af0c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3884,7 +3884,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
new_delta = ret;
/* check that voltage is converging quickly enough */
- if (new_delta - delta > rdev->constraints->max_uV_step) {
+ if (delta - new_delta < rdev->constraints->max_uV_step) {
ret = -EWOULDBLOCK;
goto out;
}
Jon
--
nvpublic
Hi Jon,
On Tuesday, 29 July 2025 10:28:17 CEST Jon Hunter wrote:
> Hi Romain,
>
...
> Looking at better closer at the issue, I noticed that it is the
> 'tps62361-vout' regulator that change is causing problem for. On boot
> I see regulator_set_voltage_unlocked() called for this regulator and
> min/max voltage requested is ...
>
> regulator regulator.5: min_uV 1000000 max_uV 1350000
>
> The min delta is 300000, but in this case the delta never reaches 0
> and in fact never converges at all and so remains at 300000.
>
> Looking at the above, if the delta never changes, then we get stuck
> in the above loop forever because 'new_delta - delta' is always 0
> and this is never greater than 'rdev->constraints->max_uV_step'.
>
> There are two things that is not clear to me in the above change ...
>
> 1. Why do we 'new_delta - delta' instead of 'delta - new_delta'?
> Assuming that we should converge, then I would expect that
> 'new_delta' should be getting smaller as we converge.
Indeed it should. "new_delta - delta" is equal to the increase of voltage
"error". So if this value is positive, it's bad because it means we're
getting further away from the target voltage. Also, if it's negative but
too large, then it means that we're slowly crawling to the target voltage,
which is bad. Currently we do:
```
if (new_delta - delta > max_uV_step)
give up and return -EWOULDBLOCK
```
but we should be doing:
```
if (new_delta - delta > -max_uV_step)
give up and return -EWOULDBLOCK
```
which is equivalent to:
```
if (delta - new_delta < max_uV_step)
give up and return -EWOULDBLOCK
```
> 2. If difference in the delta is greater than then 'max_uV_step'
> doesn't this imply that we are converging quickly?
>
Yes, the current logic is indeed flawed.
> I am wondering if we need something like ...
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 8ed9b96518cf..554d83c4af0c 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -3884,7 +3884,7 @@ static int regulator_set_voltage_unlocked(struct
> regulator *regulator, new_delta = ret;
>
> /* check that voltage is converging quickly enough */
> - if (new_delta - delta > rdev->constraints->max_uV_step) {
> + if (delta - new_delta < rdev->constraints->max_uV_step) {
Yes, that would be correct. Do you want to send the fix yourself, or should I
do it and include your "Suggested-by"?
Thanks for reporting the issue and sorry for the trouble.
Best Regards,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 29/07/2025 10:07, Romain Gantois wrote:
> Hi Jon,
>
> On Tuesday, 29 July 2025 10:28:17 CEST Jon Hunter wrote:
>> Hi Romain,
>>
> ...
>> Looking at better closer at the issue, I noticed that it is the
>> 'tps62361-vout' regulator that change is causing problem for. On boot
>> I see regulator_set_voltage_unlocked() called for this regulator and
>> min/max voltage requested is ...
>>
>> regulator regulator.5: min_uV 1000000 max_uV 1350000
>>
>> The min delta is 300000, but in this case the delta never reaches 0
>> and in fact never converges at all and so remains at 300000.
>>
>> Looking at the above, if the delta never changes, then we get stuck
>> in the above loop forever because 'new_delta - delta' is always 0
>> and this is never greater than 'rdev->constraints->max_uV_step'.
>>
>> There are two things that is not clear to me in the above change ...
>>
>> 1. Why do we 'new_delta - delta' instead of 'delta - new_delta'?
>> Assuming that we should converge, then I would expect that
>> 'new_delta' should be getting smaller as we converge.
>
> Indeed it should. "new_delta - delta" is equal to the increase of voltage
> "error". So if this value is positive, it's bad because it means we're
> getting further away from the target voltage. Also, if it's negative but
> too large, then it means that we're slowly crawling to the target voltage,
> which is bad. Currently we do:
>
> ```
> if (new_delta - delta > max_uV_step)
> give up and return -EWOULDBLOCK
> ```
>
> but we should be doing:
>
> ```
> if (new_delta - delta > -max_uV_step)
> give up and return -EWOULDBLOCK
> ```
>
> which is equivalent to:
>
> ```
> if (delta - new_delta < max_uV_step)
> give up and return -EWOULDBLOCK
> ```
>
>> 2. If difference in the delta is greater than then 'max_uV_step'
>> doesn't this imply that we are converging quickly?
>>
>
> Yes, the current logic is indeed flawed.
>
>> I am wondering if we need something like ...
>>
>> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
>> index 8ed9b96518cf..554d83c4af0c 100644
>> --- a/drivers/regulator/core.c
>> +++ b/drivers/regulator/core.c
>> @@ -3884,7 +3884,7 @@ static int regulator_set_voltage_unlocked(struct
>> regulator *regulator, new_delta = ret;
>>
>> /* check that voltage is converging quickly enough */
>> - if (new_delta - delta > rdev->constraints->max_uV_step) {
>> + if (delta - new_delta < rdev->constraints->max_uV_step) {
>
> Yes, that would be correct. Do you want to send the fix yourself, or should I
> do it and include your "Suggested-by"?
Given that you more familiar with the logic, please go ahead and send a
fix. I will happily give it a test on my side.
> Thanks for reporting the issue and sorry for the trouble.
No problem. Thanks for the quick response.
Jon
--
nvpublic
On Fri, 18 Jul 2025 16:11:36 +0200, Romain Gantois wrote:
> The regulator_set_voltage() function may exhibit unexpected behavior if the
> target regulator has a maximum voltage step constraint. With such a
> constraint, the regulator core may clamp the requested voltage to a lesser
> value, to ensure that the voltage delta stays under the specified limit.
>
> This means that the resulting regulator voltage depends on the current
> voltage, as well as the requested range, which invalidates the assumption
> that a repeated request for a specific voltage range will amount to a noop.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] regulator: core: repeat voltage setting request for stepped regulators
commit: d511206dc7443120637efd9cfa3ab06a26da33dd
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
© 2016 - 2025 Red Hat, Inc.