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

Sean McNeil sean at
Sun Nov 16 11:26:10 CET 2008

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

Yes, Agreed and we don't loop with level interrupts.

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

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

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:

while(sample_available) {

I guess we could just throw away the older sample and only generate an 
input event for the last one.

> | 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 -
> iEYEARECAAYFAkkf83gACgkQOjLpvpq7dMpmpgCcDpVcrhLbKwe2HR/iEBqzPmxT
> j1YAn1BPnDdIzpiI1954SEKOAsKNlYF2
> =nqam

More information about the openmoko-kernel mailing list