Hi Adrian, On Thu, Feb 16, 2017 at 7:09 AM, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 11/01/17 17:42, Ulf Hansson wrote: >> On 12 December 2016 at 23:55, João Paulo Rechi Vita <jprvita@xxxxxxxxx> wrote: >>> Hello Dong Adrian and Ulf, >>> >>> I'm working on enabling a BayTrail-based machine with very similar >>> hardware to one of the Intel Compute sticks, which is an Intel >>> BayTrail and has a RTL8723BS WiFi card on the SDIO bus. I'm using >>> Linux 4.8 with the driver from https://github.com/hadess/rtl8723bs, >>> and I was experiencing a complete machine hang when using the WiFi >>> card. Passing `intel_idle.max_cstate=1` together with the following >>> patch (with the sdhci_runtime_pm_get and sdhci_runtime_pm_put >>> implementations added back) makes the problem go away: >>> https://github.com/hadess/rtl8723bs/blob/master/patches_4.5/0002-mmc-sdhci-get-runtime-pm-when-sdio-irq-is-enabled.patch >> >> It's been a while ago and I wasn't able to dig out some information >> from earlier discussions/submissions. >> >>> >>> I could not find much information on why this was never sent upstream, >>> and would like to know if this approach would be acceptable, or if >>> there are any other better alternatives to solve this problem. I'm not >>> a runtime PM expert, but as I understand this keeps the device powered >>> on as long as interrupts are enabled, potentially increasing the power >>> consumption. As this kernel has to run several different machines >>> using the same code base and config, I would rather avoid something >>> that could have a negative impact on other platforms. >> >> Unless the board/soc supports an option to re-configure the SDIO IRQ >> as wakeup when entering runtime suspend state, there is no other way >> but to keep the device runtime resumed. >> >> For this specific case, I have seen two different solutions for how to >> allow the device to be runtime suspended when using SDIO IRQ. >> 1) Re-routing the SDIO IRQ DAT line as a GPIO IRQ at runtime suspend, >> thus a wakeup becomes enabled. >> 2) Using a completely separate line for SDIO IRQs and thus not a DAT >> line, configured as a GPIO IRQ. >> >>> >>> Any ideas appreciated, and I'm happy to try a newer tree if you guys >>> think some other commit might have fixed the problem. >> >> I think the best option right now, is something very similar to the >> patch you point to at github above. > > Sorry for the *very* slow reply! :-(. I need to find time to look at this, > but although the patch is OK for Intel it is wrong for other SDHCI-based > drivers which *do* runtime suspend with the clock (and perhaps the whole > host controller) still on and thus expect SDIO interrupts *during* runtime > suspend. When you have time to revisit this, another proposed fix is: mmc: sdhci: sdio-intel: Set SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk https://patchwork.kernel.org/patch/9478087/ Thanks Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
