On Sun, 16 Nov 2008 10:18:32 +0000 Andy Green <[EMAIL PROTECTED]> wrote:
> 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. I didn't see any problems under the stable tree where edge-triggered interrupts are used. Anyway, I think the current level-triggered scheme should solve also the potential issues we might have if we are unlucky, so we should be in the clear now. > |> 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). Well, the interesting thing which I noticed with the level-triggered interrupts was that using no threshol (data ready interrupts) are a lot less invasive (time is mostly spent in userspace) than using the small threshold (when >90% of the time is spent handling interrupts). According to top. For something like doom I think it makes a lot of sense to have some sort of threshold configured, I guess the interesting part is how to integrate this knowledge in the gesture recognition daemon or whatever will re-export the accelerometers to userspace in the future. // Simon
