beagleboard and TI WiFi SDIO

[claud]

Hello ,

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.

Thanks for your advise.

Claud Yu


--------------------------
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - IPC_EVENT_SCAN_COMPLETE
CTRL-EVENT-SCAN-RESULTS Ready
Trying to associate with 00:0f:66:2d:b7:2d (SSID='linksys' freq=2437
MHz)
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
wpa_supplicant - Link Speed = 54 MB/s
[ 1003.954010] BUG: soft lockup - CPU#0 stuck for 61s! [tiwlan_wifi_wq:
1381]
[ 1003.960845] Modules linked in: wlan
[ 1003.964385]
[ 1003.965881] Pid: 1381, comm: tiwlan_wifi_wq
[ 1003.970611] CPU: 0 Not tainted (2.6.29-omap1 #6)
[ 1003.975616] PC is at dma_cache_maint+0x3c/0xd8
[ 1003.980102] LR is at dma_map_sg+0x68/0xd4
[ 1003.984130] pc : [<c013628c>] lr : [<c0136468>] psr: 20000013
[ 1003.984130] sp : c7bedbd0 ip : c7bedbf0 fp : c7bedbec
[ 1003.995666] r10: 00000001 r9 : c7bedcf8 r8 : 00000014
[ 1004.000946] r7 : 00000001 r6 : 00000030 r5 : c070cdc0 r4 :
c8bee014
[ 1004.007507] r3 : c05df378 r2 : 00000001 r1 : c8000000 r0 :
c8bee014
[ 1004.014068] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 1004.021423] Control: 10c5387d Table: 873b0019 DAC: 00000017
[ 1004.027191] [<c0132d7c>] (show_regs+0x0/0x50) from [<c017d690>]
(softlockup_tick+0x124/0x174)
[ 1004.035827] r4:0000036a
[ 1004.038391] [<c017d56c>] (softlockup_tick+0x0/0x174) from
[<c015ce48>] (run_local_timers+0x1c/0x20)
[ 1004.047515] r8:000003e1 r7:000003e1 r6:3aaeb2e3 r5:c7bf7280
r4:00000000
[ 1004.054290] [<c015ce2c>] (run_local_timers+0x0/0x20) from
[<c015ce78>] (update_process_times+0x2c/0x5c)
[ 1004.063781] [<c015ce4c>] (update_process_times+0x0/0x5c) from
[<c0172450>] (tick_sched_timer+0x90/0xcc)
[ 1004.073272] r5:c7bedb88 r4:c05ad4f0
[ 1004.076873] [<c01723c0>] (tick_sched_timer+0x0/0xcc) from
[<c016a4d4>] (__run_hrtimer+0x74/0x130)
[ 1004.085845] r7:c057bd28 r6:c057bd28 r5:00000000 r4:c05ad4f0
[ 1004.091552] [<c016a460>] (__run_hrtimer+0x0/0x130) from
[<c016b150>] (hrtimer_interrupt+0x17c/0x1ec)
[ 1004.100769] r6:3aae3bae r5:7fffffff r4:ffffffff
[ 1004.105438] [<c016afd4>] (hrtimer_interrupt+0x0/0x1ec) from
[<c013ba6c>] (omap2_gp_timer_interrupt+0x28/0x34)
[ 1004.115447] [<c013ba44>] (omap2_gp_timer_interrupt+0x0/0x34) from
[<c017dc70>] (handle_IRQ_event+0x3c/0x74)
[ 1004.125274] [<c017dc34>] (handle_IRQ_event+0x0/0x74) from
[<c017f084>] (handle_level_irq+0x94/0xec)
[ 1004.134429] r7:00000001 r6:00000030 r5:0000005f r4:c057dad0
[ 1004.140136] [<c017eff0>] (handle_level_irq+0x0/0xec) from
[<c0131058>] (__exception_text_start+0x58/0x70)
[ 1004.149810] r5:00000000 r4:0000005f
[ 1004.153411] [<c0131000>] (__exception_text_start+0x0/0x70) from
[<c0131a30>] (__irq_svc+0x30/0x80)
[ 1004.162445] Exception stack(0xc7bedb88 to 0xc7bedbd0)
[ 1004.167541] db80: c8bee014 c8000000 00000001
c05df378 c8bee014 c070cdc0
[ 1004.175903] dba0: 00000030 00000001 00000014 c7bedcf8 00000001
c7bedbec c7bedbf0 c7bedbd0
[ 1004.184295] dbc0: c0136468 c013628c 20000013
ffffffff
[ 1004.192657] r5:d8200000 r4:ffffffff
[ 1004.196289] [<c0136250>] (dma_cache_maint+0x0/0xd8) from
[<c0136468>] (dma_map_sg+0x68/0xd4)
[ 1004.204803] r6:00000000 r5:c070cdc0 r4:c7bedcf8
[ 1004.209472] [<c0136400>] (dma_map_sg+0x0/0xd4) from [<c0383808>]
(omap_mmc_request+0x220/0x2ac)
[ 1004.218261] [<c03835e8>] (omap_mmc_request+0x0/0x2ac) from
[<c037c4e4>] (mmc_wait_for_req+0x114/0x12c)
[ 1004.227661] r8:c7199c00 r7:00000001 r6:00000030 r5:c79d8c00
r4:c7bedce4
[ 1004.234436] [<c037c3d0>] (mmc_wait_for_req+0x0/0x12c) from
[<c037fa5c>] (mmc_io_rw_extended+0x174/0x1d4)
[ 1004.244018] r5:c7bedc8c r4:c7bedce4
[ 1004.247619] [<c037f8e8>] (mmc_io_rw_extended+0x0/0x1d4) from
[<c0380ca4>] (sdio_io_rw_ext_helper+0x15c/0x190)
[ 1004.257629] [<c0380b48>] (sdio_io_rw_ext_helper+0x0/0x190) from
[<c0380d58>] (sdio_memcpy_toio+0x28/0x30)
[ 1004.267272] [<c0380d30>] (sdio_memcpy_toio+0x0/0x30) from
[<bf08fd8c>] (SDIO_SyncWrite+0xec/0x150 [wlan])
[ 1004.277832] [<bf08fca0>] (SDIO_SyncWrite+0x0/0x150 [wlan]) from
[<bf0637d8>] (whal_hwAccess_WriteMem+0x104/0x1dc [wlan])
[ 1004.289916] r6:00000030 r5:0003a788 r4:c7a39e54
[ 1004.294586] [<bf0636d4>] (whal_hwAccess_WriteMem+0x0/0x1dc [wlan])
from [<bf06391c>] (whal_hwAccess_WriteMemAsync+0x10/0x20 [wlan])
[ 1004.307495] r7:00000030 r6:c8bee014 r5:0003a788 r4:c7a39d94
[ 1004.313201] [<bf06390c>] (whal_hwAccess_WriteMemAsync+0x0/0x20
[wlan]) from [<bf062698>] (TNETWIF_WriteMemOpt+0x44/0x48 [wlan])
[ 1004.325775] [<bf062654>] (TNETWIF_WriteMemOpt+0x0/0x48 [wlan]) from
[<bf05f834>] (xferStateMachine+0x16c/0x70c [wlan])
[ 1004.337493] r7:00000030 r6:c7a07934 r5:00000040 r4:c7b19040
[ 1004.343231] [<bf05f6c8>] (xferStateMachine+0x0/0x70c [wlan]) from
[<bf064804>] (TNETWArb_CallClientCallback+0x80/0x1e8 [wlan])
[ 1004.355682] [<bf064784>] (TNETWArb_CallClientCallback+0x0/0x1e8
[wlan]) from [<bf065210>] (TNETWArbSM_RunClientCb+0xc4/0xe0 [wlan])
[ 1004.368560] r6:c7037174 r5:c703719c r4:c7bf8d74
[ 1004.373229] [<bf06514c>] (TNETWArbSM_RunClientCb+0x0/0xe0 [wlan])
from [<bf07bc9c>] (nrfsm_Event+0x94/0xb8 [wlan])
[ 1004.384704] r6:00000005 r5:00000000 r4:c7a39df4
[ 1004.389373] [<bf07bc08>] (nrfsm_Event+0x0/0xb8 [wlan]) from
[<bf064f48>] (TNETWArbSM_SMEvent+0x24/0x34 [wlan])
[ 1004.400482] r5:c7037174 r4:c7bf8d74
[ 1004.404083] [<bf064f24>] (TNETWArbSM_SMEvent+0x0/0x34 [wlan]) from
[<bf064d78>] (TNETWArb_Start+0x198/0x1b4 [wlan])
[ 1004.415588] r4:c70371ec
[ 1004.418121] [<bf064be0>] (TNETWArb_Start+0x0/0x1b4 [wlan]) from
[<bf0627e8>] (TNETWIF_Start+0x14/0x18 [wlan])
[ 1004.429107] r8:00000000 r7:00000000 r6:bf08e40c r5:00000000
r4:c7bfdb34
[ 1004.435882] [<bf0627d4>] (TNETWIF_Start+0x0/0x18 [wlan]) from
[<bf060854>] (FwEvent+0x50/0xcc [wlan])
[ 1004.446136] [<bf060804>] (FwEvent+0x0/0xcc [wlan]) from
[<bf066e20>] (whalCtrl_HandleInterrupts+0x14/0x18 [wlan])
[ 1004.457458] r5:c7bec000 r4:c7996380
[ 1004.461059] [<bf066e0c>] (whalCtrl_HandleInterrupts+0x0/0x18
[wlan]) from [<bf017344>] (configMgr_handleInterrupts+0x14/0x18
[wlan])
[ 1004.473907] [<bf017330>] (configMgr_handleInterrupts+0x0/0x18
[wlan]) from [<bf08e438>] (tiwlan_irq_handler+0x2c/0x38 [wlan])
[ 1004.486145] [<bf08e40c>] (tiwlan_irq_handler+0x0/0x38 [wlan]) from
[<c01636b8>] (run_workqueue+0xa4/0x11c)
[ 1004.496459] r4:c73ff9c0
[ 1004.498992] [<c0163614>] (run_workqueue+0x0/0x11c) from
[<c0163dac>] (worker_thread+0x100/0x114)
[ 1004.507873] r7:c73ff9c8 r6:c73ff9c0 r5:c7bec000 r4:c7bedfa4
[ 1004.513610] [<c0163cac>] (worker_thread+0x0/0x114) from
[<c0167404>] (kthread+0x5c/0x94)
[ 1004.521789] r7:00000000 r6:c0163cac r5:c73ff9c0 r4:c7bec000
[ 1004.527496] [<c01673a8>] (kthread+0x0/0x94) from [<c0156cf0>]
(do_exit+0x0/0x69c)
[ 1004.535064] r6:00000000 r5:00000000 r4:00000000

