linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).