Kevin,
Thanks for taking time to review the
series!
On 2020-08-12 05:49, Kevin Hilman wrote:
Sibi Sankar <sibis@xxxxxxxxxxxxxx> writes:
This is for power domains which needs to stay powered on for suspend
but can be powered on/off as part of runtime PM. This flag is aimed at
power domains coupled to remote processors which enter suspend states
independent to that of the application processor. Such power domains
are turned off only on remote processor crash/shutdown.
Signed-off-by: Sibi Sankar <sibis@xxxxxxxxxxxxxx>
Seems like a useful use-case, but i think there should be a bit more
description/documentation about what is the expected/desired behavior
during system suspsend when a power-domain with this flag is already
runtime-PM suspended. Similarily, on system resume, what is the
expected/desired behavior?
SUSPEND_ON flag is only aimed at
keeping power domains powered on
across suspend (only if its already
powered on). Also if the power domain
is runtime-PM suspended we wouldn't
want to power it on during resume.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 0a5afca250d03..547c091618008 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1003,7 +1003,7 @@ static void genpd_sync_power_on(struct
generic_pm_domain *genpd, bool use_lock,
{
struct gpd_link *link;
- if (genpd_status_on(genpd))
+ if (genpd_status_on(genpd) || genpd_is_suspend_on(genpd))
return;
I'll add the ^^ diff in the next
re-spin to prevent power on of
a runtime-PM suspended power
domain.
Kevin
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.