> -----Original Message----- > From: linux-mmc-owner@xxxxxxxxxxxxxxx [mailto:linux-mmc- > owner@xxxxxxxxxxxxxxx] On Behalf Of Adrian Hunter > Sent: Thursday, February 16, 2017 3:09 PM > To: Ulf Hansson <ulf.hansson@xxxxxxxxxx>; João Paulo Rechi Vita > <jprvita@xxxxxxxxx> > Cc: Dong Aisheng <b29396@xxxxxxxxxxxxx>; João Paulo Rechi Vita > <jprvita@xxxxxxxxxxxx>; linux-mmc@xxxxxxxxxxxxxxx; linux@xxxxxxxxxxxx > Subject: Re: SDIO bus hang on BayTrail machines > > 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. Did you look for possible wa on the wifi side? Maybe you can look into the wifi driver module params - can it be loaded with d0i3 disabled? Or even with power management disabled (power scheme = CAM)? Also maybe try Intel's wifi card... Cheers, Avri > > > > 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 -- 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
