From: Kevin Hilman <khilman@linaro.org> To: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: "Nishanth Menon" <nm@ti.com>, "Paul Walmsley" <paul@pwsan.com>, "Tony Lindgren" <tony@atomide.com>, Keerthy <j-keerthy@ti.com>, daniel.lezcano@linaro.org, lkml <linux-kernel@vger.kernel.org>, "Tero Kristo" <t-kristo@ti.com>, "Benoît Cousson" <bcousson@baylibre.com>, linux-omap <linux-omap@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support Date: Wed, 27 Aug 2014 13:22:43 -0700 [thread overview] Message-ID: <7hegw1bs30.fsf@paris.lan> (raw) In-Reply-To: <53FE3477.2020207@ti.com> (Santosh Shilimkar's message of "Wed, 27 Aug 2014 15:41:43 -0400") Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote: >> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman >> <khilman@deeprootsystems.com> wrote: >>> + Daniel (cpuidle maintainer) >> [...] >>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev, >>>> + struct cpuidle_driver *drv, >>>> + int index) >>>> +{ >>>> + struct idle_statedata *cx = state_ptr + index; >>>> + unsigned long flag; >>>> + >>>> + raw_spin_lock_irqsave(&mpu_lock, flag); >>>> + cx->mpu_state_vote++; >>>> + if (cx->mpu_state_vote == num_online_cpus()) { >>>> + pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state); >>>> + omap_set_pwrdm_state(mpu_pd, cx->mpu_state); >>>> + } >>>> + raw_spin_unlock_irqrestore(&mpu_lock, flag); >>>> + >>>> + omap4_enter_lowpower(dev->cpu, cx->cpu_state); >>>> + >>>> + raw_spin_lock_irqsave(&mpu_lock, flag); >>>> + if (cx->mpu_state_vote == num_online_cpus()) >>>> + omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON); >>>> + cx->mpu_state_vote--; >>>> + raw_spin_unlock_irqrestore(&mpu_lock, flag); >>>> + >>>> + return index; >>>> +} >>> >>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM? >> >> Trying to understand benefit of MCPM here - at least without a deeper >> understanding of mcpm infrastructure benefits (first look seemed a >> little heavy for OMAP5/DRA7 needs). >> >> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for >> "OFF" of CPU1/0, we have mercury hardware to help with context and >> sync issues. >> >> Being able to reuse most of existing OMAP4 infrastructure code is >> useful as well to leave the existing omap4 framework as being lighter >> in complexity -esp in a cpuidle like hot path? >> >> The spin_lock is only for the programming of MPU power domain in a >> consistent manner - I suppose might have been the trigger for >> proposing mcpm? >> > Mostly not.... > > I think this is coming because last time Nicolas Pitre tried to convert > the OMAP CPUIdle into MCPM but because of various ordering requirements, > OMAP wasn't suitable and then the plan was dropped later. > > Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement > remains the same for deeper states. Its just the mercury retention state > which we are able to enter without ordering requirements and hence > the voting scheme. Ah, OK. This is the part that I'm missing. So for deeper states you'll need to be using omap_enter_idle_coupled() > Hope this clarifies to you as well as Kevin just in case he missed the > part of the deeper C-states requirements. Yes, thanks for clarifying. That being said, I think MCPM can now do essentially what the coupled states code is doing. Even so, that's probably not a reason to hold up this patch, but Daniel gets to make that call. Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@linaro.org (Kevin Hilman) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support Date: Wed, 27 Aug 2014 13:22:43 -0700 [thread overview] Message-ID: <7hegw1bs30.fsf@paris.lan> (raw) In-Reply-To: <53FE3477.2020207@ti.com> (Santosh Shilimkar's message of "Wed, 27 Aug 2014 15:41:43 -0400") Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote: >> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman >> <khilman@deeprootsystems.com> wrote: >>> + Daniel (cpuidle maintainer) >> [...] >>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev, >>>> + struct cpuidle_driver *drv, >>>> + int index) >>>> +{ >>>> + struct idle_statedata *cx = state_ptr + index; >>>> + unsigned long flag; >>>> + >>>> + raw_spin_lock_irqsave(&mpu_lock, flag); >>>> + cx->mpu_state_vote++; >>>> + if (cx->mpu_state_vote == num_online_cpus()) { >>>> + pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state); >>>> + omap_set_pwrdm_state(mpu_pd, cx->mpu_state); >>>> + } >>>> + raw_spin_unlock_irqrestore(&mpu_lock, flag); >>>> + >>>> + omap4_enter_lowpower(dev->cpu, cx->cpu_state); >>>> + >>>> + raw_spin_lock_irqsave(&mpu_lock, flag); >>>> + if (cx->mpu_state_vote == num_online_cpus()) >>>> + omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON); >>>> + cx->mpu_state_vote--; >>>> + raw_spin_unlock_irqrestore(&mpu_lock, flag); >>>> + >>>> + return index; >>>> +} >>> >>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM? >> >> Trying to understand benefit of MCPM here - at least without a deeper >> understanding of mcpm infrastructure benefits (first look seemed a >> little heavy for OMAP5/DRA7 needs). >> >> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for >> "OFF" of CPU1/0, we have mercury hardware to help with context and >> sync issues. >> >> Being able to reuse most of existing OMAP4 infrastructure code is >> useful as well to leave the existing omap4 framework as being lighter >> in complexity -esp in a cpuidle like hot path? >> >> The spin_lock is only for the programming of MPU power domain in a >> consistent manner - I suppose might have been the trigger for >> proposing mcpm? >> > Mostly not.... > > I think this is coming because last time Nicolas Pitre tried to convert > the OMAP CPUIdle into MCPM but because of various ordering requirements, > OMAP wasn't suitable and then the plan was dropped later. > > Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement > remains the same for deeper states. Its just the mercury retention state > which we are able to enter without ordering requirements and hence > the voting scheme. Ah, OK. This is the part that I'm missing. So for deeper states you'll need to be using omap_enter_idle_coupled() > Hope this clarifies to you as well as Kevin just in case he missed the > part of the deeper C-states requirements. Yes, thanks for clarifying. That being said, I think MCPM can now do essentially what the coupled states code is doing. Even so, that's probably not a reason to hold up this patch, but Daniel gets to make that call. Kevin
next prev parent reply other threads:[~2014-08-27 20:22 UTC|newest] Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-08-22 14:02 [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 01/10] ARM: OMAP5 / DRA7: PM: Update CPU context register offset Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 02/10] ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-27 18:44 ` Kevin Hilman 2014-08-27 18:44 ` Kevin Hilman 2014-08-22 14:02 ` [PATCH 03/10] ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 04/10] ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx powerdomains Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 05/10] ARM: OMAP5 / DRA7: PM: Avoid all SAR saves Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 06/10] ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU hotplug Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-27 18:58 ` Kevin Hilman 2014-08-27 18:58 ` Kevin Hilman 2014-08-27 19:05 ` Nishanth Menon 2014-08-27 19:05 ` Nishanth Menon 2014-08-27 19:41 ` Tony Lindgren 2014-08-27 19:41 ` Tony Lindgren 2014-08-27 19:43 ` Santosh Shilimkar 2014-08-27 19:43 ` Santosh Shilimkar 2014-08-27 19:45 ` Nishanth Menon 2014-08-27 19:45 ` Nishanth Menon 2014-09-05 21:15 ` Nishanth Menon 2014-09-05 21:15 ` Nishanth Menon 2014-09-05 21:30 ` Tony Lindgren 2014-09-05 21:30 ` Tony Lindgren 2014-09-08 17:23 ` Grazvydas Ignotas 2014-09-08 17:23 ` Grazvydas Ignotas 2014-09-08 18:34 ` Nishanth Menon 2014-09-08 18:34 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-27 19:13 ` Kevin Hilman 2014-08-27 19:13 ` Kevin Hilman 2014-08-27 19:35 ` Nishanth Menon 2014-08-27 19:35 ` Nishanth Menon 2014-08-27 19:41 ` Santosh Shilimkar 2014-08-27 19:41 ` Santosh Shilimkar 2014-08-27 20:22 ` Kevin Hilman [this message] 2014-08-27 20:22 ` Kevin Hilman 2014-09-05 21:18 ` Nishanth Menon 2014-09-05 21:18 ` Nishanth Menon 2014-09-05 21:18 ` Nishanth Menon 2014-09-16 16:34 ` Nishanth Menon 2014-09-16 16:34 ` Nishanth Menon 2014-09-16 16:34 ` Nishanth Menon 2014-09-17 18:49 ` Daniel Lezcano 2014-09-17 18:49 ` Daniel Lezcano 2014-09-17 18:49 ` Daniel Lezcano 2014-09-17 23:20 ` Shilimkar, Santosh 2014-09-17 23:20 ` Shilimkar, Santosh 2014-09-17 23:20 ` Shilimkar, Santosh 2014-09-18 0:22 ` Daniel Lezcano 2014-09-18 0:22 ` Daniel Lezcano 2014-09-18 0:42 ` Shilimkar, Santosh 2014-09-18 0:42 ` Shilimkar, Santosh 2014-09-18 0:42 ` Shilimkar, Santosh 2014-09-18 13:41 ` Nishanth Menon 2014-09-18 13:41 ` Nishanth Menon 2014-09-18 13:50 ` Nishanth Menon 2014-09-18 13:50 ` Nishanth Menon 2014-09-22 13:02 ` Nishanth Menon 2014-09-22 13:02 ` Nishanth Menon 2014-09-22 13:17 ` Nishanth Menon 2014-09-22 13:17 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 09/10] ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` [PATCH 10/10] ARM: DRA7: " Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-22 14:02 ` Nishanth Menon 2014-08-25 16:36 ` [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle Nishanth Menon 2014-08-25 16:36 ` Nishanth Menon 2014-08-27 19:15 ` Kevin Hilman 2014-08-27 19:15 ` Kevin Hilman 2014-09-08 16:29 ` Nishanth Menon 2014-09-08 16:29 ` Nishanth Menon
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=7hegw1bs30.fsf@paris.lan \ --to=khilman@linaro.org \ --cc=bcousson@baylibre.com \ --cc=daniel.lezcano@linaro.org \ --cc=j-keerthy@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=nm@ti.com \ --cc=paul@pwsan.com \ --cc=santosh.shilimkar@ti.com \ --cc=t-kristo@ti.com \ --cc=tony@atomide.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.