[claud]

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.

Claud Yu

[Kalpesh Rathod]

Hi Claud Yu,

I faced similar problem but not with TI WL1251.

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.

Hope this helps.

Regards,
Kalpesh

[claud]

Hi Kaloesh ,

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.

Thanks for your advise.

Claud Yu

On Aug 3, 9:40 pm, Kalpesh Rathod <kalpeshrat...@gmail.com> wrote:
> Hi Claud Yu,
>
> I faced similar problem but not with TI WL1251.
>
> 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.
>
> Hope this helps.
>
> Regards,
> Kalpesh
>

[Mike]

Hi Kalpesh,

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?

Thanks,
Mike S.

On Aug 3, 8:40 am, Kalpesh Rathod <kalpeshrat...@gmail.com> wrote:
> Hi Claud Yu,
>
> I faced similar problem but not with TI WL1251.
>
> 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 othersdiofunctions 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.
>
> Hope this helps.
>
> Regards,
> Kalpesh
>

> On Mon, Aug 3, 2009 at 4:07 PM, claud<claud...@gmail.com> wrote:
>
> > 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.
>
> > Claud Yu
>
> > On 7月31日, 下午5時33分, claud <claud...@gmail.com> wrote:
> >> Hello ,
>
> >>  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

> >>sdioroutine 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 changeSDIOio
> >> 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 toSDIOdevice ?

