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

Andy Green andy at
Sun Nov 16 11:53:00 CET 2008

Hash: SHA1

Sean McNeil wrote:

> I don't see why we need both level interrupt and looping in the ISR.  If
> we have level interrupt, we will just come back into the ISR immediately
> on exit from it in the case a new sample came in the window between
> reading the registers and exiting the ISR.  So explicit looping would be
> redundant.
>> Yes, Agreed and we don't loop with level interrupts.

OK, that's half the issue agreed then.

> If we have edge interrupt, it shouldn't make any difference either: if
> the second interrupt came before we read the XYZ then the old sample is
> lost overrun-style but the new one is fetched and acknowledged; if it
> comes after we cleared the interrupt by reading XYZ it should be
> recognized as a new interrupt by the CPU hardware and like on level we
> should re-enter the ISR on exiting it.
>> Like I said, just reading the sample doesn't cause an acknowledge. There
>> is a possibility that the line never toggles.

I read the datasheets (we have two now) for lis302dl again before
writing that last mail and I did not find an explanation for what clears
the interrupt source in hardware there.  Reading between the lines we
are interrupted if "new" X, Y or Z sample is ready, I expect we make
those "new" samples "old" and so clear them as interrupt source by
reading the samples.  So "just reading the sample" does "cause an
acknowledge" down on the lis302dl.  But AIUI we don't clear the CPU
interrupt source until we leave the ISR and that's done automagically.
That can make this small "window" where getting a new edge interrupt
between stopping SPI actions in the ISR and leaving the ISR will get the
CPU copy of it having happened gratuitously cleared.  It should be very
very low probability event though, much lower than the stalls seen
before, since it not only requires 9.9xxms latency on ISR but it has to
be quite exactly wrong to find the window.  It's a once-a-month kind of
thing I would think.

>> Unless you read samples until the bit toggles, you'll still have this
>> problem when the ISR is sufficiently delayed. With edge trigger, you must:

Which bit... the Status we read over SPI from lis302dl?  It still leaves
the window open a little as described above for edge.

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


More information about the openmoko-kernel mailing list