-----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 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. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkf83gACgkQOjLpvpq7dMpmpgCcDpVcrhLbKwe2HR/iEBqzPmxT j1YAn1BPnDdIzpiI1954SEKOAsKNlYF2 =nqam -----END PGP SIGNATURE-----
