OMAP baseline test results for v3.7-rc2

Commit Message

Kevin Hilman Oct. 23, 2012, 1:04 a.m. UTC

+Igor

Paul Walmsley <[e-mail]> writes:

> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
>
>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/

[...]

> * 37xx EVM: CORE not entering dynamic off-idle
>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>     off works

I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
SPI1 was not idle when going off.  A quick hack disabling the
touchscreen showed that after that, core was hitting idle just fine.

I ran out of time today debugging this, but it's definitely realted to
the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
makes CORE hit retention again in idle.

Igor, I'm hoping you might know what's going on here since we already
had some problems with this ads7846 init stuff and you're more familiar
with this debounce init.

Kevin

[1]

Comments

Kevin Hilman Oct. 23, 2012, 6:19 p.m. UTC | #1

Kevin Hilman <[e-mail]> writes:

> +Igor
>
> Paul Walmsley <[e-mail]> writes:
>
>> Here are some basic OMAP test results for Linux v3.7-rc2.
>> Logs and other details at:
>>
>>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>
> [...]
>
>> * 37xx EVM: CORE not entering dynamic off-idle
>>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>>     off works
>
> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
> SPI1 was not idle when going off.  A quick hack disabling the
> touchscreen showed that after that, core was hitting idle just fine.
>
> I ran out of time today debugging this, but it's definitely realted to
> the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
> makes CORE hit retention again in idle.

OK, found the root cause of this in the GPIO driver.  Patch submitted:

    http://marc.info/?l=linux-omap&m=135101577925972&w=2

however...

> Igor, I'm hoping you might know what's going on here since we already
> had some problems with this ads7846 init stuff and you're more familiar
> with this debounce init.

... board files that are setting debounce values for ads7846 will no
longer work.  

Currently, omap_ads7846_init() in common-board-devices.c does this:

   gpio_request_one()
   gpio_set_debounce()
   gpio_free()                    

because of a bug in the GPIO driver, the debounce settings were sticky
and lingered even after the gpio_free().  That bug has been fixed by the
above patch, which means the above gpio_set_debounce() is completely
pointless because it's followed immediately by a gpio_free().

IMO, the whole GPIO init for the ads7846 needs a rethink as it's
currently partially done by common-board-devices.c and done (again) in
the ads7846 driver.  If the gpio_free() isn't done in
common-board-devices, then the ads7846 driver will currently fail to
probe/load becasue it can't request a GPIO line.

Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
somone else.

Kevin

Igor Grinberg Oct. 24, 2012, 9:01 a.m. UTC | #2

On 10/23/12 20:19, Kevin Hilman wrote:
> Kevin Hilman <[e-mail]> writes:
> 
>> +Igor
>>
>> Paul Walmsley <[e-mail]> writes:
>>
>>> Here are some basic OMAP test results for Linux v3.7-rc2.
>>> Logs and other details at:
>>>
>>>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>>
>> [...]
>>
>>> * 37xx EVM: CORE not entering dynamic off-idle
>>>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>>>     off works
>>
>> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
>> SPI1 was not idle when going off.  A quick hack disabling the
>> touchscreen showed that after that, core was hitting idle just fine.
>>
>> I ran out of time today debugging this, but it's definitely realted to
>> the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
>> makes CORE hit retention again in idle.
> 
> OK, found the root cause of this in the GPIO driver.  Patch submitted:
> 
>     http://marc.info/?l=linux-omap&m=135101577925972&w=2

Ok that one looks good.

> 
> however...
> 
>> Igor, I'm hoping you might know what's going on here since we already
>> had some problems with this ads7846 init stuff and you're more familiar
>> with this debounce init.
> 
> ... board files that are setting debounce values for ads7846 will no
> longer work.  
> 
> Currently, omap_ads7846_init() in common-board-devices.c does this:
> 
>    gpio_request_one()
>    gpio_set_debounce()
>    gpio_free()                    
> 
> because of a bug in the GPIO driver, the debounce settings were sticky
> and lingered even after the gpio_free().  That bug has been fixed by the
> above patch, which means the above gpio_set_debounce() is completely
> pointless because it's followed immediately by a gpio_free().
> 
> IMO, the whole GPIO init for the ads7846 needs a rethink as it's
> currently partially done by common-board-devices.c and done (again) in
> the ads7846 driver.  If the gpio_free() isn't done in
> common-board-devices, then the ads7846 driver will currently fail to
> probe/load becasue it can't request a GPIO line.
> 
> Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
> somone else.

Ok, understood, I'll look into this one soon.

Patch

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..3afdc50 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -734,7 +734,7 @@  static void __init omap3_evm_init(void)
 	omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
 			     ARRAY_SIZE(omap3evm_nand_partitions));
 
-	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
+	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 0, NULL);
 	omap3evm_init_smsc911x();
 	omap3_evm_display_init();
 	omap3_evm_wl12xx_init();