PATCH/RFC [0/3]: Fix suspend and other acceleromter issues
werner at openmoko.org
Sun Nov 16 14:14:15 CET 2008
By the way, another way to get better performance may be to do the
- set up the SPI hardware to do a transfer that reads all the
relevant registers in a single sweep
- configure the SPI controller to do DMA
- fire this off when we get an interrupt
- do avoid having to handle a completion interrupt, only process
the result on the next interrupt. If the next interrupt arrives
before DMA completes, ignore the interrupt.
The would create artefacts at the beginning and the end of a phase of
activity, but they can be filtered out, e.g., by setting up a timer
to push stale data if nothing else has happened within a dozen ms.
Since this arrangement differs quite a bit from the logic of the
regular SPI stack, this SPI-for-accelerometers driver would probably
have to exist in parallel to the S3C SPI driver.
Oh, and given my adventures with polled/interrupt-driven SPI a while
ago, I would recommend to have a scope/logic analyzer/MSO with at
least 4 channels ready before starting to try to implement DMA. The
signals are reasonably easy to access.
Ah, and another thought: how fast does bitbang-all-the-way actually
go ? The data sheet (October 2008, page 12) says that the maximum
SPI clock is 10MHz. I saw spi_s3c24xx_gpio do only a bit less than
1Mbps, but bitbang-all-the-way is a bit more streamlined, so it may
be faster - maybe fast enough to sometimes violate the timing ?
More information about the openmoko-kernel