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

Andy Green andy at
Sun Nov 16 10:41:10 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Sun, 16 Nov 2008 16:22:46 +0700
| Sean McNeil <sean at> 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.

We have to loop for up to 10ms then in the ISR is what you mean?  Then
we are really resynchronizing the ISR sample action to the source in an
expensive way.

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

Hum this sounds rather like the other problems we have seen when we try
to use level interrupts on 2442, somehow they are not acked properly and
we re-enter the service routine shortly after we exit it.  It doesn't
kill operation but makes it run very badly.  Maybe it's to do with this
not really understood lower level configuration of the handler as being
edge instead of level, Matt has seen the same when he tries to use level
on pcf50633 as he tries to work around in his recent patches at resume time.

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


More information about the openmoko-kernel mailing list