Andy Green wrote: > It sounds like you made some real progress Werner, well done.
Thanks ! It's starting to look decent indeed. > Maybe it is more widely interesting to just plug the Atheros driver part > on to the mainline stack at SDIO? That's actually what I'm doing: in hif2.c, I translate the HIF read/write operations into calls to the regular Linux SDIO stack, which then uses any of the hardware drivers. I've also tried to use the mainline S3C SD/MMC driver (with the Linux SDIO stack), but for some yet to be discovered reason, this didn't work. I know that this driver has a number of issues, which are being gradually addressed just now, particularly with interrupt handling. So it might be that going to the latest upstream would make this work without further ado. But maybe not. I can also decode the on the wire data and compare what exactly the Atheros stack with Samuel's driver is doing and what the Linux SDIO stack is doing at the bit level. But I'll save that exercise for a bit later, because it may take some time to set up a suitable test environment. I already tried the "point the scope at it and see what it catches" approach, but had to realize that my equipment is sadly inadequate for this task. But if I make the respective stack generate a trigger on the Nth packet, with N varying from session to session, then I should be able to handle this. Just needs some more work on automating things. There are about 200 transactions before I can see clearly divergent behaviour (i.e., the interrupt isn't happening), so that's well beyond manual testing and decoding. At the SDIO command level, they're already basically identical (and if I change the driver underneath to MMC-SPI, things work), so the difference seems to be in how the SDIO commands and responses get turned into bits on the wire and vice versa. > All Freerunner users might be > interested in the result... it would have DMA up for free? Don't we use the DMA of Samuel's driver already ? It's enabled in all the defconfigs and as far as I can tell, the driver implements everything necessary. > I wonder how many of the bugs we can't currently solve in WLAN for > Freerunner are to do with the Atheros SDIO stack we currently use and > how many are really in the firmware... Yep, that would be interesting to compare. Particularly in the "nothing works" cases. There's still plenty of other places where things that can go wrong. Switching to mainline SDIO removes about 10'000 lines of Atheros' deeply layered code, but there are still another 20'000 left in the actual driver and its surroundings, possibly about half of them redundant and/or extra weight added by OS abstraction. Luckily, I didn't have to touch much of that yet :-) - Werner
