WLAN from SDIO to SPI: battle plan

[Werner Almesberger]

I wrote:
> To be continued ...

It's been a while since the last update and a number of things have
happened since.

Most importantly, Atheros informed us that putting the AR6001 to
sleep causes SPI to get confused and lock up. Apparently, there is
some sort of work-around for this, but the description sounded
eerily reminiscent of the boundless joy we know from the
suspend/resume signaling between CPU and GSM.

There are two ways to avoid this kind of trouble:

- switch to the AR6002, or
- use SD SPI mode

To give a bit of context, there are the following ways how one can
talk to this module:

- SDIO, using a 4 bit bus
- SDIO, using only 1 bit
- SD SPI mode, where SD(IO) commands are transported over SPI
- Native SPI mode (with a still unknown protocol/framing)

GTA02 currently uses SDIO with the 4 bit bus. Without the SDIO
interface, native SPI mode would be the leanest choice. But since
this would cause problems with the AR6001, I then switched to
exploring the SD SPI mode.

Before doing that, I realized that my original plan of replacing
the SD host controller driver (HCD) wasn't particularly good, since
this would have left me with no convenient interface on the
mainline Linux side and I would still have had the whole Atheros
SDIO stack underneath, potentially causing trouble with native SPI
mode.

So instead I replaced what Atheros call the host interface (HIF)
and use the mainline SDIO stack to talk to the chip. As an added
bonus, this gets rid of the entire Atheros SDIO stack.

With the Linux SDIO stack, there are three possible drivers:

- S3C SD(IO) driver
- MMC-SPI using the S3C SPI driver
- MMC-SPI using the S3C bit-banging GPIO SPI driver

In an attempt to mimick exactly what the Atheros stack was doing,
I first tried to use the S3C SD driver, which should basically
deliver the same results, thus making it easy to spot and fix any
differences. (Plus, it should allow a performance comparison
between the Atheros SDIO stack and the Linux mainline SDIO stack.)

To make a long story short, this wasn't a great idea. For some
reason, I don't get the SDIO interrupt. This somehow seems to be
caused by a difference in the S3C SD drivers (I've made all the
higher layers produce identical commands, so that's about the only
place left), but it's not just the interrupt not getting delivered,
but the module not generating it internally in the first place.

I also tried to compare the bits on the wire, but communication is
too bursty to let me just record the session, and I also hit
limitations of my equipment.

Then I tried MMC-SPI with the GPIO SPI driver. This is basically
the setup I had tried successfully earlier, but back then it was
not connected to the AR6K driver.

This one worked much better: the driver doesn't like the block size
Atheros use, but I finally got the interrupt. The AR6K stack doesn't
seem to know what exactly to do with it, but that's something that
shouldn't be too hard to track down.

Once MMC-SPI with GPIO bit-banging works, I can wire SPI0 from the
debug connector to the WLAN module, and try MMC-SPI with the SPI
driver, which will then finally allow a realistic performance
evaluation.

To be continued ...

- Werner