Re: omap3evm: touchscreen delays on pm branch

2009-12-01 Thread Sriram V
Hi,
  Have you enabled CPUFREQ? We faced a similar issue and was due to
ondemand governor.
 Selecting performance governors solved the issue.


Regards,
sriram





On Fri, Nov 27, 2009 at 4:04 PM, Hemanth V heman...@ti.com wrote:
 - Original Message - From: Premi, Sanjeev pr...@ti.com
 To: Dasgupta, Romit ro...@ti.com
 Cc: linux-omap@vger.kernel.org
 Sent: Friday, November 27, 2009 3:20 PM
 Subject: RE: omap3evm: touchscreen delays on pm branch


 -Original Message-
 From: Dasgupta, Romit Sent: Friday, November 27, 2009 2:38 PM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: RE: omap3evm: touchscreen delays on pm branch

 On Fri, 2009-11-27 at 14:11 +0530, Premi, Sanjeev wrote:
   -Original Message-
   From: Dasgupta, Romit   Sent: Friday, November 27, 2009 2:10 PM
   To: Premi, Sanjeev
   Cc: linux-omap@vger.kernel.org
   Subject: Re: omap3evm: touchscreen delays on pm branch
 Premi, Sanjeev wrote:
Hi,
   I am finding the response of touchscreen on the omap3evm very
   slow.
   Here is my test:
On console, I run : watch -n2 cat /proc/interrupts
Then, I tap the touchscreen approximately once per second. However,
(usually) no interrupts are registered. As I increase the frequency
of 'taps' more and more interrupts are registered. But still not
matching exact taps.
   However, when I keep the cpu busy with cat /dev/zero 
   /dev/null 
each tap is recognized.
  Do you see this even if we don't enable OFF?
Yes. Sleep_while_idle=0; enable_off_mode=0
  ~sanjeev

 Hopefully you have the same TSC driver. Nevertheless, can you please try
 this (just to see if clock domain idling is causing any problem or not):

 It is the same driver at SDP3430. I had earlier tried removing
 cpuidle altogether and did not see this issue. I too believe that
 issue is caused by clocks being going to (auto)idle.

 But then, Hemanth should be seeing the same behavior.

 Zoom2/Zoom3 use a different touchscreen driver compared to SDP.
 Its uses Synaptic Touchscreen over I2C.
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: omap3evm: touchscreen delays on pm branch

2009-12-01 Thread Premi, Sanjeev
 -Original Message-
 From: Sriram V [mailto:vshrir...@gmail.com] 
 Sent: Tuesday, December 01, 2009 3:36 PM
 To: V, Hemanth
 Cc: Premi, Sanjeev; Dasgupta, Romit; linux-omap@vger.kernel.org
 Subject: Re: omap3evm: touchscreen delays on pm branch
 
 Hi,
   Have you enabled CPUFREQ? We faced a similar issue and was due to
 ondemand governor.
  Selecting performance governors solved the issue.

Nope. No cpufreq. I did notice that CPIO175 was not being set
properly; have made local changes. It is a definite improvement;
but there are still very noticeable delays.

