Bug 88061 - brcmfmac lacks proper runtime-pm support
Summary: brcmfmac lacks proper runtime-pm support
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Wireless (show other bugs)
Hardware: x86-64 Linux
: P1 enhancement
Assignee: networking_wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-11 18:13 UTC by Michael Shigorin
Modified: 2014-12-01 16:07 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.18-rc4
Tree: Mainline
Regression: No


Attachments

Description Michael Shigorin 2014-11-11 18:13:24 UTC
BCM943241 (B4) within Aava Inari 8 baytrail-based tablet fails to connect to wireless networks upon having scanned these successfully with this repeating:

kernel: brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
kernel: brcmfmac: brcmf_cfg80211_scan: scan error (-11)

brcmfmac messages upon bootup:

[    6.753368] brcmfmac: F1 signature read @0x18000000=0x16c54324
[    6.756695] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 4324 rev 5 pmurev 17
[    6.757795] usbcore: registered new interface driver brcmfmac
[    7.002706] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Nov 15 2013 19:14:45 version 6.10.199.2 (r437079) FWID 01-1e5283bf
[    8.664258] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[    8.664265] brcmfmac: brcmf_add_if: ignore IF event
[   10.774432] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   20.951472] brcmfmac: brcmf_escan_timeout: timer expired
[   44.085789] brcmfmac: brcmf_escan_timeout: timer expired
[   77.120678] brcmfmac: brcmf_escan_timeout: timer expired

The kernel is a 64-bit one, mostly 3.18-rc4 with the patch referenced in bug 69011, comment 61 applied; firmware and nvram files taken from ODM's android.

Looks like there were similar problems on T100TA: https://lists.debian.org/debian-kernel/2014/08/msg00294.html

What should I do/provide to help diagnose this issue and sort it out?

TIA :)
Comment 1 Michael Shigorin 2014-11-11 18:17:14 UTC
CCing Intel and Broadcom folks who might know innards of Baytrail and brcmfmac.
Comment 2 Arend van Spriel 2014-11-16 15:14:01 UTC
The systems typically come with sdhci-acpi driver used for the SDIO host controller, which does runtime-pm. However, the brcmfmac driver does not support runtime-pm so when host controller goes into runtime suspend the firmware can not communicate with the host and brcmfmac is idle as it waits for firmware response.

So please confirm it works with runtime-pm disabled for the host controller through sysfs. To locate the host controller, I think you need to go to /sys/bus/platform/drivers/sdhci-acpi. It can be bound to multiple devices so you have to find the correct one or disable runtime-pm for both.
Comment 3 Michael Shigorin 2014-11-17 14:59:14 UTC
Confirmed:

---
bus/platform/drivers/sdhci-acpi/80860F14:00/power/control = on
bus/platform/drivers/sdhci-acpi/80860F14:01/power/control = on
bus/platform/drivers/sdhci-acpi/INT33BB:00/power/control = on
--- /etc/sysfs.conf

gets me working wlan0; looks like INT33BB:00 is responsible for wifi on this particular platform.

This is a valid workaround, thank you; is the bug still valid as a feature request to implement runtime PM support?
Comment 4 Arend van Spriel 2014-11-26 19:25:56 UTC
Not sure whether bugzilla is to track feature requests. We could add runtime-pm in brcmfmac, but that does not solve this issue. It would require an API that brcmfmac could use to inform the mmc host-controller not to go into runtime-suspend or at least allow the device to wake it up. I did not look into runtime-pm yet but from a quick glance I guess we should use pm_runtime_forbid()/pm_runtime_allow() on mmc_host->parent, which should be the sdhci-acpi device if I am not mistaken.
Comment 5 Michael Shigorin 2014-11-26 21:04:22 UTC
It's definitely up to you, Arend :-)  Always glad to test of course.
Comment 6 Michael Shigorin 2014-11-26 21:54:40 UTC
Could this patch be related?

https://github.com/AdamWill/baytrail-m/blob/master/kernel/sdhci-pm.patch
Comment 7 Michael Shigorin 2014-12-01 16:07:11 UTC
Actually this was enough:

---
bus/platform/drivers/sdhci-acpi/INT33BB:00/power/control = on
---

Note You need to log in before you can comment on or make changes to this bug.