We are using a Marvell based WLAN/Bluetooth combo module with OMAPL138 (not the EVM, but a custom design). In some scenarios we observed that FN1 (WLAN) driver gets write failure error from MMC controller (error seen on console is pasted at the end of this message). What we have observed is that the F1 driver occasionally fails to write, but recovers (the retry limit is set to 3). However, irrecoverable failure will eventually happen. We have tried increasing the retry limit (not a practical solution though) and found that the failure is inevitable.
We debugged further using SDIO analyzer and observed that actual data is not seen by the analyzer (as shown in the below capture, Figure 2), when the write failure happens.
Figure 1: CMD53-Write operation with DATA
Figure 2: CMD53-Write Operation with NO DATA
The WLAN SDIO card that we are using supports various voltages. We are using 1.8V.
For the same test instead of using SDIO analyzer, we probed SD lines. It can be noted that when the write fails, the D1 line logic low shows a problem as in the below picture (the lines do not go low completely). The D1 line would have returned to normal after sometime, but the write failure doesn't recover. Interesting thing to note is that the read from the SDIO slave works fine even after the irrecovrable failure with write happens (and after D1 lines return to normal behavior).
We observed the issue initially without the probes. The kernel driver debug messages show the same failures with or without the probes connected. Also, we believe SDIO analyzer has enough buffers to maintain the signal integrity between host controller and card. So we guess the chances of interference due to the probes are remote.
We are trying to identify the problem area positively. At this point, all the data we have suggests that the problem is with the host (OMAPL138 controller or the design). We appreciate any help to debug this issue further. Let us know if any more data is needed. We will run any tests required to get the data.
Thanks,
Suresh
Log seen on serial console
(We are using Linux on the host platform)
[ 3] 49.0-50.0 sec 129 KBytes 1.06 Mbits/sec [ 3] 50.0-51.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 51.0-52.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 52.0-53.0 sec 128 KBytes 1.05 Mbits/sec host_to_card, write iomem (1) failed: -1 host_to_card, write iomem (2) failed: -1 [ 3] 53.0-54.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 54.0-55.0 sec 129 KBytes 1.06 Mbits/sec ------------[ cut here ]------------ WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x2bc/0x2dc() NETDEV WATCHDOG: mlan0 (wlan_sdio): transmit queue 0 timed out Modules linked in: sd8xxx(O) mlan(PO) syslink(O) [<c000d948>] (unwind_backtrace+0x0/0xf0) from [<c0017e34>] (warn_slowpath_common+0x4c/0x64) [<c0017e34>] (warn_slowpath_common+0x4c/0x64) from [<c0017ee0>] (warn_slowpath_fmt+0x30/0x40) [<c0017ee0>] (warn_slowpath_fmt+0x30/0x40) from [<c0264c68>] (dev_watchdog+0x2bc/0x2dc) [<c0264c68>] (dev_watchdog+0x2bc/0x2dc) from [<c0022d0c>] (run_timer_softirq+0x12c/0x2b8) [<c0022d0c>] (run_timer_softirq+0x12c/0x2b8) from [<c001d778>] (__do_softirq+0xa0/0x13c) [<c001d778>] (__do_softirq+0xa0/0x13c) from [<c001dc38>] (irq_exit+0x88/0x94) [<c001dc38>] (irq_exit+0x88/0x94) from [<c0009cb0>] (handle_IRQ+0x34/0x84) [<c0009cb0>] (handle_IRQ+0x34/0x84) from [<c0009058>] (__irq_svc+0x38/0x8c) [<c0009058>] (__irq_svc+0x38/0x8c) from [<c00153bc>] (davinci_enter_idle+0x78/0xb4) [<c00153bc>] (davinci_enter_idle+0x78/0xb4) from [<c0208f88>] (cpuidle_idle_call+0x9c/0x12c) [<c0208f88>] (cpuidle_idle_call+0x9c/0x12c) from [<c0009fd0>] (cpu_idle+0xa8/0x100) [<c0009fd0>] (cpu_idle+0xa8/0x100) from [<c03d06f4>] (start_kernel+0x274/0x2bc) ---[ end trace 366d06aa9ac4300c ]--- 4294962112 : Tx timeout (1), bss_index=0 4294963101 : Tx timeout (2), bss_index=0 4294964101 : Tx timeout (3), bss_index=0 4294965101 : Tx timeout (4), bss_index=0 4294966101 : Tx timeout (5), bss_index=0
