linux & android平台WIFI休眠唤醒问题

这两周很痛苦，因为自己负责的WIFI模块休眠唤醒有问题，导致每天晚上都睡不好觉，第二天没有精神上班。

不过所幸的是，这两天找到了方法解决了，现在想把经验和大家分享下。

把调试环境和硬件说一下：

硬件平台：三星S5PV210

kernel: 2.6.35

android:2.3.4

WIFI驱动使用SDIO接口，有独立的上电及复位接口。

先上问题：

在WIFI打开的情况下，在WIFI的设置界面，按“MENU”键，选择高级->Wi-Fi休眠策略->充电时永不休眠/永不休眠，然后按POWER键使机器进入深度休眠，唤醒后WIFI不正常，软件跑飞。

跑飞的LOG：

[ 96.430142] DAPM sequencing finished, waiting 2ms
[ 96.432989] DAPM sequencing finished, waiting 2ms
[ 96.437106] smdkc110-rtc smdkc110-rtc: rtc disabled, re-enabling
[ 96.437127] smdkc110-rtc smdkc110-rtc: rtc disabled, re-enabling
[ 96.437143] smdkc110-rtc smdkc110-rtc: rtc disabled, re-enabling
[ 96.437185] pm_op(): platform_pm_suspend+0x0/0x64 returns -16
[ 96.437197] PM: Device alarm failed to suspend: error -16
[ 96.437206] PM: Some devices failed to suspend
[ 96.437541] PM: resume of devices complete after 0.321 msecs
[ 96.486343] Restarting tasks ...
[ 96.493614] done.
[ 96.499432] suspend: exit suspend, ret = -16 (2012-06-12 08:24:09.352134502 UTC)
[ 96.508291] DAPM sequencing finished, waiting 2ms
[ 96.515022] DAPM sequencing finished, waiting 2ms
[ 96.518930] dai_active 0, IISMOD 00000100, IISCON 8050c491
[ 96.526857] Inside s5p_i2s_resume..@550
[ 97.430432] dhdsdio_disconnect: Enter
[ 97.432612] dhdsdio_release: Enter
[ 97.436029] kernel BUG at drivers/mmc/core/sdio_io.c:29!
[ 97.441340] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 97.449358] pgd = c0004000
[ 97.452023] [00000000] *pgd=00000000
[ 97.455578] Internal error: Oops: 817 [#1] PREEMPT
[ 97.460342] last sysfs file: /sys/devices/platform/sec-fake-battery/power_supply/battery/technology
[ 97.469354] Modules linked in: dhd
[ 97.472737] CPU: 0 Not tainted (2.6.35.7 #72)
[ 97.477422] PC is at __bug+0x20/0x2c
[ 97.480971] LR is at schedule+0x274/0x2e8
[ 97.484955] pc : [<c0033dcc>] lr : [<c0448298>] psr: 60000013
[ 97.484961] sp : df89ddc8 ip : df89dcd0 fp : df89ddd4
[ 97.496391] r10: dfa991c4 r9 : dfa991c0 r8 : df87b050
[ 97.501591] r7 : df87b058 r6 : bf02a670 r5 : bf02a668 r4 : db9ced80
[ 97.508090] r3 : 00000000 r2 : 00000000 r1 : 00000002 r0 : 00000042
[ 97.514591] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 97.521870] Control: 10c5387d Table: 4f078019 DAC: 00000017
[ 97.527587]
[ 97.527590] PC: 0xc0033d4c:
[ 97.531832] 3d4c e89da800 c0567cee e1a0c00d e92dd800 e24cb004 e1a0c001 e1a03002 e1a01000
[ 97.539978] 3d6c e1a0200c e59f0004 eb104f83 e89da800 c0567d05 e1a0c00d e92dd800 e24cb004
[ 97.548123] 3d8c e1a0c001 e1a03002 e1a01000 e1a0200c e59f0004 eb104f78 e89da800 c0567d1c
[ 97.556269] 3dac e1a0c00d e92dd800 e24cb004 e1a02001 e1a01000 e59f000c eb104f6f e3a03000
[ 97.564415] 3dcc e5833000 eafffffe c0567d33 e1a0c00d e92dd800 e24cb004 e59f0004 e30012e1
[ 97.572561] 3dec ebffffee c0567d4c e1a0c00d e92dd800 e24cb004 e1a01000 e59f000c eb104f5e
[ 97.580706] 3e0c e59f0008 e30012c5 ebffffe4 c0567d64 c0567d4c e1a0c00d e92dd800 e24cb004
[ 97.588852] 3e2c e59f000c eb104f54 e59f0008 eb104f52 e89da800 c0567d84 c0567dbb e1a0c00d
[ 97.596999]
[ 97.597001] LR: 0xc0448218:
[ 97.601244] 8218 0a000001 e1570006 0a000012 e59f20d8 e5963170 e5922000 e0223003 e1b03423
[ 97.609390] 8238 0a000001 e1a00006 ebefc4a9 e59f30bc e5962184 e5933184 e1520003 0a000001
[ 97.617536] 8258 e1a00006 ebefbcd3 e5960024 e1a01006 e2800207 ebefc519 e59530dc e1a00005
[ 97.625681] 8278 e3530000 058530e0 059f3074 05837440 e5982004 e5951004 ebef9f37 ebf0204f
[ 97.633827] 8298 ea000001 e1a0000c eb000990 e594300c e5933014 e3530000 ba000005 eb000a46
[ 97.641973] 82b8 e3500000 b59f3038 b5935434 b285af62 baffff68 e5942000 e5943004 e3120002
[ 97.650118] 82d8 e2433001 e5843004 0a000003 eaffff55 e3a03000 e5853000 eaffff85 e24bd024
[ 97.658264] 82f8 e89dadf0 c05ff6f0 c044c5b8 c05f2900 c060e724 e1a0c00d e92dd878 e24cb004
[ 97.666410]
[ 97.666413] SP: 0xdf89dd48:
[ 97.670656] dd48 00205d39 00000000 df89dde4 df89dd60 c00578fc c04484d4 ffffffff df89ddb4
[ 97.678802] dd68 bf02a670 df87b058 df89ddd4 df89dd80 c002fa6c c002f2c4 00000042 00000002
[ 97.686947] dd88 00000000 00000000 db9ced80 bf02a668 bf02a670 df87b058 df87b050 dfa991c0
[ 97.695093] dda8 dfa991c4 df89ddd4 df89dcd0 df89ddc8 c0448298 c0033dcc 60000013 ffffffff
[ 97.703239] ddc8 df89dde4 df89ddd8 c02dc960 c0033db8 df89ddfc df89dde8 bf01e6c8 c02dc938
[ 97.711384] dde8 ce7e2800 db9cd940 df89de0c df89de00 bf020194 bf01e6ac df89de24 df89de10
[ 97.719530] de08 bf016718 bf02018c ce7e2800 db9cd880 df89de3c df89de28 bf01687c bf0166d0
[ 97.727676] de28 00000002 bf02a65c df89de5c df89de40 bf0203c8 bf016838 00000002 bf02787c
[ 97.735822]
[ 97.735825] IP: 0xdf89dc50:
[ 97.740068] dc50 00000000 00000000 df89dd80 00000000 00000817 00000000 df89dc9c df89dc78
[ 97.748214] dc70 c00368cc c003430c df89dd80 df88ae00 df89dd80 00000001 00000000 00000000
[ 97.756359] dc90 df89dcd4 df89dca0 c0036acc c003686c df17601c df88ae00 df89dccc 00000817
[ 97.764505] dcb0 c05f247c 00000000 df89dd80 df87b050 20000113 dfa991c4 df89dd7c df89dcd8
[ 97.772651] dcd0 c002f2f4 c00368f8 df89c000 00000042 0000002d c05ffcdc 60000013 0000000f
[ 97.780797] dcf0 df89dd14 df89dd00 c0448508 c0448030 00000002 00000000 df89dd9c df89dd18
[ 97.788942] dd10 c00578fc c04484d4 c05ffd68 00000002 2df3f42b 0000000c afa3d24b 00000016
[ 97.797088] dd30 60000013 60000013 df89dd5c 2020205b 342e3739 32303633 00205d39 00000000

WIFI模块使用的是SDIO接口，经过认真分析后，觉得应该从MMC驱动入手，毕竟是在MMC驱动出的问题。可关键是，查找了很久，也没发现什么可疑的。

最后无奈，采用最原始的方法，就是加LOG，一步一步的跟。

终于，还是被我找到原因了。

在SDIO驱动的sdio_reset_comm函数中，每次唤醒时，都会调用mmc_send_io_op_cond函数，现在出错时，就是这个函数返回失败了。

那么再研究下这个函数，发现它有通过mmc_wait_for_cmd函数来发命令给模块，而且传递的参数中，有MMC_CMD_RETRIES值，设置了3次。

那么，会不会是这个值太短了呢？

以我的经验，有的时候模块在唤醒的过程中，由于模块硬件本身没有准备好，还在进行模块本身的初始化，而这时候与模块进行通信有可能会导致通信失败。

那么，何不把MMC_CMD_RETRIES这个值改个极限值试试？即改一个极端的大一点的值。

我把它改成300，以及把当前函数下的mmc_delay(10)改成mmc_delay(100)，再测试。

奇迹出现了，唤醒后，它居然没有跑飞。

我欣喜若狂，赶紧测试多几次，发现还真没有跑飞的情况出现。

那么，这个问题就这么解决了？

以我的经验，不能马上下结论，需要多测看看会不会导致别的问题出现。

于是我再多测，发现还会有另外一个问题，即dhd_dev_reset: dhd_bus_devreset: -35

但这个问题不是因为我修改跑飞的情况出现的，而是之前就出现的。

但是现在已经没有多少时间查找了，于是我做了如下修改：

1、修改MMC驱动，休眠唤醒初始化模块次数增加。

2、深度休眠时，把WIFI的POWER及RESET脚置低，使模块断电。唤醒时再恢复。
3、在WIFI打开的情况下，在WIFI的设置界面，按“MENU”键，选择高级->Wi-Fi休眠策略->屏幕关闭时休眠时，android层修改为按POER键休眠时，卸载wifi驱动，唤醒时再加载。
4、在WIFI打开的情况下，当选择“充电时永不休眠”时，充电情况下，休眠时，锁住电源不让系统进入深度休眠（虽然进入深度休眠按照方法1已经改好，但测试时发现唤醒后会有10%的概率产生驱动出错的问题）。非充电情况下休眠时按照方法2操作。
5、在WIFI打开的情况下，当选择“永不休眠”时，休眠时锁住电源不让系统进入深度休眠。
按如上方法修改后，WIFI未测到出现休眠唤醒问题。

此问题得到圆满解决。