* Kevin Hilman <khilman@xxxxxxxxxx> [231128 04:52]: > Tony Lindgren <tony@xxxxxxxxxxx> writes: > > > * Kevin Hilman <khilman@xxxxxxxxxx> [231128 04:05]: > >> Tony Lindgren <tony@xxxxxxxxxxx> writes: > >> > >> > * Théo Lebrun <theo.lebrun@xxxxxxxxxxx> [231124 10:39]: > >> >> On Fri Nov 24, 2023 at 6:37 AM CET, Tony Lindgren wrote: > >> >> Checking the code confirms this behavior. Grep for the macro > >> >> genpd_is_active_wakeup rather than GENPD_FLAG_ACTIVE_WAKEUP. It gets > >> >> used twice (suspend & resume), both in the same manner: > >> >> > >> >> if (device_wakeup_path(dev) && genpd_is_active_wakeup(genpd)) > >> >> > >> >> This means this flag won't have any impact on runtime PM handling of > >> >> power-domains. By the way, other users of the flag enable it at PD > >> >> registration & don't touch it afterwards. > >> > > >> > Setting GENPD_FLAG_ACTIVE_WAKEUP will block deeper idle states for > >> > the SoC most likely. > >> > >> It doesn't affect idle states. It only affects suspend states. > >> > >> As Théo pointed out, system-wide suspend will ignores runtime PM > >> refcounts, so IMO, using this flag is the right approach. > > > > But it still blocks the deeper SoC suspend states if set, right? > > > > If so, it should be dynamically toggled depending on the console_suspend > > flag. > > Agreed, and that's what I think Théo proposed earlier in this thread[1]. > > Since the deeper suspend states are prevented only when this flag is > present *and* the wakeup path is set, Théo's example just toggles the > wakeup path set based on console_suspend_enabled. Ah it's the *and* part I was missing! Yes great, that sounds good to me. Thanks, Tony > [1] https://lore.kernel.org/r/CX5F88JLWFUW.Z36KQB2PX554@tleb-bootlin-xps13-01
