[PATCH 1/1] PM: s2idle: Introduce syscore callbacks in s2idle flow

Stephen Boyd swboyd at chromium.org
Tue Sep 1 03:40:23 EDT 2020


Quoting Claude Yen (2020-09-01 00:04:19)
> From: "claude.yen" <claude.yen at mediatek.com>
> 
> Adding syscore callbacks to s2idle makes the behavior of s2idle become
> more similar to Suspend-to-Ram (S2R) and reduces potential porting
> effort.
> 
> tick_freeze() in s2idle flow calls sched_clock_suspend() and
> timekeeping_suspend(), which both functions are also registered as
> syscore callback. sched_clock_suspend() introduced in
> commit 3f2552f7e9c5 ("timers/sched_clock: Prevent generic sched_clock
> wrap caused by tick_freeze()") is added due to clock wrap issue.
> By adding syscore callbacks in s2idle, if there is any syscore callbacks
> also required in s2idle, additional porting effort could be saved.
> 
> Besides, in both S2R and s2idle, before the system entering low power
> state, there is a state when only one cpu alive with interrupt-disabled,
> which is syscore callback designed for. Adding syscore callbacks in
> s2idle is feasible option.
> 
> Scenarios to call syscore callback:
> S2R: one cpu alive when nonboot cpus are hotplug-ed off
> s2idle: one cpu alive when other cpus have enter idle state
> 

Do you have syscore ops that can't be converted to something else like
CPU_PM notifier? At this point most syscore code that is important has
been converted so I don't see much benefit for this patch. If anything,
it will prevent conversions to code that works for both cases.

> 
> Signed-off-by: claude.yen <claude.yen at mediatek.com>



More information about the Linux-mediatek mailing list