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

Simon Kagstrom simon.kagstrom at
Sun Nov 16 11:33:23 CET 2008

On Sun, 16 Nov 2008 10:18:32 +0000
Andy Green <andy at> 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

More information about the openmoko-kernel mailing list