[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220418141158.1.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid>
Date: Mon, 18 Apr 2022 14:12:39 -0700
From: Brian Norris <briannorris@...omium.org>
To: Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>
Cc: Matthias Kaehlcke <mka@...omium.org>, linux-kernel@...r.kernel.org,
Brian Norris <briannorris@...omium.org>
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 <briannorris@...omium.org>
---
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
Powered by blists - more mailing lists