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
