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

Sean McNeil sean at
Sun Nov 16 10:22:46 CET 2008

Andy Green wrote:
> 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.

But thats OK because if we loop until the line toggles then we will get 
another edge interrupt. The problem is that we aren't really clearing 
out the cause of the interrupt in the ISR.

> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> iEYEARECAAYFAkkf5Y8ACgkQOjLpvpq7dMqb/QCeMJObWolFJP19NhHnaJ5K63iR
> btwAnjyqVhtzbaKervJJlFyRBVeFgY9o
> =U8nV

More information about the openmoko-kernel mailing list