From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Basak, Partha" <p-basak2@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"Varadarajan, Charulatha" <charu@ti.com>,
Tero Kristo <tero.kristo@nokia.com>
Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
Date: Tue, 14 Sep 2010 09:57:55 -0700 [thread overview]
Message-ID: <87d3sgs1nw.fsf@deeprootsystems.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301F6DF51AF@dbde02.ent.ti.com> (Partha Basak's message of "Tue, 14 Sep 2010 21:39:35 +0530")
"Basak, Partha" <p-basak2@ti.com> writes:
>> From: Kevin Hilman <khilman@ti.com>
>>
>> Currently, we wait until late in the idle path where interrupts are
>> disabled to do runtime-PM-like management for certain special-case
>> devices like GPIO.
>>
>> As a prerequiste to moving GPIO to the new runtime PM framework, move
>> this runtime-PM-like code out of the late idle path into new device
>> idle and resume functions that can be called before interrupts are
>> disabled by CPUidle and/or suspend.
>>
>> In addition, move all the GPIO-specific logic into the GPIO core
>> instead of keeping GPIO-specific knowledge of power-states, context
>> saving etc. in the PM core.
>>
>> Also, call the new device-idle and -resume methods from CPUidle and
>> static suspend path.
>>
>> Signed-off-by: Kevin Hilman <khilman@ti.com>
>> ---
>> arch/arm/mach-omap2/cpuidle34xx.c | 4 ++
>> arch/arm/mach-omap2/pm.h | 2 +
>> arch/arm/mach-omap2/pm24xx.c | 2 +-
>> arch/arm/mach-omap2/pm34xx.c | 38 +++++++++------------
>> arch/arm/plat-omap/gpio.c | 57
>> ++++++++++++++++++++++++--------
>> arch/arm/plat-omap/include/plat/gpio.h | 4 +--
>> 6 files changed, 67 insertions(+), 40 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>> b/arch/arm/mach-omap2/cpuidle34xx.c
>> index 0923b82..681d823 100644
>> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> @@ -274,9 +274,13 @@ static int omap3_enter_idle_bm(struct
>> cpuidle_device *dev,
>> pwrdm_set_next_pwrst(per_pd, per_next_state);
>>
>> select_state:
>> + omap3_device_idle();
>> +
>> dev->last_state = new_state;
>> ret = omap3_enter_idle(dev, new_state);
>>
>> + omap3_device_resume();
>> +
> In the generic cpu_idle() in process.c, interrupts are already disabled
> before control comes to cpuidle_idle_call() via pm_idle()
> local_irq_disable();
> if (hlt_counter) {
> local_irq_enable();
> cpu_relax();
> } else {
> stop_critical_timings();
> pm_idle();
> start_critical_timings();
> /*
> * This will eventually be removed - pm_idle
> * functions should always return with IRQs
> * enabled.
> */
> WARN_ON(irqs_disabled());
> local_irq_enable();
> }
>
> omap3_enter_idle_bm() will be called from inside cpuidle_idle_call()
> via target_state->enter(dev, target_state).
> So, interrupts are already disabled here.
>
> Am I missing something?
You're right.
I knew this was the case for !CPUIDLE setup, but had thought (without
testing) that the CPUidle core had re-enabled interrupts during the
governor selection process etc.
While I investigate ways to manage this in CPUidle, the following should
be fine for now to include with $SUBJECT patch.
Kevin
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 681d823..c5cb9d0 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -245,6 +245,14 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
goto select_state;
}
+ /*
+ * Enable IRQs during the device activity checking and idle management.
+ * IRQs are later (re)disabled when entering the actual idle function.
+ * Device idle management that is using runtime PM needs to have
+ * interrupts enabled when calling into the runtime PM core.
+ */
+ local_irq_enable();
+
cx = cpuidle_get_statedata(state);
core_next_state = cx->core_state;
k
next prev parent reply other threads:[~2010-09-14 16:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-13 23:02 [PATCH 0/2] idle-path reorg for interrupt-enabled runtime PM Kevin Hilman
2010-09-13 23:02 ` [PATCH 1/2] OMAP3: PM: move device-specific special cases from PM core into CPUidle Kevin Hilman
2010-09-13 23:02 ` [PATCH 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path Kevin Hilman
2010-09-14 14:14 ` Varadarajan, Charulatha
2010-09-14 14:41 ` Kevin Hilman
2010-09-14 16:09 ` Basak, Partha
2010-09-14 16:57 ` Kevin Hilman [this message]
2010-09-15 8:02 ` Basak, Partha
2010-09-23 12:54 ` Basak, Partha
2010-09-23 15:38 ` Kevin Hilman
2010-09-23 19:57 ` Basak, Partha
2010-09-23 23:18 ` Kevin Hilman
2010-09-23 23:53 ` Kevin Hilman
2010-09-25 3:30 ` Basak, Partha
2010-09-27 14:53 ` Kevin Hilman
2010-09-22 8:22 ` Kalliguddi, Hema
2010-09-22 14:24 ` Kevin Hilman
2010-09-22 15:09 ` Kalliguddi, Hema
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=87d3sgs1nw.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=charu@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=p-basak2@ti.com \
--cc=tero.kristo@nokia.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: link
Be 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.