[PATCH] kill mutex in lis
werner at openmoko.org
Fri Oct 10 22:42:34 CEST 2008
Andy Green wrote:
> The only problem with bitbang outside the API is that
> it's unlikely to chime with the upstream way.
How does the performance of "bitbang all the way" compare to using
a workqueue ? Also, do you know what maximum SCLK the a11r (*)
supports ? I haven't been able to find this information in the data
(*) "a11r" = "accellerometer", like "i18n" = "internationalization"
> I don't think it's realistic to throw half the hardware off a cliff as a
Well, doesn't everybody pretty much agree that 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 ;-)
Before thinking about great optimizations, we should have a clear
idea what best-case performance we can expect, and where the real
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.
More information about the openmoko-kernel