I have one WiFi module based on TI WL1251. The chip also used on
Google G1. And I can get the source code from Android project. I
already porting the driver success and load the driver working with
Beagleboard MMC/SD.
I study the source code a couple days. The driver use default linux
sdio routine sdio_memcpy_fromio, sdio_memcpy_toio to access WiFi
module. The routine use CMD53 to access HW. But I always get halt near
first WiFi scan operation and get a lot of debug message about CPU
soft lockup like following log. The error message show the routine
halt at dma_cache_maint call from dma_map_sg. I try to change SDIO io
access routine to Single byte access with CMD52
(sdio_writeb,sdio_readb) , and the driver working and can associate to
AP and ping. But the throughput is very pool.
Have anyone have experience use beagleboard connect to SDIO device ?
My beagleboard version is B5 and kernel is 2.6.29-omap1 from linux-
omap git.
That is status update. I change the driver to another platform
(Freescale iMX31) and get driver work perfect.
Only change platform specific code.
The driver could connect and get reasonable bandwidth like HTC G1
phone (iperf tcp 8~9 Mbps).
Maybe the OMAP DMA code have problem with MMC DMA.
I came to following conclusion:
omap_hsmmc driver uses DMA for all read/write operations.
So, buffer has to be in DMA:able space.
sdio_readb/sdio_writeb succeeds because they use extra DMA:able buffer
allocated inside
sdio_func. whereas, all other sdio functions will use buffer supplied
by the driver.
I did ugly workaround by writing wrapper over
sdio_memcpy_toio/sdio_memcpy_fromio which
uses pre-allocated kmalloced buffer for the transfer.
I believe, ideal solution would be to enhance omap_hsmmc driver for
not to use dma for very short transfers.
I am talking about 2.6.28-omap. Don't know about recent kernels.
I also try the same workaround while I saw the problem. I use a pre-
allocated kmalloced buffer as you say.
But the problem still exist. And original TI WLAN driver also have
different way to do SDIO IO.
One is normal (dio_memcpy_toio/sdio_memcpy_fromio directory), and the
other is using the workaround you say.
I'm just starting to work on this problem also. We are attempting to
port a Marvell 8688 driver to work on the OMAP3 but are also seeing
the low transfer rate problem.
Did your "workaround" fix the DMA buffer problem and increase your
data transfer rates?
hi ! Mike ,
The low transfer rate problem is normal. The omap_hsmmc don't claim
the driver have capacity to handle SDIO interrupt and SDIO stack use
cpu to polling.
I porting the code to another platform (Freescale iMX31) with kernel
2.6.27.
The problem is gone. The driver work perfect. I get the same
performance as HTC G1 .
I don't know what's problem with OMAP3530/2.6.29 combination. Maybe I
could try another version OMAP3530 kernel.
In my case , on OMAP3530 the SDIO xfer fails in 2 cases.
1. source buffer is not in DMA:able space.
2. source buffer address is not 4 buf aligned.
I wrote to linux-omap list to confirm this but it got lost in heavy traffic.
Changing to whole new platform you have all new MMC/SD host controller
h/w and driver.
I think these two limitations may not hold for your Freescale platform
and hence your marvell card works fine.
Hope this helps.
Regards,
Kalpesh
Hi Claud Yu,
I porting the code to another platform (Freescale iMX31) with kernel
2.6.27.
The problem is gone. The driver work perfect. I get the same
performance as HTC G1 .
I don't know what's problem with OMAP3530/2.6.29 combination. Maybe I
could try another version OMAP3530 kernel.
on OMAP3530 the SDIO xfer fails in 2 cases.
1. source buffer is not in DMA:able space.
2. source buffer address is not 4 byte aligned.
Changing to whole new platform you have all new MMC/SD host controller
h/w and driver.
I think these two limitations may not hold for your Freescale platform
and hence your marvell card works fine.
Ok, thanks. But if your transfers are working I'll bet your
performance is where it should be.
BTW, I replaced both the omap_hsmmc and SDIO driver with drivers I
ported from an omap 2430 implementation and solved all performance
problems (4-bit mode with interrupts now working). This is on the
2.6.29-rc3 kernel with B7 beagleboard.
I haven't looked yet but I'll bet this implementation uses pre-
allocated kmalloced buffers as you suggested.
Finially I get a workable WL1251 driver with beagleboard. The tcp
performance ~10 Mbps with iperf.
The DMA workaround is work like Kalpesh's hint. But the size of DMA
need to adjust.
Thanks for sharing your work. I sent you an email but it probably got lost. Is there any info on where I can find the source code which you used to compile