* Re: [PATCH v2] regulator: core: repeat voltage setting request for stepped regulators
[not found] <20250718-regulator-stepping-v2-1-e28c9ac5d54a@bootlin.com>
@ 2025-07-29 8:28 ` Jon Hunter
2025-07-29 9:07 ` Romain Gantois
0 siblings, 1 reply; 3+ messages in thread
From: Jon Hunter @ 2025-07-29 8:28 UTC (permalink / raw)
To: Romain Gantois, Liam Girdwood, Mark Brown
Cc: Thomas Petazzoni, linux-kernel, linux-tegra@vger.kernel.org
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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v2] regulator: core: repeat voltage setting request for stepped regulators
2025-07-29 8:28 ` [PATCH v2] regulator: core: repeat voltage setting request for stepped regulators Jon Hunter
@ 2025-07-29 9:07 ` Romain Gantois
2025-07-29 9:18 ` Jon Hunter
0 siblings, 1 reply; 3+ messages in thread
From: Romain Gantois @ 2025-07-29 9:07 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jon Hunter
Cc: Thomas Petazzoni, linux-kernel, linux-tegra@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] regulator: core: repeat voltage setting request for stepped regulators
2025-07-29 9:07 ` Romain Gantois
@ 2025-07-29 9:18 ` Jon Hunter
0 siblings, 0 replies; 3+ messages in thread
From: Jon Hunter @ 2025-07-29 9:18 UTC (permalink / raw)
To: Romain Gantois, Liam Girdwood, Mark Brown
Cc: Thomas Petazzoni, linux-kernel, linux-tegra@vger.kernel.org
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-07-29 9:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20250718-regulator-stepping-v2-1-e28c9ac5d54a@bootlin.com>
2025-07-29 8:28 ` [PATCH v2] regulator: core: repeat voltage setting request for stepped regulators Jon Hunter
2025-07-29 9:07 ` Romain Gantois
2025-07-29 9:18 ` Jon Hunter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox