On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu <peter@xxxxxxxxxxxxx> wrote: > On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote: >> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu <peter@xxxxxxxxxxxxx> wrote: >> > Hi, >> > >> > Here are two patches to fix an issue reported on kernel bugzilla (infinite loop >> > due to unchecked function) and a more important fix to fix hanging Optimus >> > machines when runtime PM is enabled (with pm/pci patches). >> > >> > These are the final patches targeting v4.8. Changes compared to v2[1]: >> > collected R-b from Hans and Mika and fixed a minor comment style issue. >> > >> > I recommend it to be merged before the pci/pm patches[2], otherwise there is a >> > window where newer Nvidia Optimus laptops might fail to runtime resume and/or >> > lock up. Once the pci/pm branch is merged I will propose another patch to >> > improve reliability[3]. >> > >> > Known issue with patch 4: when a Nvidia HDMI audio function is present, the >> > bridge will not suspend and hence the Nvidia card will still be powered. Fixing >> >> That's basically all optimus gpu's, right? Anything GT21x+ has a HDMI >> audio subfunction, and prior to that, the nvidia gpu tended to be the >> only gpu, or hard-muxed. >> >> If that's the case, that's pretty much a non-starter, IMO. > > For some reason the audio function tends to disappear/hide, so maybe it > is not as problematic as it appears (see > https://bugs.freedesktop.org/show_bug.cgi?id=75985). For my laptop I I'm aware of that bug. I believe this is an exceedingly rare scenario or it would have been reported a lot more. > also had to runtime suspend/resume before lspci -H1 shows the device, > loading with runpm=0 didn't return my HDMI audio device. Hm ok. Do you have the same laptop as the reporter of that bug? > > The powered on issue will also only appear on devices produced in 2013 > and newer that happen to have this ACPI _PR3 ACPI method (which is quite > common for new machines supporting Windows 8 though). > > For these newer laptops, after the pci/pm merge and after a patch like > http://www.spinics.net/lists/linux-pci/msg52601.html, the user can > revert to the old DSM method by booting with pcie_port_pm=off which will > retain the current behavior. > > The advantage of this patch is that it fixes memory corruption on some > devices. The risk is that the card stays on because the audio subsystem > needs some more work. FWIW, I was working on some patches that properly > suspended in presence of the HDA controller, but somehow the audio > device was not properly resumed resulting in "no AFG or MFG node found" > and "snd_hda_intel 0000:01:00.1: no codecs initialized". Does this restriction (runpm being broken in presence of the audio subfunction) only affect devices with _PR3? If so, that's a lot more palatable - I bet Windows 8+ is in an era when the display-less thing became more popular, and thus less likely to affect a ton of people. -ilia _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
