Mokopatches, accelerometers and delaying work

Andy Green andy at
Tue Oct 7 20:42:13 CEST 2008

Hash: SHA1

Simon Kagstrom wrote:
> Hi!
> I saw the mokopatches git tree today, which I guess is the patches
> destined for upstream submission. There I saw that the accelerometer
> driver once again schedules work in a work queue in the interrupt
> handler.

Ah no Mokopatches branches are our patchset as it was several months ago
when we switched to git.

But a few weeks back the git server filled up and the repo got
corrupted, I didn't push these branches back up there until recently.
But their content is several months old, it's rebased on -tracking and
- -2.6.26 versions though.

The patches in stable, stable-2.6.26, and stable-tracking go on top of
the mokopatches to form the actual tree.

> 	spi_async(spi_dev, m);

> Getting new interrupts while running lis302dl_work() would now just
> enqueue another message with spi_async, and should therefore be safe.
> Lots of implementation details left, obviously, but do you think this
> would be a possible implementation (acceptable by upstream)?

It's an interesting find, I had no idea that it existed.  Yes it will be
more smiled upon than bitbanging it as you suggest, but... we don't have
proper chip select on those devices, and we have a pretty intense need
to service them, so I am uncertain what result this will give.

It's not very popular stance but in fact along with stable and reliable
we need efficient implementation, I don't think it makes sense to use
this if it is significantly worse on CPU / power.  But if you're
interested to try this and it isn't much worse than bitbanging
performance-wise or have some other drawback, it does sound like we
should use it in place of bitbanging.

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


More information about the openmoko-kernel mailing list