Linux休眠wifi,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 : []    lr : []    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未测到出现休眠唤醒问题。

此问题得到圆满解决。

    原文作者:Axaxaxc
    原文地址: https://blog.csdn.net/weixin_35448535/article/details/116907874
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