PATCH/RFC [0/3]: Fix suspend and other acceleromter issues

Andy Green andy at
Sun Nov 16 10:19:11 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
| Somebody in the thread at some point said:
| |> For the accelerometers, the problem boils down to the FIFO not being
| What FIFO?  Where?  There's no FIFO in the accels.
|> I'm sure you know the hardware better than I, but behavior indicates
|> there is either some sort of internal FIFO or a buffer of some kind.
|> There is a bit that tells you when a sample is ready to read. That bit
|> can generate an interrupt. The old code would then read one sample on an
|> edge interrupt and return. The problem was that the bit could at times
|> not get reset because of delays and there are actually 2 samples to
|> read. We can solve by either making level trigger or looping until the
|> bit is cleared. I prefer level trigger because if it breaks we get an
|> interrupt storm but the phone still functions. Looping in an interrupt
|> can be hard to debug.

There's no fifo... if we know empirically that this looping definitely
affects the problem, then it means there is a window between reading the
first sample and looking for the second where a new sample interupt can
occur, and it also has to mean that the edge interrupt for the second
sample is ignored and / or lost if it happens in this window.

But if that's true and this window exists I can't see how we could
reduce the window to actually zero length by looping in the ISR,
whatever opens and closes that window (eg, "being in an ISR") is not an
atomic action.  The new sample interrupt can still happen just after the
last time we poll for it and get a negative response.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list