[claud]

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.

Claud Yu

[claud]

Hi Kaloesh ,

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.

Claud Yu

On 8月4日, 上午6時56分, claud <claud...@gmail.com> wrote:
> Hi Kaloesh ,
>
> 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 doSDIOIO.
> One is normal (dio_memcpy_toio/sdio_memcpy_fromio directory), and the
> other is using the workaround you say.
>
> Thanks for your advise.
>
> Claud Yu
>
> On Aug 3, 9:40 pm, Kalpesh Rathod <kalpeshrat...@gmail.com> wrote:
>
>
>
> > Hi Claud Yu,
>
> > I faced similar problem but not with TI WL1251.
>
> > 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 othersdiofunctions will use buffer supplied

> > >>sdioroutine 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 changeSDIOio
> > >> 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 toSDIOdevice ?

[Kalpesh Rathod]

Hi Claud Yu,

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.

Hope this helps.

Regards,
Kalpesh

>
> Claud Yu

[Kalpesh Rathod]

Hi Mike,

I did not attempt it for Marvell 8688.
Workaround did fix DMA buffer problem by making the xfer work.
I have not measured performance yet.

Regards,
Kalpesh

[Mike]

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.

Mike.

On Aug 9, 8:59 am, Kalpesh Rathod <kalpeshrat...@gmail.com> wrote:
> Hi Mike,
>
> I did not attempt it for Marvell 8688.
> Workaround did fix DMA buffer problem by making the xfer work.
> I have not measured performance yet.
>
> Regards,
> Kalpesh
>

