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. Kind regards Uffe -- 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
