Openmoko Bug #2328: touschreen sometimes stops generating events

[Openmoko Public Trac]

#2328: touschreen sometimes stops generating events
--------------------+-------------------------------------------------------
 Reporter:  lindi   |          Owner:  openmoko-kernel
     Type:  defect  |         Status:  new            
 Priority:  normal  |      Milestone:                 
Component:  kernel  |        Version:                 
 Severity:  normal  |       Keywords:  touchscreen    
 Haspatch:  0       |      Blockedby:                 
Estimated:          |    Patchreview:                 
 Blocking:          |   Reproducible:  rarely         
--------------------+-------------------------------------------------------

Comment(by gena2x):

 I spent some time trying to investigate this (or similar?) issue.

 I got problems then i changed optimization from optimization for size to
 optimization for speed (for andy-tracking).

 Perfectly reproducible.

 Interesting thing i found while investigation is that our touchscreen
 sometimes start sending absolutely correct events (no need to filter).
 This happens then screen is blanked for some period and perfectly
 reproducible too.

 Reloading touchscreen module restores functionality.

 I can't recall correctly (i did investigation in Feb) but problem real
 causes were following:

 dmesg is like following:

 ...
 Jan  1 03:49:06 debian-gta02 kernel: [ 2539.550000] s3c2440-ts s3c2440-ts:
 Stylus timer, down state, samples: 1, 1, 4
 Jan  1 03:49:06 debian-gta02 kernel: [ 2539.550000] s3c2440-ts s3c2440-ts:
 Stylus irq, down state: 0, 0
 Jan  1 03:49:06 debian-gta02 kernel: [ 2539.550000] s3c2440-ts s3c2440-ts:
 stylus_irq: count=4
 Jan  1 03:49:06 debian-gta02 kernel: [ 2539.560000] s3c2440-ts s3c2440-ts:
 Stylus irq, down state: 0, 0
 Jan  1 03:49:06 debian-gta02 kernel: [ 2539.560000] s3c2440-ts s3c2440-ts:
 stylus_irq: count=4
 Jan  1 03:49:06 debian-gta02 kernel: [ 2539.565000] s3c2440-ts s3c2440-ts:
 Stylus timer, down state, samples: 0, 0, 4
 Jan  1 03:49:06 debian-gta02 kernel: [ 2540.005000] s3c2440-ts s3c2440-ts:
 Stylus irq, down state: 1, 1
 Jan  1 03:49:06 debian-gta02 kernel: [ 2540.010000] s3c2440-ts s3c2440-ts:
 Stylus timer, down state, samples: 1, 1, 4
 Jan  1 03:49:06 debian-gta02 kernel: [ 2540.020000] s3c2440-ts s3c2440-ts:
 Stylus timer, down state, samples: 1, 1, 4
 [...same...]
 Jan  1 03:49:06 debian-gta02 kernel: [ 2540.135000] s3c2440-ts s3c2440-ts:
 Stylus timer, down state, samples: 1, 1, 4
 Jan  1 03:49:06 debian-gta02 kernel: [ 2540.140000] s3c2440-ts s3c2440-ts:
 Stylus timer, down state, samples: 1, 1, 4
 Jan  1 03:49:06 debian-gta02 kernel: [ 2540.145000] s3c2440-ts s3c2440-ts:
 Stylus irq, down state: 0, 0
 Jan  1 03:49:06 debian-gta02 kernel: [ 2540.145000] s3c2440-ts s3c2440-ts:
 stylus_irq: count=4
 Jan  1 03:49:06 debian-gta02 kernel: [ 2540.150000] s3c2440-ts s3c2440-ts:
 Stylus irq, down state: 1, 0

 "Stylus irq, down state: 0, 0' is a 'up' interrupt
 up prints also 'stylus_irq: count=?', this is count of measurements ready
 at this point.

 "Stylus irq, down state: 1, ?' is a 'down' interrupt
 down starts 'timer'

 main source of info about interrupt is reading registers after each
 conversion/on interrupt. if that registers return 1 - ts is down. and we
 start timer and adc. then it is 'up' 0 we only start waiting for down.
 (this seen unneeded for me as we already know what are we waiting, we can
 say state=!state, but this not works somehow)

 this down state '1,1' is normal situation, the '1,0' is then bug occured.

 so, interrupt happens but adc registers report stylus is 'up'. and so they
 do forever from some point. I rewrited driver to check only interrupts,
 but somehow this didn't helped. i tried other ideas also, but without
 success.

 all the tests are from .34-backported (as it was in february) driver
 without filtering.

 i fact i also did some investigation on touchscreen buzz, i tried
 different combinations of delays, and scaling and all without luck too.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2328#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac