WLAN from SDIO to SPI: sneak preview
werner at openmoko.org
Thu Sep 4 15:54:55 CEST 2008
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
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
> 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 :-)
More information about the openmoko-kernel