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. -- 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
