PATCH/RFC [0/3]: Fix suspend and other acceleromter issues
sean at mcneil.com
Sun Nov 16 11:26:10 CET 2008
Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> |> 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
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
> 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:
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
> | 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
> | 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
More information about the openmoko-kernel