RE: [PATCH 2/3] PM: Skip PER previous state register read

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Kevin, 

>-----Original Message-----
>From: linux-omap-owner@xxxxxxxxxxxxxxx 
>[mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of ext Kevin Hilman
>Sent: 30. lokakuuta 2009 18:32
>To: Kalle Jokiniemi
>Cc: linux-omap@xxxxxxxxxxxxxxx
>Subject: Re: [PATCH 2/3] PM: Skip PER previous state register read
>
>Kalle Jokiniemi <kalle.jokiniemi@xxxxxxxxx> writes:
>
>> According to measurements, reading the previous state of PER domain 
>> after wfi takes ~11us on OPP2.
>>
>> Removed this unneccessary latency from cases where we know PER power 
>> domain did not try to enter off mode.
>>
>> Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@xxxxxxxxx>
>
>Looks good, pulling into PM branch.
>
>But still amazed at such a *huge* latency to read that register.

We talked about this with Peter, and he suggested the reason might
be that the register is in WKUP domain, which runs on slow clock.
Checking from TRM, it is mentioned that at least in low-power mode,
the 32k clock is used in PRM. Could not figure out what is used in
normal mode, though. 

Probably the same reason makes the debug counter updates so slow.

- Kalle


>
>Kevin
>
>> ---
>>  arch/arm/mach-omap2/pm34xx.c |   19 +++++++++++++------
>>  1 files changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c 
>> b/arch/arm/mach-omap2/pm34xx.c index 237c819..b70ea19 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -489,12 +489,19 @@ void omap_sram_idle(void)
>>  
>>  	/* PER */
>>  	if (per_next_state < PWRDM_POWER_ON) {
>> -		per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
>> -		if (per_prev_state == PWRDM_POWER_OFF) {
>> -			omap3_per_restore_context();
>> -			omap3_gpio_restore_pad_context(0);
>> -		} else if (per_next_state == PWRDM_POWER_OFF)
>> -			omap3_gpio_restore_pad_context(1);
>> +		if (per_next_state == PWRDM_POWER_OFF) {
>> +			/*
>> +			 * Reading the prev-state takes long 
>time (11us@OPP2),
>> +			 * only do it, if we really tried to 
>put PER in OFF
>> +			 */
>> +			per_prev_state = 
>pwrdm_read_prev_pwrst(per_pwrdm);
>> +			if (per_prev_state == PWRDM_POWER_OFF) {
>> +				omap3_per_restore_context();
>> +				omap3_gpio_restore_pad_context(0);
>> +			} else if (per_next_state == PWRDM_POWER_OFF) {
>> +				omap3_gpio_restore_pad_context(1);
>> +			}
>> +		}
>>  		omap2_gpio_resume_after_idle();
>>  		omap_uart_resume_idle(2);
>>  		if (per_state_modified)
>> --
>> 1.5.4.3
>--
>To unsubscribe from this list: send the line "unsubscribe 
>linux-omap" in the body of a message to 
>majordomo@xxxxxxxxxxxxxxx More majordomo info at  
>http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux