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

Andy Green andy at
Sun Nov 16 11:18:32 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

|> There is no magic number as far as I know. Most of the time, the cause
|> is cleared out by reading the one sample. That is why we see data for a
|> while before it suddenly hangs. What I'm saying is that reading the
|> sample doesn't guarantee that you will clear the cause and toggle the
|> interrupt line. If there is sufficient delay before the ISR runs, then
|> reading the sample isn't good enough because there was another one ready
|> immediately and the IRQ didn't toggle.

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

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.

Somehow for edge to fail we need our SPI bitbang to be screwed up (so we
never actually succeed to clear the interrupt source when we think we
read XYZ), or this "window" business where there is a bad moment to get
a second edge interrupt for some reason.

In the past we didn't block interrupts right around the service and /sys
stuff, and since we have two indepenent accels with async interrupt
requests sharing the same SPI bus my belief is that was enough to tread
on each others' communication for the ISR action and cause the inability
to see more edges.  The bitbang-all-the-way and other patches nailed
interrupt locking right down everywhere and if we don't see the symptom
any more I guess that was it.  But using level would recover from even that.

Maybe what we should do is go back to edge as a test and see if we are
still solid now, meaning we fixed the underlying "treading on toes"
issue already.

| 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.
|> Yes, that is what happens here now when too slow. We just get another
|> interrupt immediately when level triggered.

These problems involve some kind of continuous reentry even if you clear
the source somehow, the whole device becomes very slow indeed.  I think
this may be what Simon refers to along with people complaining that Doom
becomes unusable unless they set the accel threshold (and so reduce
incidence of interrupts).

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


More information about the openmoko-kernel mailing list