From: Kevin Hilman <khilman@deeprootsystems.com>
To: Kalle Jokiniemi <kalle.jokiniemi@digia.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"paul@pwsan.com" <paul@pwsan.com>,
Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com>
Subject: Re: [PATCH V2] OMAP3: Only update pm-counters when needed
Date: Fri, 30 Oct 2009 09:23:47 -0700 [thread overview]
Message-ID: <878wessve4.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1256902713.31764.141.camel@ubuntu> (Kalle Jokiniemi's message of "Fri\, 30 Oct 2009 13\:38\:33 +0200")
Kalle Jokiniemi <kalle.jokiniemi@digia.com> writes:
> On Fri, 2009-10-30 at 13:26 +0200, Kalle Jokiniemi wrote:
>> From: Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com>
>>
>> The biggest source of latency in idle loop (omap_sram_idle
>> function) comes from updating the state counters for each
>> power domain. The two purposes of these counters are to
>> provide debug data in debugfs, and to keep track of context
>> losses occurring during idle transitions (off mode counters).
>>
>> I created new debugfs interface "enable_count" for
>> enabling the "count" interface, which exposes the debug
>> part of these counters. The counters are not updated
>> anymore for CORE ON idle transitions, when the count
>> interface is disabled. For deeper CORE states, counters
>> are still updated to preserve context loss tracking.
>>
>> This change decreases C1/C2 state latency over 100us at
>> OPP2.
>>
>> Signed-off-by: Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com>
[...]
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index 01260ec..1e3041e 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -378,15 +378,16 @@ void omap_sram_idle(void)
>> return;
>> }
>>
>> - pwrdm_pre_transition();
>> + per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
>> + core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
>> +
>> + pwrdm_pre_transition(core_next_state != PWRDM_POWER_ON);
>
> I still left a little condition handling here, but it's nicer than the
> previous one, don't you think. Just passing this force_update parameter
> seemed like the most efficient way of doing it.
Yes, I'm OK with the 'force update' idea for now. You should just
update the changelog to talk about the force-update additon to the
transition hooks as well.
Other than that, looks fine with me for now.
Kevin
> I did not want to duplicate core state recording into powerdomain code,
> nor inefficient code looking for core pwrdm and then checking it's next
> state in powerdomain code. I think it's idle codes responsibility to
> know whether off-transitions will happen in general (do we need to force
> state counter update). Or at least that information is most efficiently
> available there now.
>
> We could consider cpuidle passing some "safe state" parameter, in case
> of C1/C2, which could be used instead of this core_next_state
> comparison. If you want to make it even nicer looking.
>
> - Kalle
>
>>
>> /* NEON control */
>> if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
>> pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
>>
>> /* PER */
>> - per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
>> - core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
>> if (per_next_state < PWRDM_POWER_ON) {
>> omap_uart_prepare_idle(2);
>> omap2_gpio_prepare_for_idle(per_next_state);
>> @@ -505,8 +506,7 @@ void omap_sram_idle(void)
>> omap3_disable_io_chain();
>> }
>>
>> -
>> - pwrdm_post_transition();
>> + pwrdm_post_transition(core_next_state != PWRDM_POWER_ON);
>>
>> omap2_clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
>> }
>> diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
>> index f00289a..71af2b8 100644
>> --- a/arch/arm/mach-omap2/powerdomain.c
>> +++ b/arch/arm/mach-omap2/powerdomain.c
>> @@ -1216,15 +1216,17 @@ int pwrdm_clk_state_switch(struct clk *clk)
>> return -EINVAL;
>> }
>>
>> -int pwrdm_pre_transition(void)
>> +int pwrdm_pre_transition(int force_update)
>> {
>> - pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
>> + if (pm_dbg_count_is_active() || force_update)
>> + pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
>> return 0;
>> }
>>
>> -int pwrdm_post_transition(void)
>> +int pwrdm_post_transition(int force_update)
>> {
>> - pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
>> + if (pm_dbg_count_is_active() || force_update)
>> + pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
>> return 0;
>> }
>>
>> diff --git a/arch/arm/plat-omap/include/mach/powerdomain.h b/arch/arm/plat-omap/include/mach/powerdomain.h
>> index fa64614..cb93272 100644
>> --- a/arch/arm/plat-omap/include/mach/powerdomain.h
>> +++ b/arch/arm/plat-omap/include/mach/powerdomain.h
>> @@ -176,7 +176,7 @@ int pwrdm_wait_transition(struct powerdomain *pwrdm);
>>
>> int pwrdm_state_switch(struct powerdomain *pwrdm);
>> int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
>> -int pwrdm_pre_transition(void);
>> -int pwrdm_post_transition(void);
>> +int pwrdm_pre_transition(int force_update);
>> +int pwrdm_post_transition(int force_update);
>>
>> #endif
prev parent reply other threads:[~2009-10-30 16:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-30 11:26 [PATCH V2] OMAP3: Only update pm-counters when needed Kalle Jokiniemi
2009-10-30 11:38 ` Kalle Jokiniemi
2009-10-30 16:23 ` Kevin Hilman [this message]
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=878wessve4.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=ext-kalle.jokiniemi@nokia.com \
--cc=kalle.jokiniemi@digia.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.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