[Kalpesh Rathod]

Mike,

> I haven't looked yet but I'll bet this implementation uses pre-
> allocated kmalloced buffers as you suggested.
>

Using kmalloced DMA:able buffer before calling
sdio_memcpy_fromio/sdio_memcpy_toio
is a workaround.

drivers/mmc/host/omap.c switches to PIO when DMA is not possible due
to constraints.

drivers/mmc/host/omap_hsmmc.c always attempts DMA. I tried
host->use_dma = 0, but it didn't work.

compare definition of function mmc_omap_prepare_data in both the drivers.
I believe you successfully ported these changes and things work.

Regards,
Kalpesh

[claud]

Hi !

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.

Claud Yu

On 8月3日, 下午6時37分, claud <claud...@gmail.com> wrote:
> 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.
>
> Claud Yu
>
> On 7月31日, 下午5時33分, claud <claud...@gmail.com> wrote:
>
> > Hello ,
>
> >  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

> >sdioroutine 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 changeSDIOio
> > 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 toSDIOdevice ?

[Steve Sakoman]

On Wed, Aug 12, 2009 at 12:18 AM, claud<clau...@gmail.com> wrote:

> 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.

Patches??

Steve

[claud]

Hi ,

I verify another GPL wl1251 driver wl12xx and change interrupt
handling as spi interface .

Please check the result at my blog.

http://greekclaud.blogspot.com/2009/08/wl1251-sdio-performance-and-setting.html

And I verify the origin code at
http://greekclaud.blogspot.com/2009/08/wl12xx-sdio-driver-performance-and.html

The following is Wilink 4.x performance
http://greekclaud.blogspot.com/2009/08/wilink-4x-sdio-driver-performance-and.html

Claud Yu

[Thanh Tran]

Hi Claud 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 insmod wl1251..ko insmod wl1251_sdio.ko Thanks very much -Thanh --- On Wed, 8/19/09, claud <clau...@gmail.com> wrote:

[claud]

You can download from linux wireless project (http://
linuxwireless.org/) .

On 8月19日, 下午5時31分, Thanh Tran <thanhtra...@yahoo.com> wrote:
> Hi Claud
>
> 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
>

> insmod wl1251.ko

> insmod wl1251_sdio.ko
>
> Thanks very much
>
> -Thanh
>

> --- On Wed, 8/19/09, claud <claud...@gmail.com> wrote:

>
> From: claud <claud...@gmail.com>
> Subject: [beagleboard] Re: beagleboard and TI WiFi SDIO
> To: "Beagle Board" <beagl...@googlegroups.com>
> Date: Wednesday, August 19, 2009, 2:23 AM
>
> Hi ,
>
>     I verify another GPL wl1251 driver wl12xx and change interrupt
> handling as spi interface .
>
> Please check the result at my blog.
>

> http://greekclaud.blogspot.com/2009/08/wl1251-sdio-performance-and-se...
>
> And I verify the origin code athttp://greekclaud.blogspot.com/2009/08/wl12xx-sdio-driver-performance...
>
> The following is Wilink 4.x performancehttp://greekclaud.blogspot.com/2009/08/wilink-4x-sdio-driver-performa...
>
> Claud Yu