I will post the GPIO related patches in a few days; currently
drowned in few debug issues :(

Best regards,
Sanjeev

 
 
 Regards,
 sriram
 
 
 
 
 
 On Fri, Nov 27, 2009 at 4:04 PM, Hemanth V heman...@ti.com wrote:
  - Original Message - From: Premi, Sanjeev pr...@ti.com
  To: Dasgupta, Romit ro...@ti.com
  Cc: linux-omap@vger.kernel.org
  Sent: Friday, November 27, 2009 3:20 PM
  Subject: RE: omap3evm: touchscreen delays on pm branch
 
 
  -Original Message-
  From: Dasgupta, Romit Sent: Friday, November 27, 2009 2:38 PM
  To: Premi, Sanjeev
  Cc: linux-omap@vger.kernel.org
  Subject: RE: omap3evm: touchscreen delays on pm branch
 
  On Fri, 2009-11-27 at 14:11 +0530, Premi, Sanjeev wrote:
-Original Message-
From: Dasgupta, Romit   Sent: Friday, November 27, 
 2009 2:10 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: omap3evm: touchscreen delays on pm branch
  Premi, Sanjeev wrote:
 Hi,
I am finding the response of touchscreen on 
 the omap3evm very
slow.
Here is my test:
 On console, I run : watch -n2 cat /proc/interrupts
 Then, I tap the touchscreen approximately once per 
 second. However,
 (usually) no interrupts are registered. As I 
 increase the frequency
 of 'taps' more and more interrupts are registered. 
 But still not
 matching exact taps.
However, when I keep the cpu busy with cat 
 /dev/zero 
/dev/null 
 each tap is recognized.
   Do you see this even if we don't enable OFF?
 Yes. Sleep_while_idle=0; enable_off_mode=0
   ~sanjeev
 
  Hopefully you have the same TSC driver. Nevertheless, can 
 you please try
  this (just to see if clock domain idling is causing any 
 problem or not):
 
  It is the same driver at SDP3430. I had earlier tried removing
  cpuidle altogether and did not see this issue. I too believe that
  issue is caused by clocks being going to (auto)idle.
 
  But then, Hemanth should be seeing the same behavior.
 
  Zoom2/Zoom3 use a different touchscreen driver compared to SDP.
  Its uses Synaptic Touchscreen over I2C.
  --
  To unsubscribe from this list: send the line unsubscribe 
 linux-omap in
  the body of a message to majord...@vger.kernel.org
  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap3evm: touchscreen delays on pm branch

2009-12-01 Thread Romit Dasgupta
  Selecting performance governors solved the issue.
 
 Nope. No cpufreq. I did notice that CPIO175 was not being set
 properly; have made local changes. It is a definite improvement;
 but there are still very noticeable delays.
 

If PER Power domain is entering RET then module wakeups wont work! If at C2 you
are seeing this then it might explain.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap3evm: touchscreen delays on pm branch

2009-11-27 Thread Romit Dasgupta
Premi, Sanjeev wrote:
 Hi,
 
 I am finding the response of touchscreen on the omap3evm very slow.
 
 Here is my test:
 On console, I run : watch -n2 cat /proc/interrupts
 Then, I tap the touchscreen approximately once per second. However,
 (usually) no interrupts are registered. As I increase the frequency
 of 'taps' more and more interrupts are registered. But still not
 matching exact taps.
 
 However, when I keep the cpu busy with cat /dev/zero  /dev/null 
 each tap is recognized.
 
Do you see this even if we don't enable OFF?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: omap3evm: touchscreen delays on pm branch

2009-11-27 Thread Premi, Sanjeev
 -Original Message-
 From: Dasgupta, Romit 
 Sent: Friday, November 27, 2009 2:10 PM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: Re: omap3evm: touchscreen delays on pm branch
 
 Premi, Sanjeev wrote:
  Hi,
  
  I am finding the response of touchscreen on the omap3evm very slow.
  
  Here is my test:
  On console, I run : watch -n2 cat /proc/interrupts
  Then, I tap the touchscreen approximately once per second. However,
  (usually) no interrupts are registered. As I increase the frequency
  of 'taps' more and more interrupts are registered. But still not
  matching exact taps.
  
  However, when I keep the cpu busy with cat /dev/zero  /dev/null 
  each tap is recognized.
  
 Do you see this even if we don't enable OFF?
 
Yes. Sleep_while_idle=0; enable_off_mode=0
~sanjeev--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: omap3evm: touchscreen delays on pm branch

2009-11-27 Thread Romit Dasgupta
On Fri, 2009-11-27 at 14:11 +0530, Premi, Sanjeev wrote:
  -Original Message-
  From: Dasgupta, Romit 
  Sent: Friday, November 27, 2009 2:10 PM
  To: Premi, Sanjeev
  Cc: linux-omap@vger.kernel.org
  Subject: Re: omap3evm: touchscreen delays on pm branch
  
  Premi, Sanjeev wrote:
   Hi,
   
   I am finding the response of touchscreen on the omap3evm very slow.
   
   Here is my test:
   On console, I run : watch -n2 cat /proc/interrupts
   Then, I tap the touchscreen approximately once per second. However,
   (usually) no interrupts are registered. As I increase the frequency
   of 'taps' more and more interrupts are registered. But still not
   matching exact taps.
   
   However, when I keep the cpu busy with cat /dev/zero  /dev/null 
   each tap is recognized.
   
  Do you see this even if we don't enable OFF?
  
 Yes. Sleep_while_idle=0; enable_off_mode=0
 ~sanjeev

Hopefully you have the same TSC driver. Nevertheless, can you please try
this (just to see if clock domain idling is causing any problem or not):

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1cfa5a6..79710a1 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -248,7 +248,8 @@ void omap_init_power_states(void)
cpuidle_params_table[OMAP3_STATE_C2].threshold;
omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
-   omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID;
+   omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID |
+   CPUIDLE_FLAG_CHECK_BM;
 
/* C3 . MPU CSWR + Core inactive */
omap3_power_states[OMAP3_STATE_C3].valid =

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: omap3evm: touchscreen delays on pm branch

2009-11-27 Thread Premi, Sanjeev
 -Original Message-
 From: Dasgupta, Romit 
 Sent: Friday, November 27, 2009 2:38 PM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: RE: omap3evm: touchscreen delays on pm branch
 
 On Fri, 2009-11-27 at 14:11 +0530, Premi, Sanjeev wrote:
   -Original Message-
   From: Dasgupta, Romit 
   Sent: Friday, November 27, 2009 2:10 PM
   To: Premi, Sanjeev
   Cc: linux-omap@vger.kernel.org
   Subject: Re: omap3evm: touchscreen delays on pm branch
   
   Premi, Sanjeev wrote:
Hi,

I am finding the response of touchscreen on the 
 omap3evm very slow.

Here is my test:
On console, I run : watch -n2 cat /proc/interrupts
Then, I tap the touchscreen approximately once per 
 second. However,
(usually) no interrupts are registered. As I increase 
 the frequency
of 'taps' more and more interrupts are registered. But still not
matching exact taps.

However, when I keep the cpu busy with cat /dev/zero  
 /dev/null 
each tap is recognized.

   Do you see this even if we don't enable OFF?
   
  Yes. Sleep_while_idle=0; enable_off_mode=0
  ~sanjeev
 
 Hopefully you have the same TSC driver. Nevertheless, can you 
 please try
 this (just to see if clock domain idling is causing any 
 problem or not):

It is the same driver at SDP3430. I had earlier tried removing
cpuidle altogether and did not see this issue. I too believe that
issue is caused by clocks being going to (auto)idle.

But then, Hemanth should be seeing the same behavior.

~sanjeev

 
 diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
 b/arch/arm/mach-omap2/cpuidle34xx.c
 index 1cfa5a6..79710a1 100644
 --- a/arch/arm/mach-omap2/cpuidle34xx.c
 +++ b/arch/arm/mach-omap2/cpuidle34xx.c
 @@ -248,7 +248,8 @@ void omap_init_power_states(void)
   cpuidle_params_table[OMAP3_STATE_C2].threshold;
   omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
   omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
 - omap3_power_states[OMAP3_STATE_C2].flags = 
 CPUIDLE_FLAG_TIME_VALID;
 + omap3_power_states[OMAP3_STATE_C2].flags = 
 CPUIDLE_FLAG_TIME_VALID |
 + CPUIDLE_FLAG_CHECK_BM;
  
   /* C3 . MPU CSWR + Core inactive */
   omap3_power_states[OMAP3_STATE_C3].valid =
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap3evm: touchscreen delays on pm branch

2009-11-27 Thread Romit Dasgupta
 
 It is the same driver at SDP3430. I had earlier tried removing
 cpuidle altogether and did not see this issue. I too believe that
 issue is caused by clocks being going to (auto)idle.
 
 But then, Hemanth should be seeing the same behavior.
Do you see PER powerdomain entering retention?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap3evm: touchscreen delays on pm branch

2009-11-27 Thread Hemanth V
- Original Message - 
From: Premi, Sanjeev pr...@ti.com

To: Dasgupta, Romit ro...@ti.com
Cc: linux-omap@vger.kernel.org
Sent: Friday, November 27, 2009 3:20 PM
Subject: RE: omap3evm: touchscreen delays on pm branch



-Original Message-
From: Dasgupta, Romit 
Sent: Friday, November 27, 2009 2:38 PM

To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: RE: omap3evm: touchscreen delays on pm branch

On Fri, 2009-11-27 at 14:11 +0530, Premi, Sanjeev wrote:
  -Original Message-
  From: Dasgupta, Romit 
  Sent: Friday, November 27, 2009 2:10 PM

  To: Premi, Sanjeev
  Cc: linux-omap@vger.kernel.org
  Subject: Re: omap3evm: touchscreen delays on pm branch
  
  Premi, Sanjeev wrote:

   Hi,
   
   I am finding the response of touchscreen on the 
omap3evm very slow.
   
   Here is my test:

   On console, I run : watch -n2 cat /proc/interrupts
   Then, I tap the touchscreen approximately once per 
second. However,
   (usually) no interrupts are registered. As I increase 
the frequency

   of 'taps' more and more interrupts are registered. But still not
   matching exact taps.
   
   However, when I keep the cpu busy with cat /dev/zero  
/dev/null 

   each tap is recognized.
   
  Do you see this even if we don't enable OFF?
  
 Yes. Sleep_while_idle=0; enable_off_mode=0

 ~sanjeev

Hopefully you have the same TSC driver. Nevertheless, can you 
please try
this (just to see if clock domain idling is causing any 
problem or not):


It is the same driver at SDP3430. I had earlier tried removing
cpuidle altogether and did not see this issue. I too believe that
issue is caused by clocks being going to (auto)idle.

But then, Hemanth should be seeing the same behavior.


Zoom2/Zoom3 use a different touchscreen driver compared to SDP.
Its uses Synaptic Touchscreen over I2C.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap3evm: touchscreen delays on pm branch

2009-11-26 Thread Hemanth V
- Original Message - 
From: Premi, Sanjeev pr...@ti.com

To: linux-omap@vger.kernel.org
Sent: Thursday, November 26, 2009 10:32 PM
Subject: omap3evm: touchscreen delays on pm branch



Hi,

I am finding the response of touchscreen on the omap3evm very slow.

Here is my test:
On console, I run : watch -n2 cat /proc/interrupts
Then, I tap the touchscreen approximately once per second. However,
(usually) no interrupts are registered. As I increase the frequency
of 'taps' more and more interrupts are registered. But still not
matching exact taps.

However, when I keep the cpu busy with cat /dev/zero  /dev/null 
each tap is recognized.

EVM uses GPIO175 for touchscreen. I notice that Zoom2 uses GPIO102.
Both are not on BANK0.

Is the behavior same on ZOOM2 as well?


I dont see this problem on Zoom2/Zoom3, I am able to see interrupts being
incremented for every touch.



Best regards,
Sanjeev
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html