From: Kevin Hilman <khilman@ti.com> To: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux@arm.linux.org.uk>, <ccross@android.com>, <rjw@sisk.pl> Subject: Re: [PATCH v2 2/5] cpu_pm: call notifiers during suspend Date: Wed, 07 Sep 2011 13:02:59 -0700 [thread overview] Message-ID: <87k49knmrw.fsf@ti.com> (raw) In-Reply-To: <1315060755-4613-3-git-send-email-santosh.shilimkar@ti.com> (Santosh Shilimkar's message of "Sat, 3 Sep 2011 20:09:12 +0530") Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > From: Colin Cross <ccross@android.com> > > Implements syscore_ops in cpu_pm to call the cpu and > cpu cluster notifiers during suspend and resume, > allowing drivers receiving the notifications to > avoid implementing syscore_ops. > > Signed-off-by: Colin Cross <ccross@android.com> > [santosh.shilimkar@ti.com: Rebased against 3.1-rc4] > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> I don't think using syscore_ops is right here. The platform code should decide where in its own suspend path the notifiers should be triggered. The reason is because while the syscore_ops run late in the suspend path, they still run before some platform-specific decisions about the low-power states are made. That means that any notifiers that need to use information about the target low-power state (e.g. whether context will be lost or not) cannot do so since that information has not yet been decided until the platform_suspend_ops->enter() runs. Basically, I think the cpu_*_pm_enter() calls should be called by platform-specific code, not by common code. Kevin > --- > kernel/cpu_pm.c | 33 +++++++++++++++++++++++++++++++++ > 1 files changed, 33 insertions(+), 0 deletions(-) > > diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c > index 54aa892..3d115d0 100644 > --- a/kernel/cpu_pm.c > +++ b/kernel/cpu_pm.c > @@ -20,6 +20,7 @@ > #include <linux/module.h> > #include <linux/notifier.h> > #include <linux/spinlock.h> > +#include <linux/syscore_ops.h> > > static DEFINE_RWLOCK(cpu_pm_notifier_lock); > static RAW_NOTIFIER_HEAD(cpu_pm_notifier_chain); > @@ -113,3 +114,35 @@ int cpu_cluster_pm_exit(void) > return ret; > } > EXPORT_SYMBOL_GPL(cpu_cluster_pm_exit); > + > +#ifdef CONFIG_PM > +static int cpu_pm_suspend(void) > +{ > + int ret; > + > + ret = cpu_pm_enter(); > + if (ret) > + return ret; > + > + ret = cpu_cluster_pm_enter(); > + return ret; > +} > + > +static void cpu_pm_resume(void) > +{ > + cpu_cluster_pm_exit(); > + cpu_pm_exit(); > +} > + > +static struct syscore_ops cpu_pm_syscore_ops = { > + .suspend = cpu_pm_suspend, > + .resume = cpu_pm_resume, > +}; > + > +static int cpu_pm_init(void) > +{ > + register_syscore_ops(&cpu_pm_syscore_ops); > + return 0; > +} > +core_initcall(cpu_pm_init); > +#endif
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 2/5] cpu_pm: call notifiers during suspend Date: Wed, 07 Sep 2011 13:02:59 -0700 [thread overview] Message-ID: <87k49knmrw.fsf@ti.com> (raw) In-Reply-To: <1315060755-4613-3-git-send-email-santosh.shilimkar@ti.com> (Santosh Shilimkar's message of "Sat, 3 Sep 2011 20:09:12 +0530") Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > From: Colin Cross <ccross@android.com> > > Implements syscore_ops in cpu_pm to call the cpu and > cpu cluster notifiers during suspend and resume, > allowing drivers receiving the notifications to > avoid implementing syscore_ops. > > Signed-off-by: Colin Cross <ccross@android.com> > [santosh.shilimkar at ti.com: Rebased against 3.1-rc4] > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> I don't think using syscore_ops is right here. The platform code should decide where in its own suspend path the notifiers should be triggered. The reason is because while the syscore_ops run late in the suspend path, they still run before some platform-specific decisions about the low-power states are made. That means that any notifiers that need to use information about the target low-power state (e.g. whether context will be lost or not) cannot do so since that information has not yet been decided until the platform_suspend_ops->enter() runs. Basically, I think the cpu_*_pm_enter() calls should be called by platform-specific code, not by common code. Kevin > --- > kernel/cpu_pm.c | 33 +++++++++++++++++++++++++++++++++ > 1 files changed, 33 insertions(+), 0 deletions(-) > > diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c > index 54aa892..3d115d0 100644 > --- a/kernel/cpu_pm.c > +++ b/kernel/cpu_pm.c > @@ -20,6 +20,7 @@ > #include <linux/module.h> > #include <linux/notifier.h> > #include <linux/spinlock.h> > +#include <linux/syscore_ops.h> > > static DEFINE_RWLOCK(cpu_pm_notifier_lock); > static RAW_NOTIFIER_HEAD(cpu_pm_notifier_chain); > @@ -113,3 +114,35 @@ int cpu_cluster_pm_exit(void) > return ret; > } > EXPORT_SYMBOL_GPL(cpu_cluster_pm_exit); > + > +#ifdef CONFIG_PM > +static int cpu_pm_suspend(void) > +{ > + int ret; > + > + ret = cpu_pm_enter(); > + if (ret) > + return ret; > + > + ret = cpu_cluster_pm_enter(); > + return ret; > +} > + > +static void cpu_pm_resume(void) > +{ > + cpu_cluster_pm_exit(); > + cpu_pm_exit(); > +} > + > +static struct syscore_ops cpu_pm_syscore_ops = { > + .suspend = cpu_pm_suspend, > + .resume = cpu_pm_resume, > +}; > + > +static int cpu_pm_init(void) > +{ > + register_syscore_ops(&cpu_pm_syscore_ops); > + return 0; > +} > +core_initcall(cpu_pm_init); > +#endif
next prev parent reply other threads:[~2011-09-07 20:03 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-09-03 14:39 [PATCH v2 0/5] CPU PM notifiers Santosh Shilimkar 2011-09-03 14:39 ` Santosh Shilimkar 2011-09-03 14:39 ` [PATCH v2 1/5] cpu_pm: Add cpu power management notifiers Santosh Shilimkar 2011-09-03 14:39 ` Santosh Shilimkar 2011-09-09 22:56 ` Andrew Morton 2011-09-09 22:56 ` Andrew Morton 2011-09-10 4:02 ` Santosh 2011-09-10 4:02 ` Santosh 2011-09-10 9:31 ` Santosh 2011-09-10 9:31 ` Santosh 2011-09-12 5:02 ` Santosh 2011-09-12 5:02 ` Santosh 2011-09-13 5:42 ` Santosh 2011-09-13 5:42 ` Santosh 2011-09-03 14:39 ` [PATCH v2 2/5] cpu_pm: call notifiers during suspend Santosh Shilimkar 2011-09-03 14:39 ` Santosh Shilimkar 2011-09-07 20:02 ` Kevin Hilman [this message] 2011-09-07 20:02 ` Kevin Hilman 2011-09-08 5:16 ` Santosh 2011-09-08 5:16 ` Santosh 2011-09-08 14:01 ` Kevin Hilman 2011-09-08 14:01 ` Kevin Hilman 2011-09-08 16:12 ` Santosh 2011-09-08 16:12 ` Santosh 2011-09-08 17:56 ` Kevin Hilman 2011-09-08 18:04 ` Colin Cross 2011-09-08 18:04 ` Colin Cross 2011-09-08 20:51 ` Kevin Hilman 2011-09-09 6:27 ` Santosh 2011-09-09 6:27 ` Santosh 2011-09-03 14:39 ` [PATCH v2 3/5] ARM: gic: Use cpu pm notifiers to save gic state Santosh Shilimkar 2011-09-03 14:39 ` Santosh Shilimkar 2011-09-03 14:39 ` [PATCH v2 4/5] ARM: vfp: Use cpu pm notifiers to save vfp state Santosh Shilimkar 2011-09-03 14:39 ` Santosh Shilimkar 2011-09-03 14:39 ` [PATCH v2 5/5] ARM: gic: Allow gic arch extensions to provide irqchip flags Santosh Shilimkar 2011-09-03 14:39 ` Santosh Shilimkar 2011-09-06 2:34 ` [PATCH v2 0/5] CPU PM notifiers Shawn Guo 2011-09-06 2:34 ` Shawn Guo 2011-09-06 5:17 ` Santosh 2011-09-06 5:17 ` Santosh 2011-09-09 18:00 ` Kevin Hilman 2011-09-09 18:00 ` Kevin Hilman 2011-09-10 5:53 ` Santosh 2011-09-10 5:53 ` Santosh 2011-09-16 4:50 ` Santosh 2011-09-16 4:50 ` Santosh
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87k49knmrw.fsf@ti.com \ --to=khilman@ti.com \ --cc=ccross@android.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=rjw@sisk.pl \ --cc=santosh.shilimkar@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.