For regulators with 'off-on-delay-us' the regulator framework currently
uses ktime_get() to determine how long the regulator has been off
before re-enabling it (after a delay if needed). A problem with using
ktime_get() is that it doesn't account for the time the system is
suspended. As a result a regulator with a longer 'off-on-delay' (e.g.
500ms) that was switched off during suspend might still incurr in a
delay on resume before it is re-enabled, even though the regulator
might have been off for hours. ktime_get_boottime() accounts for
suspend time, use it instead of ktime_get().
Signed-off-by: Matthias Kaehlcke <[email protected]>
---
drivers/regulator/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ae69e493913d..4fcd36055b02 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1584,7 +1584,7 @@ static int set_machine_constraints(struct regulator_dev *rdev)
}
if (rdev->desc->off_on_delay)
- rdev->last_off = ktime_get();
+ rdev->last_off = ktime_get_boottime();
/* If the constraints say the regulator should be on at this point
* and we have control then make sure it is enabled.
@@ -2673,7 +2673,7 @@ static int _regulator_do_enable(struct regulator_dev *rdev)
* this regulator was disabled.
*/
ktime_t end = ktime_add_us(rdev->last_off, rdev->desc->off_on_delay);
- s64 remaining = ktime_us_delta(end, ktime_get());
+ s64 remaining = ktime_us_delta(end, ktime_get_boottime());
if (remaining > 0)
_regulator_delay_helper(remaining);
@@ -2912,7 +2912,7 @@ static int _regulator_do_disable(struct regulator_dev *rdev)
}
if (rdev->desc->off_on_delay)
- rdev->last_off = ktime_get();
+ rdev->last_off = ktime_get_boottime();
trace_regulator_disable_complete(rdev_get_name(rdev));
--
2.39.2.722.g9855ee24e9-goog
Quoting Matthias Kaehlcke (2023-02-22 11:15:46)
> For regulators with 'off-on-delay-us' the regulator framework currently
> uses ktime_get() to determine how long the regulator has been off
> before re-enabling it (after a delay if needed). A problem with using
> ktime_get() is that it doesn't account for the time the system is
> suspended. As a result a regulator with a longer 'off-on-delay' (e.g.
> 500ms) that was switched off during suspend might still incurr in a
> delay on resume before it is re-enabled, even though the regulator
> might have been off for hours. ktime_get_boottime() accounts for
> suspend time, use it instead of ktime_get().
>
> Signed-off-by: Matthias Kaehlcke <[email protected]>
> ---
Is it fixing something in stable kernels? Should it be tagged for
stable?
Reviewed-by: Stephen Boyd <[email protected]>
On Wed, Feb 22, 2023 at 03:46:39PM -0500, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2023-02-22 11:15:46)
> > For regulators with 'off-on-delay-us' the regulator framework currently
> > uses ktime_get() to determine how long the regulator has been off
> > before re-enabling it (after a delay if needed). A problem with using
> > ktime_get() is that it doesn't account for the time the system is
> > suspended. As a result a regulator with a longer 'off-on-delay' (e.g.
> > 500ms) that was switched off during suspend might still incurr in a
> > delay on resume before it is re-enabled, even though the regulator
> > might have been off for hours. ktime_get_boottime() accounts for
> > suspend time, use it instead of ktime_get().
> >
> > Signed-off-by: Matthias Kaehlcke <[email protected]>
> > ---
>
> Is it fixing something in stable kernels? Should it be tagged for
> stable?
It's not a super-critical fix, but it could improve resume time for
some devices with stable kernels, so it might be worth adding it to
stable. I'll send out a a v2 with the corresponding tags.