Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #2328: touschreen sometimes stops generating
events (Openmoko Public Trac)
--- Begin Message ---
#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):
issue is caused by thing i called 'unexpected interrupts'. then device is
touched up/down interrupt recieved, but original drivers do not rely on
interrupt cause, they check adc registers for current state instead. this
may cause that 'down' interrupt recieved while handler thinks this is
'up', that leads to situation then driver no longer watch for down
interrupts and ts generate no events until ts driver reload. other
situation then 'up' interrupt is interpreted as 'down' sometimes lead to
data corruption is adc conversion and 'number remaining of samples need'
can go below 0, so adc conversion will be requested for infinite amount of
times. in this case attempt to reloading module will hang system. as
driver written with some 'states' in mind it can't handle such interrupts
and in fact they are not interesting for us (is we already have pen down,
no need for more interrupt informing as about this), so we have to ignore
em.
for me some thing left unexplained - sometimes recieving interrupts while
we totally not expect them, and why we see this problem only on kernel
without debugging information.
mine solution for this is to accept only expected interrupts.
some logs of failures with added debug info:
http://www.bsdmn.com/openmoko/kernel/touchscreen/34failexpectupgotdown.log
http://www.bsdmn.com/openmoko/kernel/touchscreen/34failexpectdowngotup.log
http://www.bsdmn.com/openmoko/kernel/touchscreen/34unknowunexpected.log
patches for .34 and .29 kernel:
http://www.bsdmn.com/openmoko/kernel/touchscreen/touchscreen_ignoreunexpectedintr29.patch
http://www.bsdmn.com/openmoko/kernel/touchscreen/touchscreen_ignoreunexpectedintr34.patch
.34 patch were tested much more than .29 version for which only basic test
very done.
i hope this bug fix is good step forward to kernel optimized for speed.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2328#comment:6>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
