FIQ (was Motion Sensor Status)

Andy Green andy at
Fri Jan 25 02:01:34 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> Anyway INT is working as an INT pin now.
> Congratulations on slaying the dragon !

Thanks -- Tony/Willie/Miles put me in the right path otherwise I would
be giving a poor ST FAE a bad day for no reason... and might still be
wandering around clueless :-)

> I was afraid that we'd see bad latency :-( You could try to raise
> the scheduling priority of the workqueue, though, by scheduling
> something like the following work queue item during initialization:

Thanks for the tip.

>> I think this will improve when the excessive SPI bug is fixed, but it
>> still might not be very good to add 200 actions/sec through the scheduler.
> Yeah. That whole design a bit on the questionable side, and it's
> definitely begging for an ultra-low-overhead interrupt-driven
> SPI interface.

I made a start on this tonight and have a basically empty but working C
FIQ ISR now off timer 3, seems to have inherited a rate of something
like ~20K FIQ a second (~50us period) which doesn't make problems.

I plan to end up servicing

 - Motion sensors SPI (10ms / (3 x 16 clocks x 2 phases == ~100) ->
~100us FIQ period)

 - HDQ (IIRC we need ~30us FIQ period during these reads)

 - Vibrator PWM (Timer 3 was for this before)

with it using a FSM approach so we do one clock of protocol per FIQ to
be less noticeable.  If nothing is happening we don't need to run the
FIQ timer.

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list