State of the OpenMoko wlan driver

[Werner Almesberger]

Andy Green wrote:
> | If you're not in a hurry, you can do that even today :-)

Perhaps I should clarify what I meant with "not in a hurry":

Right now, only MMC-SPI using the GPIO-bitbang driver works with the
Linux SDIO stack, but it's dreadfully slow (about 200-300 kbps), as
one would expect.

I'm now making this work with MMC-SPI using the S3C SPI driver, which
can do bursts of up to 25Mbps. Of course, the bursts alone don't always
help, e.g., see here:
http://people.openmoko.org/werner/wlan-spi/bursty-spi.png

That's:
- driver writes next byte to hardware
- about 0.3us later, the byte has been sent and an interrupt is
  generated
- time passes ...
- the interrupt handler sends the next byte
- etc., until ...
- finally, the interrupt handler sends the last byte and calls
  complete()
- paint dries, gets brittle, falls off the wall ...
- MMC stack wakes up from a long and restful sleep and decides what to
  do next

So the effective speed before modification is still only about 2Mbps.

> Even if it
> works pretty much the same it's preferable just to chop out the amount
> of code we drag around in mokopatches.

Definitely yes. That SDIO driver is probably the most offensive large
part of the whole Atheros stack, since it duplicates an entire
subsystem. (In a way, it's a shame that it has to go, since it's
actually quite efficient.)

That doesn't mean that the driver would be suitable for mainline
inclusion even after switching stacks, but the messy heap gets at
least significantly smaller.

> If it isn't that, what're you trying to do in there?  We don't actually
> have a use for SPI interface to it?

You never know :-) But even if we don't use this, MMC-SPI (not to be
confused with G_SPI) is basically the simplest way to talk to the card,
so it's easier to debug things bottom-up.

Besides, that's also an opportunity to fix the S3C SPI driver. The bug
I found would explain very well why SPI didn't work when you tried it
with the accelerometers.

- Werner