[PATCH] (repost) lis302dl-queue-work-in-interrupt-handler.patch

Andy Green andy at openmoko.com
Tue Sep 23 10:30:48 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> So about the hanging problem: Did I understand the situation correct
|> that it is caused by the device having reported values into the
|> out-registers while in the interrupt handler (which is subsequently
|> missed as this is an edge interrupt).
|
| I think the fundamental problem is that the interrupt pin is a level
| where it indicates that data is available to read from the
| accelerometer. So, I actually think your approach would work just fine.
| You can either:
|
| a) use a level interrupt and do things in the irq handler.
| b) use an edge trigger interrupt and do things in a work_queue where it
| assures that the line will go high again so that a new interrupt can
happen.
|
| Which means you have to loop until no data in the work_queue as you have
| done.

The hole there it seems is if interrupts can be lost at all, they can be
lost after the workqueue has fired and now nothing will come and set
things right.

As Simon found (BTW props for putting numbers on it) workqueue is not
viable way for 2 x 100 interrupt a second source anyway.

If you are finding level interrupt is working OK, that's a better
solution since it is "sticky", but the reason it is edge at the moment
is that level made trouble before (this was early 2008 but it is on the
list archives somewhere).  So trying level if that is somehow better on
2.6.26, or the problems were actually elsewhere before, sounds safest way.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjYqTgACgkQOjLpvpq7dMq4sQCcDSEydeGS7LwBb66cy7JV0UHS
DtMAnjmB32TPlG+g8HtE9cbxIaElf+tL
=V9M1
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list