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

[Simon Kagstrom]

On Sun, 16 Nov 2008 10:54:47 -0200
Werner Almesberger <werner at openmoko.org> wrote:

> Simon Kagstrom wrote:
> > 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).
> 
> Just to be clear: is what you're seeing here expected behaviour
> because you asked for an interrupt on every slight change ? Or do you
> think the number of interrupts is too large for the changes you get ?

I was surprised by it, but when thinking about the situation it's
perhaps natural. If the threshold is set to 18mg (1 in the register),
you catch all the jitter the device generates, so it should generate
interrupts basically all the time. What's strange is that it didn't
look like this with the edge-triggered interrupts, but in general I
don't think the behavior is unreasonable.

> It seems that the best combination for games would be a threshold AND
> a period. That way, you don't get interrupts until something has
> actually happened, and at the same time you're protected against user
> space getting starved by a flood of them (hmm, that's where the
> metaphor breaks down :-)

I've not experimented much with the duration, but I'm sure we'll see
many nice games centering around it ;-). The interface is there, so it
should be simple to play with.
 
> The AOI bit in FF_WU_CFG_x seems to be able to do just that.

Reading data sheets has increased my respect for the hermeneutic
tradition in philosophy a lot :-). Anyway, I think the AOI bit
specifies if an interrupt should be generated when ONE (or) or ALL
(and) inputs exceed a certain threshold (p33 in the application notes).

But again, I'm not sure what to make of this data sheet...

// Simon