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

Simon Kagstrom simon.kagstrom at gmail.com
Sun Nov 16 10:34:46 CET 2008


On Sun, 16 Nov 2008 16:22:46 +0700
Sean McNeil <sean at mcneil.com> wrote:

> > 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.

Well, stable-tracking uses your level-triggered interrupts anyway so I
don't think this should be a problem anymore (however the chip actually
work) :-)

One difference I saw compared to the edge-triggered ones was that with
a very small threshold, interrupts get generated at a very high rate
which causes considerable slow-down (almost to a halt). With data-ready
interrupts it's not so. I therefore raised the lowest threshold to
avoid this particular problem - the lowest are not very useful anyway
since the device continuously generates data even being stationary on a
table.

// Simon



More information about the openmoko-kernel mailing list