From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Premi, Sanjeev" <premi@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 1/1] PM : cpuidle - update statistics for correct state
Date: Tue, 29 Sep 2009 08:36:52 -0700 [thread overview]
Message-ID: <87pr99zrsb.fsf@deeprootsystems.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301DDAB4053@dbde02.ent.ti.com> (Sanjeev Premi's message of "Tue\, 29 Sep 2009 20\:11\:35 +0530")
"Premi, Sanjeev" <premi@ti.com> writes:
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Thursday, September 10, 2009 11:51 PM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: [PATCH 1/1] PM : cpuidle - update statistics for
>> correct state
>>
>> Sanjeev Premi <premi@ti.com> writes:
>>
>> > When 'enable_off_mode' is 0, the target power state for MPU
>> > and Core is locally changed to PWRDM_POWER_RET but, the
>> > statistics are updated for idle state originally selected
>> > by the governor.
>> >
>> > This patch 'invalidates' the idle states that lead either of
>> > MPU or Core to PWRDM_POWER_OFF state when 'enable_off_mode'
>> > is '0'. The states are valid once 'enable_off_mode' is set
>> > to '1'.
>> >
>> > Signed-off-by: Sanjeev Premi <premi@ti.com>
>>
>> This is a good start, but doesn't actually fix the problem. This is
>> because the 'valid' field is an OMAP specific field and is not checked
>> in any of our 'enter_idle' hooks.
>>
>> It works in your test case because the code snippet you mentioned in
>> PATCH 0/0 still modifies the target state.
>>
>> What we need is for the enter_idle_bm() enter function to check the
>> .valid flag. If it's not valid, then keep dropping states until it
>> finds a valid flag or it hits the safe state.
>
> We do have a omap3_enter_idle_bm(), but the problem is that calculating
> the current index in dev->states will be costly operation. We know the
> pointer to 'target' c-state; but the translating the index back to the
> omap3_power_states[] seems 'intense' operation in idle_bm check.
Maybe this array should be converted to a list.
> I believe the right solution will be to add .valid in the cpuidle framework
> itself. I am submitting a patch for same.
I like this idea better.
Kevin
next prev parent reply other threads:[~2009-09-29 15:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-05 9:56 [PATCH 1/1] PM : cpuidle - update statistics for correct state Sanjeev Premi
2009-09-10 18:20 ` Kevin Hilman
2009-09-29 14:41 ` Premi, Sanjeev
2009-09-29 15:36 ` Kevin Hilman [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-09-04 19:34 Sanjeev Premi
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=87pr99zrsb.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=premi@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: 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.