PATCH/RFC [0/3]: Fix suspend and other acceleromter issues

Andy Green andy at
Sun Nov 16 14:23:11 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

| 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.

I don't fancy doing this to get us pretty much where we think we are
already... and still no path into mainline... what might be worth effort
is bringing it under or extending the mainline SPI somehow so it can
operate inside interrupt context.  For example, the existing mainline
bitbang SPI stuff may work itself under interrupt itself, we could maybe
try hook that up to the existing bitbang guts for upstream.  Or if it
doesn't, try come at it by fixing that.

| 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 ?

With bitbang-all-the-way and level the sample-dropping problem is gone

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


More information about the openmoko-kernel mailing list