mwifiex_sdio problem: firmware fails to be active in time

DISCUSSION Daniel Mack 3 participants 8 messages Oct 17, 2012 – Nov 1, 2012 1 message not in the archive

Share & tools

Daniel Mack

author

2012-10-17 23:50 UTC #0 lore raw

Hi,

we're trying to get a SD8787 to play which is connected via SDIO to an OMAP hsmmc (AM33xx hardware). This fails with the following message:

# modprobe mwifiex_sdio
[   13.984779] [sched_delayed] sched: RT throttling activated
[   22.401700] mwifiex_sdio mmc0:0001:1: FW failed to be active in time

The firmware sd8787_uapsta.bin was taken from the linux-firmware.git and apparently is transferred successfully, but then consequently fails to do start up. When compiled with CONFIG_MMC_CONFIG=y, tons of successful messages are logged like this:

[ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
[ 2607.867713] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
00000000
[ 2607.883273] mmc0: starting CMD52 arg 00000a00 flags 00000195
[ 2607.883327] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
00000000
[ 2607.898905] mmc0: starting CMD52 arg 00000a00 flags 00000195

The kernel we're based on is Linus' current merge tree (3.7-rc1), but earlier version (3.6) have shown the same issue.

Before we start digging into this, I want to ask whether there are any common pitfalls we should be aware of and that could cause this?

Please let me know whether you need any further information.

Many thanks,
Daniel

Bing Zhao

2012-10-18 00:22 UTC #1 lore raw

SGkgRGFuaWVsLA0KDQo+IEhpLA0KPiANCj4gd2UncmUgdHJ5aW5nIHRvIGdldCBhIFNEODc4NyB0 byBwbGF5IHdoaWNoIGlzIGNvbm5lY3RlZCB2aWEgU0RJTyB0byBhbg0KPiBPTUFQIGhzbW1jIChB TTMzeHggaGFyZHdhcmUpLiBUaGlzIGZhaWxzIHdpdGggdGhlIGZvbGxvd2luZyBtZXNzYWdlOg0K PiANCj4gIyBtb2Rwcm9iZSBtd2lmaWV4X3NkaW8NCj4gWyAgIDEzLjk4NDc3OV0gW3NjaGVkX2Rl bGF5ZWRdIHNjaGVkOiBSVCB0aHJvdHRsaW5nIGFjdGl2YXRlZA0KPiBbICAgMjIuNDAxNzAwXSBt d2lmaWV4X3NkaW8gbW1jMDowMDAxOjE6IEZXIGZhaWxlZCB0byBiZSBhY3RpdmUgaW4gdGltZQ0K PiANCj4gVGhlIGZpcm13YXJlIHNkODc4N191YXBzdGEuYmluIHdhcyB0YWtlbiBmcm9tIHRoZSBs aW51eC1maXJtd2FyZS5naXQgYW5kDQo+IGFwcGFyZW50bHkgaXMgdHJhbnNmZXJyZWQgc3VjY2Vz c2Z1bGx5LCBidXQgdGhlbiBjb25zZXF1ZW50bHkgZmFpbHMgdG8NCj4gZG8gc3RhcnQgdXAuIFdo ZW4gY29tcGlsZWQgd2l0aCBDT05GSUdfTU1DX0NPTkZJRz15LCB0b25zIG9mIHN1Y2Nlc3NmdWwN Cj4gbWVzc2FnZXMgYXJlIGxvZ2dlZCBsaWtlIHRoaXM6DQo+IA0KPiBbIDI2MDcuODY3NjYwXSBt bWMwOiBzdGFydGluZyBDTUQ1MiBhcmcgMDAwMDBhMDAgZmxhZ3MgMDAwMDAxOTUNCj4gWyAyNjA3 Ljg2NzcxM10gbW1jMDogcmVxIGRvbmUgKENNRDUyKTogMDogMDAwMDEwMDAgMDAwMDAwMDAgMDAw MDAwMDANCj4gMDAwMDAwMDANCj4gWyAyNjA3Ljg4MzI3M10gbW1jMDogc3RhcnRpbmcgQ01ENTIg YXJnIDAwMDAwYTAwIGZsYWdzIDAwMDAwMTk1DQo+IFsgMjYwNy44ODMzMjddIG1tYzA6IHJlcSBk b25lIChDTUQ1Mik6IDA6IDAwMDAxMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQo+IDAwMDAwMDAwDQo+ IFsgMjYwNy44OTg5MDVdIG1tYzA6IHN0YXJ0aW5nIENNRDUyIGFyZyAwMDAwMGEwMCBmbGFncyAw MDAwMDE5NQ0KDQpJdCBrZWVwcyByZWFkaW5nIEludF9QZW5kaW5nIChDQ0NSIHJlZ2lzdGVyIDB4 MDUpLiBQZXJoYXBzIHlvdSBoYXZlIGludGVycnVwdCBzdG9ybSBoZXJlPw0KQ291bGQgeW91IHBs ZWFzZSBjaGVjayBpZiB5b3VyIGNvbnRyb2xsZXIgY2xlYXJzIGludGVycnVwdCBwcm9wZXJseT8N Cg0KPiANCj4gDQo+IFRoZSBrZXJuZWwgd2UncmUgYmFzZWQgb24gaXMgTGludXMnIGN1cnJlbnQg bWVyZ2UgdHJlZSAoMy43LXJjMSksIGJ1dA0KPiBlYXJsaWVyIHZlcnNpb24gKDMuNikgaGF2ZSBz aG93biB0aGUgc2FtZSBpc3N1ZS4NCj4gDQo+IEJlZm9yZSB3ZSBzdGFydCBkaWdnaW5nIGludG8g dGhpcywgSSB3YW50IHRvIGFzayB3aGV0aGVyIHRoZXJlIGFyZSBhbnkNCj4gY29tbW9uIHBpdGZh bGxzIHdlIHNob3VsZCBiZSBhd2FyZSBvZiBhbmQgdGhhdCBjb3VsZCBjYXVzZSB0aGlzPw0KDQpZ b3UgbWF5IHdhbnQgdG8gZ2V0IGEgbmV3ZXIgZmlybXdhcmUgcmVsZWFzZSBmcm9tIGhlcmU6DQoN Cmh0dHA6Ly9naXQubWFydmVsbC5jb20vP3A9bXdpZmlleC1maXJtd2FyZS5naXQ7YT1zdW1tYXJ5 DQpnaXQ6Ly9naXQubWFydmVsbC5jb20vbXdpZmlleC1maXJtd2FyZS5naXQNCg0KPiANCj4gUGxl YXNlIGxldCBtZSBrbm93IHdoZXRoZXIgeW91IG5lZWQgYW55IGZ1cnRoZXIgaW5mb3JtYXRpb24u DQoNCkl0IG1pZ2h0IGJlIGhlbHBmdWwgaWYgeW91IHBvc3QgbWVzc2FnZXMgYmVmb3JlIHRoaXMg bGluZToNCg0KWyAyNjA3Ljg2NzY2MF0gbW1jMDogc3RhcnRpbmcgQ01ENTIgYXJnIDAwMDAwYTAw IGZsYWdzIDAwMDAwMTk1DQoNClRoYW5rcywNCkJpbmcNCg0KPiANCj4gDQo+IE1hbnkgdGhhbmtz LA0KPiBEYW5pZWwNCg==

Daniel Mack

author

2012-10-18 16:08 UTC #2 lore raw

Hi Bing,

thanks for your time.

Quoted 20 lines · Bing Zhao

Quoted 12 lines
we're trying to get a SD8787 to play which is connected via SDIO to an OMAP hsmmc (AM33xx hardware). This fails with the following message:
# modprobe mwifiex_sdio
[   13.984779] [sched_delayed] sched: RT throttling activated
[   22.401700] mwifiex_sdio mmc0:0001:1: FW failed to be active in time
The firmware sd8787_uapsta.bin was taken from the linux-firmware.git and apparently is transferred successfully, but then consequently fails to do start up. When compiled with CONFIG_MMC_CONFIG=y, tons of successful messages are logged like this:
Quoted 7 lines
[ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
[ 2607.867713] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
00000000
[ 2607.883273] mmc0: starting CMD52 arg 00000a00 flags 00000195
[ 2607.883327] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
00000000
[ 2607.898905] mmc0: starting CMD52 arg 00000a00 flags 00000195

Quoted 2 lines

It keeps reading Int_Pending (CCCR register 0x05). Perhaps you have interrupt storm here? Could you please check if your controller clears interrupt properly?

The reason for this issue was a different one: the 32KHz clock was not running. I just learned that the firmware download will succeed nevertheless, but the firmware won't start. Note to myself: make sure to rule out any hardware issue before bordering developers :-/ But that posting may be a help to someone with similar issues one day ...

Quoted 10 lines

Quoted 5 lines
The kernel we're based on is Linus' current merge tree (3.7-rc1), but earlier version (3.6) have shown the same issue.
Before we start digging into this, I want to ask whether there are any common pitfalls we should be aware of and that could cause this?
You may want to get a newer firmware release from here:
http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
git://git.marvell.com/mwifiex-firmware.git

Note that contains the same firmware binary than the linux-firmware repository.

Quoted 5 lines

Quoted 1 line
Please let me know whether you need any further information.
It might be helpful if you post messages before this line:
[ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195

Thanks again!

Daniel

A message that is not in the archive (sent off-list or not yet received): CAMXE1-qWOKphtOjUYWUz1CLDUtAynODvHmLm60rJMC=jBtRsNw@mail.gmail.com

Daniel Mack

author

2012-10-26 20:59 UTC #4 lore raw

[have to re-open this issue again]

Quoted 2 lines · Andrei Emeltchenko

I have the same board and see this problem sometimes. Reloading modules might help, if not reboot always works :).

I thought I solved this issue, but I can't reproduce the running version anymore unfortunately. It constantly fails with the error I described, even though the clock and all voltages etc are definitely stable. I can also rule out hardware issues as the BSP kernel (3.2.18) works just fine with the same setup including the firmware image.

Andrei, may I ask which board you have exactly? What kernel version are you based on? I wonder if the firmware is actually transferred correctly, or which reason there could be for it not to start up. Could that be related to the recent AM33xx/omap_hsmmc DMA reworks? [copied Matt]

Bing, FWIW here are some more complete logs with CONFIG_MMC_DEBUG=y.

This is the detection of the SDIO card:

http://pastebin.com/h9VDaExh

And this is what happens after "modprobe mwifiex_sdio":

http://pastebin.com/w5bcz6Aa (part 1/2)
http://pastebin.com/G5wfnPrg (part 2/2)

Can anyone see what's wrong here?

Thanks again,
Daniel

Quoted 72 lines

18.10.2012 18:09 пользователь "Daniel Mack" <[email protected] <mailto:[email protected]>> написал:
Quoted 14 lines
Hi Bing,
thanks for your time.
Quoted 8 lines · Bing Zhao
Quoted 8 lines
we're trying to get a SD8787 to play which is connected via SDIO to an OMAP hsmmc (AM33xx hardware). This fails with the following message:
# modprobe mwifiex_sdio
[   13.984779] [sched_delayed] sched: RT throttling activated
[   22.401700] mwifiex_sdio mmc0:0001:1: FW failed to be active in time
The firmware sd8787_uapsta.bin was taken from the
linux-firmware.git and
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
apparently is transferred successfully, but then consequently fails to do start up. When compiled with CONFIG_MMC_CONFIG=y, tons of successful messages are logged like this:
[ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
[ 2607.867713] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
00000000
[ 2607.883273] mmc0: starting CMD52 arg 00000a00 flags 00000195
[ 2607.883327] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
00000000
[ 2607.898905] mmc0: starting CMD52 arg 00000a00 flags 00000195
Quoted 1 line
Quoted 1 line
It keeps reading Int_Pending (CCCR register 0x05). Perhaps you have
interrupt storm here?
Quoted 18 lines
Quoted 1 line
Could you please check if your controller clears interrupt properly?
The reason for this issue was a different one: the 32KHz clock was not running. I just learned that the firmware download will succeed nevertheless, but the firmware won't start. Note to myself: make sure to rule out any hardware issue before bordering developers :-/ But that posting may be a help to someone with similar issues one day ...
Quoted 10 lines
Quoted 5 lines
The kernel we're based on is Linus' current merge tree (3.7-rc1), but earlier version (3.6) have shown the same issue.
Before we start digging into this, I want to ask whether there are any common pitfalls we should be aware of and that could cause this?
You may want to get a newer firmware release from here:
http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
git://git.marvell.com/mwifiex-firmware.git
<http://git.marvell.com/mwifiex-firmware.git>
Quoted 11 lines
Note that contains the same firmware binary than the linux-firmware repository.
Quoted 5 lines
Quoted 1 line
Please let me know whether you need any further information.
It might be helpful if you post messages before this line:
[ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
Quoted 6 lines
Thanks again!
Daniel
--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
Quoted 1 line
the body of a message to [email protected]
<mailto:[email protected]>
Quoted 1 line
More majordomo info at http://vger.kernel.org/majordomo-info.html

Daniel Mack

author

2012-10-28 15:49 UTC #5 lore raw

Quoted 9 lines · Daniel Mack

[have to re-open this issue again]
Quoted 2 lines · Andrei Emeltchenko
I have the same board and see this problem sometimes. Reloading modules might help, if not reboot always works :).
I thought I solved this issue, but I can't reproduce the running version anymore unfortunately. It constantly fails with the error I described, even though the clock and all voltages etc are definitely stable.

Ok, following up on my own writings: I solved this issue. It took me awhile to figure out that the 88WSD8787 is really picky about the clock/power sequencing. It really needs >= 1ms delay in the startup phase, otherwise the firmware won't start up.

So if anyone has this problem, make sure to care for that very detail.

Daniel

Andrei Emeltchenko

2012-11-01 09:48 UTC #6 lore raw

Hi Daniel,

Quoted 7 lines · Daniel Mack

Quoted 6 lines · Daniel Mack
[have to re-open this issue again]
Quoted 2 lines · Andrei Emeltchenko
I have the same board and see this problem sometimes. Reloading modules might help, if not reboot always works :).

Quoted 8 lines

Quoted 3 lines
I thought I solved this issue, but I can't reproduce the running version anymore unfortunately. It constantly fails with the error I described, even though the clock and all voltages etc are definitely stable.
Ok, following up on my own writings: I solved this issue. It took me awhile to figure out that the 88WSD8787 is really picky about the clock/power sequencing. It really needs >= 1ms delay in the startup phase, otherwise the firmware won't start up.

So did you put delay in a marvell sdio driver?

Best regards
Andrei Emeltchenko

Quoted 6 lines

So if anyone has this problem, make sure to care for that very detail.
Daniel

Daniel Mack

author

2012-11-01 11:10 UTC #7 lore raw

Quoted 14 lines · Andrei Emeltchenko

Hi Daniel,
Quoted 11 lines · Daniel Mack
Quoted 9 lines · Daniel Mack
[have to re-open this issue again]
Quoted 2 lines · Andrei Emeltchenko
I have the same board and see this problem sometimes. Reloading modules might help, if not reboot always works :).
I thought I solved this issue, but I can't reproduce the running version anymore unfortunately. It constantly fails with the error I described, even though the clock and all voltages etc are definitely stable.

Quoted 6 lines

Quoted 4 lines
Ok, following up on my own writings: I solved this issue. It took me awhile to figure out that the 88WSD8787 is really picky about the clock/power sequencing. It really needs >= 1ms delay in the startup phase, otherwise the firmware won't start up.
So did you put delay in a marvell sdio driver?

No, that has to be done by some code that first enables the clock and then asserts the PDN line (assuming that clock is generated by some sort of PLL or CPU).

Daniel

Andrei Emeltchenko

2012-11-01 09:46 UTC #8 lore raw

In reply to Daniel Mack

Hi Mack,

Quoted 6 lines · Daniel Mack

[have to re-open this issue again]
Quoted 2 lines · Andrei Emeltchenko
I have the same board and see this problem sometimes. Reloading modules might help, if not reboot always works :).

Quoted 7 lines

I thought I solved this issue, but I can't reproduce the running version anymore unfortunately. It constantly fails with the error I described, even though the clock and all voltages etc are definitely stable. I can also rule out hardware issues as the BSP kernel (3.2.18) works just fine with the same setup including the firmware image.
Andrei, may I ask which board you have exactly?

I do not know exactly, it is MARVELL RD8787 AG1_V3 with WIB Adapter v3.

Quoted 2 lines

What kernel version are
you based on?

I use latest bluetooth-next which is 3.7-rc1 + some bluetooth & wireless patches

Best regards
Andrei Emeltchenko