From: khilman@ti•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC 2/4] ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle
Date: Thu, 26 Jul 2012 10:44:25 -0700 [thread overview]
Message-ID: <87boj2s9hi.fsf@ti.com> (raw)
In-Reply-To: <50113B3C.4090608@ti.com> (Rajendra Nayak's message of "Thu, 26 Jul 2012 18:12:36 +0530")
Rajendra Nayak <rnayak@ti•com> writes:
> On Thursday 26 July 2012 04:13 AM, Kevin Hilman wrote:
>> Tero Kristo<t-kristo@ti•com> writes:
>>
>>> On Fri, 2012-07-20 at 13:38 +0530, Rajendra Nayak wrote:
>>>> On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
>>>>> On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayak<rnayak@ti•com> wrote:
>>>>>> pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency
>>>>>> operations done within cpuidle to do Powerdomain level book-keeping to know
>>>>>> what state transitions for different Powerdomains have been triggered.
>>>>>> This is also useful to do a restore-on-demand in some cases when we know
>>>>>> the context for the given Powerdomain was lost etc.
>>>>>>
>>>>>> Now that we have definitive entry/exit points (thanks to the Powerdomain
>>>>>> level usecounting) for Powerdomain transitions, these book-keeping functions
>>>>>> can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_
>>>>>> clkdm_disable() functions.
>>>>>>
>>>>>> Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition()
>>>>>> and get rid of the original ones which iterate over all powerdomains.
>>>>>>
>>>>>> Signed-off-by: Rajendra Nayak<rnayak@ti•com>
>>
>> This is excellent! Thanks for working on this.
>>
>> However, it needs a rebase against mainline though because I merged a
>> set of optimizations[1] to this code already that only calls pre/post
>> per-pwrdm.
>>
>
> Hi Kevin,
>
> I thought some more on this patch, and I think this way of collecting
> stats and knowing what state transitions the powerdomains been through
> will not work on OMAP3, mainly because of the autodeps. Might work on
> OMAP4 and beyond which do not need any autodeps.
>
> Here why I think so,
> Lets assume a Powerdomain X with a last module Y active, once Y disables
> the last clock (lets assume no hardware controlled clocks for
> simplicity), we clear the last power state register for X. However
> due to autodeps X does not transition to a target state immediately.
> It only does so when the MPU (and IVA) go down, and because
> of the wakeup dependency (autodeps set a sleep and a wakeup dep with
> both MPU and IVA) is also woken up every time MPU or IVA are up.
> So its quite possible that X transitions in and out of sleep multiple
> times before Y decides to re-enable its clocks, which is when we end up
> looking for the last power state entered.
> Lets say X entered OFF 3 times in between Y disabling and re-enabling
> its clocks. Though we end up updating the counter only once (instead of
> 3) we still know and can tell Y that it lost context.
> The problem however arises if for some reason X entered OFF
> twice and happened to stay ON the third time the dependencies were met.
> When Y re-enables its clocks, we end up telling it that it *did not*
> lose context because we see the previous power state was ON.
Yeah, this is definitely a problem.
As long as we have autodeps, everything is centralized around CPU
transitions anyways, so it makes sense to keep the accounting
centralized too.
> I think as long as we have autodeps, the only way on OMAP3 to accurately
> do this is to do it for all dependent domains in CPUIdle :(
Or, to get rid of autodeps. ;)
Kevin
next prev parent reply other threads:[~2012-07-26 17:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 6:04 [RFC 0/4] OMAP Cpuidle/Suspend Cleanups Rajendra Nayak
2012-07-20 6:04 ` [RFC 1/4] ARM: OMAP3: cpuidle: Remove unused MPU OSWR support code Rajendra Nayak
2012-07-20 7:08 ` Shilimkar, Santosh
2012-07-20 18:25 ` Paul Walmsley
2012-07-23 7:10 ` Rajendra Nayak
2012-07-20 6:04 ` [RFC 2/4] ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle Rajendra Nayak
2012-07-20 7:25 ` Shilimkar, Santosh
2012-07-20 8:08 ` Rajendra Nayak
2012-07-20 8:51 ` Tero Kristo
2012-07-20 11:54 ` Shilimkar, Santosh
2012-07-25 22:43 ` Kevin Hilman
2012-07-26 11:43 ` Rajendra Nayak
2012-07-26 12:42 ` Rajendra Nayak
2012-07-26 17:44 ` Kevin Hilman [this message]
2012-07-26 18:27 ` Tero Kristo
2012-07-26 20:50 ` Paul Walmsley
2012-07-27 6:46 ` Rajendra Nayak
2012-07-27 7:43 ` Rajendra Nayak
2012-07-20 6:04 ` [RFC 3/4] ARM: OMAP: powerdomain: Add .power_on/.power_down hooks for powerdomains Rajendra Nayak
2012-07-20 7:26 ` Shilimkar, Santosh
2012-07-20 6:04 ` [RFC 4/4] ARM: OMAP3: PM: Use .power_on/.power_down to clean omap_sram_idle Rajendra Nayak
2012-07-20 7:30 ` Shilimkar, Santosh
2012-07-20 8:59 ` [RFC 0/4] OMAP Cpuidle/Suspend Cleanups Tero Kristo
2012-07-20 9:03 ` Rajendra Nayak
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=87boj2s9hi.fsf@ti.com \
--to=khilman@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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