Similar to what happened whith autosuspend, a deadlock has been
reported with PM-runtime accounting in the call path:
change_clocksource
...
write_seqcount_begin
...
timekeeping_update
...
sh_cmt_clocksource_enable
...
rpm_resume
update_pm_runtime_accounting
ktime_get
do
read_seqcount_begin
while read_seqcount_retry
....
write_seqcount_end
Make PM-runtime accounting use ktime_get_mono_fast_ns() to avoid this
problem.
With ktime_get_mono_fast_ns(), the timestamp is not guaranteed to be
monotonic across an update of timekeeping and as a result time can go
backward. Add a test to skip accounting for such situation which should
stay exceptional.
Fixes:
a08c2a5a3194 ("PM-runtime: Replace jiffies-based accounting with ktime-based accounting")
Reported-by: Biju Das <biju.das@bp.renesas.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
[ rjw: Subject, changelog, comment cleanup ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
*/
void update_pm_runtime_accounting(struct device *dev)
{
- u64 now = ktime_to_ns(ktime_get());
+ u64 now = ktime_get_mono_fast_ns();
+ u64 last = dev->power.accounting_timestamp;
u64 delta;
- delta = now - dev->power.accounting_timestamp;
-
dev->power.accounting_timestamp = now;
+ /*
+ * Because ktime_get_mono_fast_ns() is not monotonic during
+ * timekeeping updates, ensure that 'now' is after the last saved
+ * timesptamp.
+ */
+ if (now < last)
+ return;
+
+ delta = now - last;
+
if (dev->power.disable_depth > 0)
return;
/* About to enable runtime pm, set accounting_timestamp to now */
if (!dev->power.disable_depth)
- dev->power.accounting_timestamp = ktime_to_ns(ktime_get());
+ dev->power.accounting_timestamp = ktime_get_mono_fast_ns();
} else {
dev_warn(dev, "Unbalanced %s!\n", __func__);
}