2022-04-20 10:36:19

by Brian Norris

Subject: [PATCH 1/2] regulator: core: Sleep (not delay) in set_voltage()

These delays can be relatively large (e.g., hundreds of microseconds on
RK3399 Gru systems). Per Documentation/timers/timers-howto.rst, that
should usually use a sleeping delay. Let's use fsleep() to handle both
large and small delays appropriately. This avoids burning a bunch of CPU
time and hurting scheduling latencies when hitting regulators a lot
(e.g., during cpufreq).

The sleep vs. delay issue choice has been made differently over time --
early versions of RK3399 Gru PWM-regulator support used usleep_range()
in pwm-regulator.c. More of this got moved into the regulator core,
in commits like:

73e705bf81ce regulator: core: Add set_voltage_time op

At the same time, the sleep turned into a delay.

It's OK to sleep here, as we aren't in an atomic contexts. (All our
callers grab various mutexes already.)

Signed-off-by: Brian Norris <[email protected]>
---

drivers/regulator/core.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d2553970a67b..223c6d71a2b2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3548,12 +3548,7 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
}

/* Insert any necessary delays */
- if (delay >= 1000) {
- mdelay(delay / 1000);
- udelay(delay % 1000);
- } else if (delay) {
- udelay(delay);
- }
+ fsleep(delay);

if (best_val >= 0) {
unsigned long data = best_val;
--
2.36.0.rc0.470.gd361397f0d-goog

2022-04-22 07:53:58

by Matthias Kaehlcke

Subject: Re: [PATCH 1/2] regulator: core: Sleep (not delay) in set_voltage()

On Mon, Apr 18, 2022 at 02:12:39PM -0700, Brian Norris wrote:
> These delays can be relatively large (e.g., hundreds of microseconds on
> RK3399 Gru systems). Per Documentation/timers/timers-howto.rst, that
> should usually use a sleeping delay. Let's use fsleep() to handle both
> large and small delays appropriately. This avoids burning a bunch of CPU
> time and hurting scheduling latencies when hitting regulators a lot
> (e.g., during cpufreq).
>
> The sleep vs. delay issue choice has been made differently over time --
> early versions of RK3399 Gru PWM-regulator support used usleep_range()
> in pwm-regulator.c. More of this got moved into the regulator core,
> in commits like:
>
> 73e705bf81ce regulator: core: Add set_voltage_time op
>
> At the same time, the sleep turned into a delay.
>
> It's OK to sleep here, as we aren't in an atomic contexts. (All our
> callers grab various mutexes already.)
>
> Signed-off-by: Brian Norris <[email protected]>

Reviewed-by: Matthias Kaehlcke <[email protected]>