By the way, another way to get better performance may be to do the following:
- 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 ? - Werner
