This sounds quite familiar. There was a patch applied to this driver which fixed an incorrect ref counting issue in the power down routines. which would obviously manifest it's when you try to power the device back up.
Don't know whether this is your particular bug but worth a look https://code-review.phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_ti_wlan.git;a=commitdiff;h=855a27f7d6c88dbfa948411c7f1254be886f6b13 I assume this patch is also in TI official project repos which are located here https://git.ti.com/wilink8-wlan ( I think ) Hope that helps trevd On Monday, 22 September 2014 09:54:20 UTC+1, Bruno De Paoli wrote: > > We have a custom iMX53-based platform running Android Gingerbread, Linux > kernel 2.6.35 with a TiWi-BLE Wlan/Bluetooth device using the SDIO > interface for WLAN. We are using a Freescale BSP. The TiWi-BLE is a > repackaged TI wl1271 device. I downloaded the wl1271 driver from the TI > site as suggested by TI. > > I am getting SDIO errors when the WLAN device is stopped and restarted. > The device has a WL_EN signal that is cleared by the driver when the device > is stopped and set when started. Toggling this signal resets the device. > > I investigated this issue and saw what looked like the same problem on the > TI forums > http://e2e.ti.com/support/wireless_connectivity/f/307/t/181835.aspx?pi310978=2 > > It looked like the device may not be turned on while SDIO traffic is > present and I implemented the suggested fix to address this issue but the > problem did not go away. It is getting an SDIO MMC timeout error. Here's > what I get at the console when the device is restarted after having been > stopped. > > > ------------[ cut here ]------------ > WARNING: at /home/wlan/compat-wireless/drivers/net/wireless/wl12xx/sdio.c:126 > wl12xx_sdio_raw_write+0xac/0xe8 [wl12xx_sdio]() > Modules linked in: wl12xx_sdio wl12xx mac80211 cfg80211 compat > [<8003e578>] (unwind_backtrace+0x0/0xf0) from [<80068e6c>] > (warn_slowpath_common+0x4c/0x64) > [<80068e6c>] (warn_slowpath_common+0x4c/0x64) from [<80068e9c>] > (warn_slowpath_null+0x18/0x1c) > [<80068e9c>] (warn_slowpath_null+0x18/0x1c) from [<7f0e0264>] > (wl12xx_sdio_raw_write+0xac/0xe8 [wl12xx_sdio]) > [<7f0e0264>] (wl12xx_sdio_raw_write+0xac/0xe8 [wl12xx_sdio]) from > [<7f0aecac>] (wl1271_set_partition+0xe0/0x3d0 [wl12xx]) > [<7f0aecac>] (wl1271_set_partition+0xe0/0x3d0 [wl12xx]) from [<7f0a678c>] > (wl12xx_set_power_on+0x70/0x138 [wl12xx]) > [<7f0a678c>] (wl12xx_set_power_on+0x70/0x138 [wl12xx]) from [<7f0a999c>] > (wl12xx_chip_wakeup+0x10/0x2b8 [wl12xx]) > [<7f0a999c>] (wl12xx_chip_wakeup+0x10/0x2b8 [wl12xx]) from [<7f0a9f5c>] > (wl1271_op_add_interface+0x318/0x574 [wl12xx]) > [<7f0a9f5c>] (wl1271_op_add_interface+0x318/0x574 [wl12xx]) from [<7f0581c8>] > (ieee80211_do_open+0x2e0/0x6c0 [mac80211]) > [<7f0581c8>] (ieee80211_do_open+0x2e0/0x6c0 [mac80211]) from [<80371bb8>] > (__dev_open+0xa0/0xf0) > [<80371bb8>] (__dev_open+0xa0/0xf0) from [<8036f4f8>] > (__dev_change_flags+0x8c/0x110) > [<8036f4f8>] (__dev_change_flags+0x8c/0x110) from [<80371ae4>] > (dev_change_flags+0x10/0x44) > [<80371ae4>] (dev_change_flags+0x10/0x44) from [<803c793c>] > (devinet_ioctl+0x3ac/0x77c) > [<803c793c>] (devinet_ioctl+0x3ac/0x77c) from [<80361058>] > (sock_ioctl+0x1f4/0x244) > [<80361058>] (sock_ioctl+0x1f4/0x244) from [<800da3e4>] (vfs_ioctl+0x2c/0xac) > [<800da3e4>] (vfs_ioctl+0x2c/0xac) from [<800daa98>] > (do_vfs_ioctl+0x540/0x5a0) > [<800daa98>] (do_vfs_ioctl+0x540/0x5a0) from [<800dab44>] > (sys_ioctl+0x4c/0x6c) > [<800dab44>] (sys_ioctl+0x4c/0x6c) from [<80039f80>] > (ret_fast_syscall+0x0/0x30) > ---[ end trace 28f46a0aaed28e6a ]--- > wl1271_sdio mmc1:0001:2: sdio write failed (-110) > > > We believe we are adhering to the WL_EN up/down device requirements as > stated in the datsheet. > > It seems to be some kind of SDIO/MMC issue where the interface has not > come up properly second time around, possibly due to some re-initialisation > issue. > > Can anyone suggest what might be happening or possible ways to debug this > in more depth to get to the bottom of it. > > Thanks, Bruno > > > -- -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting --- You received this message because you are subscribed to the Google Groups "android-porting" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
