diff for duplicates of <87lix2y6pm.fsf@ti.com> diff --git a/a/1.txt b/N1/1.txt index 9a1d264..2cdf728 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,7 +5,7 @@ Colin Cross <ccross@android.com> writes: >> >>> During some CPU power modes entered during idle, hotplug and >>> suspend, peripherals located in the CPU power domain, such as ->>> the GIC and VFP, may be powered down. ?Add a notifier chain +>>> the GIC and VFP, may be powered down. Add a notifier chain >>> that allows drivers for those peripherals to be notified >>> before and after they may be reset. >>> @@ -15,22 +15,22 @@ Colin Cross <ccross@android.com> writes: >> >> I had hacked up something OMAP-specific a while back to do something >> similar, and have been meaning to make it more generic, so this is ->> perfect. ?Also, if it is moved outside ARM, note that x86_64 has a +>> perfect. Also, if it is moved outside ARM, note that x86_64 has a >> idle_notifier infrastructure that is somewhat similar, and if you're ->> motivated, it should probably be converted to this as well. ?See +>> motivated, it should probably be converted to this as well. See >> arch/x86/kernel/process_64.c. > > I'll take a look at x86 > >> Also, for the sake of the comments/changelog, the usefulness of these >> notifiers is not limited to low-power states where power is off and IP ->> blocks may be reset. ?It could be considered as simply a generic +>> blocks may be reset. It could be considered as simply a generic >> notification mechanism for any CPU PM transitions. >> >> On OMAP we have other peripherals (not in the CPU power domain) where we >> need to control their PM transitions in relation to the CPU PM >> transitions so the notifiers are useful for any low-power state ->> transition of the CPU(s). ?The drivers for these peripherals use runtime +>> transition of the CPU(s). The drivers for these peripherals use runtime >> PM in their CPU PM notifiers to trigger the device PM transitions. (The >> drivers must use the synchronous versions of the runtime PM get/put >> calls with device in pm_runtime_irq_safe() mode.) @@ -49,8 +49,8 @@ notifier would be used to check for pending activity and take action. >> In this series, I don't see any calls to cpu_[complex_]pm_[enter|exit](). >> Based on that, I assume you prefer to leave it up to platform-specific ->> idle/PM code to place these calls. ?Or, do you plan to have this ->> triggered by generic CPUidle, suspend/resume and/or hotplug code? ?At +>> idle/PM code to place these calls. Or, do you plan to have this +>> triggered by generic CPUidle, suspend/resume and/or hotplug code? At >> least on OMAP, I prefer having the calls in platform-specific code. > > I will post the Tegra code that uses this soon. I expect that the @@ -60,10 +60,10 @@ notifier would be used to check for pending activity and take action. Agreed. ->> I have a minor enhancement request. ?The notifier callbacks provide for ->> passing a void * through the notifier chain. ?Could you add a way for a +>> I have a minor enhancement request. The notifier callbacks provide for +>> passing a void * through the notifier chain. Could you add a way for a >> void * to be registered at cpu_pm_register_notifier() time and that ->> would be passed through the notifier call chain? ?This would allow using +>> would be passed through the notifier call chain? This would allow using >> the same struct notifier_block and callback for multiple instances of >> the same IP, and the instances could be differentiated in the callback >> using the void *. @@ -82,7 +82,7 @@ being able to pass in the 'void *' at registration time would allow a single struct notifier_block' for all instances of the device. >> Also, FWIW I tested this on OMAP3 (Cortex-A8 UP) using ->> cpu_pm_enter/exit() in the code path shared between idle and suspend. ?I +>> cpu_pm_enter/exit() in the code path shared between idle and suspend. I >> successfully triggered PM transitions in non-CPU power-domain >> peripherals, and it worked great. > diff --git a/a/content_digest b/N1/content_digest index e6d973e..b8c8bec 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,10 +2,19 @@ "ref\01307925825-28566-2-git-send-email-ccross@android.com\0" "ref\087ips9fka2.fsf@ti.com\0" "ref\0BANLkTinnZtPFY1Aae=8uDbyt5sh9xAxiNw@mail.gmail.com\0" - "From\0khilman@ti.com (Kevin Hilman)\0" - "Subject\0[PATCH 1/3] ARM: Add cpu power management notifiers\0" + "From\0Kevin Hilman <khilman@ti.com>\0" + "Subject\0Re: [PATCH 1/3] ARM: Add cpu power management notifiers\0" "Date\0Wed, 15 Jun 2011 17:12:53 -0700\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Colin Cross <ccross@android.com>\0" + "Cc\0linux-arm-kernel\\@lists.infradead.org <linux-arm-kernel@lists.infradead.org>" + lkml <linux-kernel@vger.kernel.org> + Russell King <linux@arm.linux.org.uk> + Catalin Marinas <catalin.marinas@arm.com> + Santosh Shilimkar <santosh.shilimkar@ti.com> + Nicolas Pitre <nicolas.pitre@linaro.org> + Eric Miao <eric.y.miao@gmail.com> + Peter Zijlstra <peterz@infradead.org> + " Leif Lindholm <leif.lindholm@arm.com>\0" "\00:1\0" "b\0" "Colin Cross <ccross@android.com> writes:\n" @@ -15,7 +24,7 @@ ">>\n" ">>> During some CPU power modes entered during idle, hotplug and\n" ">>> suspend, peripherals located in the CPU power domain, such as\n" - ">>> the GIC and VFP, may be powered down. ?Add a notifier chain\n" + ">>> the GIC and VFP, may be powered down. \302\240Add a notifier chain\n" ">>> that allows drivers for those peripherals to be notified\n" ">>> before and after they may be reset.\n" ">>>\n" @@ -25,22 +34,22 @@ ">>\n" ">> I had hacked up something OMAP-specific a while back to do something\n" ">> similar, and have been meaning to make it more generic, so this is\n" - ">> perfect. ?Also, if it is moved outside ARM, note that x86_64 has a\n" + ">> perfect. \302\240Also, if it is moved outside ARM, note that x86_64 has a\n" ">> idle_notifier infrastructure that is somewhat similar, and if you're\n" - ">> motivated, it should probably be converted to this as well. ?See\n" + ">> motivated, it should probably be converted to this as well. \302\240See\n" ">> arch/x86/kernel/process_64.c.\n" ">\n" "> I'll take a look at x86\n" ">\n" ">> Also, for the sake of the comments/changelog, the usefulness of these\n" ">> notifiers is not limited to low-power states where power is off and IP\n" - ">> blocks may be reset. ?It could be considered as simply a generic\n" + ">> blocks may be reset. \302\240It could be considered as simply a generic\n" ">> notification mechanism for any CPU PM transitions.\n" ">>\n" ">> On OMAP we have other peripherals (not in the CPU power domain) where we\n" ">> need to control their PM transitions in relation to the CPU PM\n" ">> transitions so the notifiers are useful for any low-power state\n" - ">> transition of the CPU(s). ?The drivers for these peripherals use runtime\n" + ">> transition of the CPU(s). \302\240The drivers for these peripherals use runtime\n" ">> PM in their CPU PM notifiers to trigger the device PM transitions. (The\n" ">> drivers must use the synchronous versions of the runtime PM get/put\n" ">> calls with device in pm_runtime_irq_safe() mode.)\n" @@ -59,8 +68,8 @@ "\n" ">> In this series, I don't see any calls to cpu_[complex_]pm_[enter|exit]().\n" ">> Based on that, I assume you prefer to leave it up to platform-specific\n" - ">> idle/PM code to place these calls. ?Or, do you plan to have this\n" - ">> triggered by generic CPUidle, suspend/resume and/or hotplug code? ?At\n" + ">> idle/PM code to place these calls. \302\240Or, do you plan to have this\n" + ">> triggered by generic CPUidle, suspend/resume and/or hotplug code? \302\240At\n" ">> least on OMAP, I prefer having the calls in platform-specific code.\n" ">\n" "> I will post the Tegra code that uses this soon. I expect that the\n" @@ -70,10 +79,10 @@ "\n" "Agreed.\n" "\n" - ">> I have a minor enhancement request. ?The notifier callbacks provide for\n" - ">> passing a void * through the notifier chain. ?Could you add a way for a\n" + ">> I have a minor enhancement request. \302\240The notifier callbacks provide for\n" + ">> passing a void * through the notifier chain. \302\240Could you add a way for a\n" ">> void * to be registered at cpu_pm_register_notifier() time and that\n" - ">> would be passed through the notifier call chain? ?This would allow using\n" + ">> would be passed through the notifier call chain? \302\240This would allow using\n" ">> the same struct notifier_block and callback for multiple instances of\n" ">> the same IP, and the instances could be differentiated in the callback\n" ">> using the void *.\n" @@ -92,7 +101,7 @@ "single struct notifier_block' for all instances of the device.\n" "\n" ">> Also, FWIW I tested this on OMAP3 (Cortex-A8 UP) using\n" - ">> cpu_pm_enter/exit() in the code path shared between idle and suspend. ?I\n" + ">> cpu_pm_enter/exit() in the code path shared between idle and suspend. \302\240I\n" ">> successfully triggered PM transitions in non-CPU power-domain\n" ">> peripherals, and it worked great.\n" ">\n" @@ -104,4 +113,4 @@ "\n" Kevin -afce5c25a21a6f0cbbab7d431d4686b57b9a7b600d9c1a173200f5c592a4a9ba +240baa1269634e7a517ba6f357ea446333f996139399ddfd18fa0fc7538d95cd
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.