[PATCH] kill mutex in lis

Andy Green andy at openmoko.com
Sat Oct 11 11:30:49 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Werner Almesberger wrote:

>> I don't think it's realistic to throw half the hardware off a cliff as a
>> solution.
> 
> Well, doesn't everybody pretty much agree that 

Uh oh whenever I see that formulation, I suspect I will be disagreeing
with whatever comes next...

the second a11r is
> useless ? So if we can make things simpler and more efficient by
> just not using it, why shouldn't we ? We're not using all the
> fancy coprocessors in the Glamo either, even though we could ;-)

Well thousands of folks paid for two, would probably be a bit grumpy if
we "downgrade" them.

> Before thinking about great optimizations, we should have a clear
> idea what best-case performance we can expect, and where the real
> bottlenecks are.

Seems to me that deferring service to a workqueue in an ISR just because
the API can't do it in the ISR might be a "bottleneck" (and add jitter
under load).

> If DIY bitbang beats a workqueue by a large margin, then that's a
> strong case in favour of the former. If not, we should just use
> the SPI subsystem the way it's meant to be.

Who exactly says that SPI subsystem is "meant to be" only used outside
interrupts?  Only the current Linux implementation.  Obviously it's nice
and safe position to say to just always use what Linux provides and not
daring to think about anything else (to the point of handicapping the
device by throwing out one accel), a political answer to a technical
question.

Simon is looking at another route in the API, please send patches with
numbers like he is rather than more emails on this subject.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjwckgACgkQOjLpvpq7dMqDjwCdELcdWNdZpwGmqTHXQrOKk2eK
yUcAnRZ9q3KIWDFl37Yv0QveXBgffilt
=xjXS
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list