* [PATCH] regulator: core: Reduce busy-wait looping
@ 2014-03-21 2:31 Jonghwan Choi
2014-03-21 11:50 ` Mark Brown
0 siblings, 1 reply; 4+ messages in thread
From: Jonghwan Choi @ 2014-03-21 2:31 UTC (permalink / raw)
To: 'open list'; +Cc: 'Liam Girdwood', 'Mark Brown'
Commit 5df529d440("regulator: core: Reduce busy-wait looping")
can also be used in regulator_do_set_voltage.
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
---
drivers/regulator/core.c | 39 +++++++++++++++++++++++++++++++++------
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index afca1bc..c375bfb 100644
--- a/drivers/regulator/core.c
+++ b/d728099474rivers/regulator/core.c
@@ -2355,12 +2355,39 @@ static int _regulator_do_set_voltage(struct
regulator_dev *rdev,
delay = 0;
}
- /* Insert any necessary delays */
- if (delay >= 1000) {
- mdelay(delay / 1000);
- udelay(delay % 1000);
- } else if (delay) {
- udelay(delay);
+ /*
+ * Delay for the requested amount of time as per the
guidelines in:
+ *
+ * Documentation/timers/timers-howto.txt
+ *
+ * The assumption here is that regulators will never set the
voltage in
+ * atomic context and therefore sleeping functions can be
used.
+ */
+ if (delay) {
+ unsigned int ms = delay / 1000;
+ unsigned int us = delay % 1000;
+
+ if (ms > 0) {
+ /*
+ * For small enough values, handle
super-millisecond
+ * delays in the usleep_range() call below.
+ */
+ if (ms < 20)
+ us += ms * 1000;
+ else
+ msleep(ms);
+ }
+
+ /*
+ * Give the scheduler some room to coalesce with any
other
+ * wakeup sources. For delays shorter than 10 us,
don't even
+ * bother setting up high-resolution timers and just
busy-
+ * loop.
+ */
+ if (us >= 10)
+ usleep_range(us, us + 100);
+ else
+ udelay(us);
}
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] regulator: core: Reduce busy-wait looping
2014-03-21 2:31 [PATCH] regulator: core: Reduce busy-wait looping Jonghwan Choi
@ 2014-03-21 11:50 ` Mark Brown
0 siblings, 0 replies; 4+ messages in thread
From: Mark Brown @ 2014-03-21 11:50 UTC (permalink / raw)
To: Jonghwan Choi; +Cc: 'open list', 'Liam Girdwood'
[-- Attachment #1: Type: text/plain, Size: 497 bytes --]
On Fri, Mar 21, 2014 at 11:31:25AM +0900, Jonghwan Choi wrote:
> Commit 5df529d440("regulator: core: Reduce busy-wait looping")
> can also be used in regulator_do_set_voltage.
This is good as a change but please factor it out into a function so we
don't have the same problem again with future changes (I'm surprised
there isn't one in the generic code somewhere but if not we can do that
as a second stage, regulator only is fine for now) and make sure that
the lines are less than 80 columns.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] regulator: core: Reduce busy-wait looping
2013-09-20 11:51 Thierry Reding
@ 2013-09-20 16:42 ` Mark Brown
0 siblings, 0 replies; 4+ messages in thread
From: Mark Brown @ 2013-09-20 16:42 UTC (permalink / raw)
To: Thierry Reding; +Cc: Liam Girdwood, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
On Fri, Sep 20, 2013 at 01:51:56PM +0200, Thierry Reding wrote:
> Keep busy-wait looping to a minimum while waiting for a regulator to
> ramp-up to the target voltage. This follows the guidelines set forth
> in Documentation/timers/timers-howto.txt and assumes that regulators
> are never enabled in atomic context.
Nice, good spot - applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] regulator: core: Reduce busy-wait looping
@ 2013-09-20 11:51 Thierry Reding
2013-09-20 16:42 ` Mark Brown
0 siblings, 1 reply; 4+ messages in thread
From: Thierry Reding @ 2013-09-20 11:51 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood; +Cc: linux-kernel
Keep busy-wait looping to a minimum while waiting for a regulator to
ramp-up to the target voltage. This follows the guidelines set forth
in Documentation/timers/timers-howto.txt and assumes that regulators
are never enabled in atomic context.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/regulator/core.c | 38 +++++++++++++++++++++++++++++++++-----
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 4eefcc3..4e18884 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1566,11 +1566,39 @@ static int _regulator_do_enable(struct regulator_dev *rdev)
* together. */
trace_regulator_enable_delay(rdev_get_name(rdev));
- if (delay >= 1000) {
- mdelay(delay / 1000);
- udelay(delay % 1000);
- } else if (delay) {
- udelay(delay);
+ /*
+ * Delay for the requested amount of time as per the guidelines in:
+ *
+ * Documentation/timers/timers-howto.txt
+ *
+ * The assumption here is that regulators will never be enabled in
+ * atomic context and therefore sleeping functions can be used.
+ */
+ if (delay) {
+ unsigned int ms = delay / 1000;
+ unsigned int us = delay % 1000;
+
+ if (ms > 0) {
+ /*
+ * For small enough values, handle super-millisecond
+ * delays in the usleep_range() call below.
+ */
+ if (ms < 20)
+ us += ms * 1000;
+ else
+ msleep(ms);
+ }
+
+ /*
+ * Give the scheduler some room to coalesce with any other
+ * wakeup sources. For delays shorter than 10 us, don't even
+ * bother setting up high-resolution timers and just busy-
+ * loop.
+ */
+ if (us >= 10)
+ usleep_range(us, us + 100);
+ else
+ udelay(us);
}
trace_regulator_enable_complete(rdev_get_name(rdev));
--
1.8.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-03-21 11:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-21 2:31 [PATCH] regulator: core: Reduce busy-wait looping Jonghwan Choi
2014-03-21 11:50 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2013-09-20 11:51 Thierry Reding
2013-09-20 16:42 ` Mark Brown
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.