[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
Ping, would it be possible to get some acks and merge it for 4.8? Current -next is broken (on modern laptops as expected) and these series fix the issues according to an IRC report. The audio issue mentioned below should not give issues, modern laptops do not seem to expose the audio device by default (https://bugs.freedesktop.org/show_bug.cgi?id=75985). On Windows the audio device only appears after inserting the HDMI/miniDP cable (my laptop has no other connectors), enabling the card for rendering purposes has no effect on the availability of the audio device. Kind regards, Peter On Fri, Jul 15, 2016 at 03:12:14PM +0200, Peter Wu 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 > this properly will require more work[4], until then you can kill the audio > device and make runtime PM work properly: > > echo 1 > /sys/bus/pci/devices/:01:00.1/remove > > Kind regards, > Peter > > [1]: https://lists.freedesktop.org/archives/nouveau/2016-July/025519.html > [2]: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/?h=pci/pm > [3]: http://www.spinics.net/lists/linux-pci/msg52601.html > [4]: https://lists.freedesktop.org/archives/dri-devel/2016-July/112759.html > > Peter Wu (4): > drm/nouveau/acpi: ensure matching ACPI handle and supported functions > drm/nouveau/acpi: return supported DSM functions > drm/nouveau/acpi: check for function 0x1B before using it > drm/nouveau/acpi: fix lockup with PCIe runtime PM > > drivers/gpu/drm/nouveau/nouveau_acpi.c | 105 > + > 1 file changed, 68 insertions(+), 37 deletions(-) > > -- > 2.9.0
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 06:54:27PM +0200, Peter Wu wrote: > On Fri, Jul 15, 2016 at 12:41:49PM -0400, Ilia Mirkin wrote: > > On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu 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 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? > > Nope, I have a Clevo P651RA (GTX965M). That reporter has a Dell XPS 15, > but it also seems present for the Lenovo ThinkPad T420s (see comment on > bug), Asus N56VZ, MSI GT60 2PE, Dell L502x (Launchpad 1377653), Asus > G46vw (Ask Ubuntu user). There is another AU report for a GT 525M > (laptop brand/model unknown). > > Maybe there are more affected users, but then they did not notice it > because they did not use HDMI audio. > > > > > > > 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 :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. > > Yes it only affects those devices with _PR3. I downloaded all .tar.gz files from the big Launchpad bug that collects DSDTs (and more recently also dmidecode/lspci) and ran an analysis. The result (limited to files which actually had a lspci and dmidecode file): - 111 Nvidia video devices - 20 out of these have an audio device. - 18 use _PR3, 93 use DSM (or gmux). - Exactly zero use _PR3 and have an audio device! The post-processed data (sorted by BIOS date) and (quick and dirty) scripts are attached. Hopefully these results are convincing enough :-) -- Kind regards, Peter Wu https://lekensteyn.nl -- next part -- 001 Apple_Inc.-MacBookPro6,1 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT216M [GeForce GT 330M] [10de:0a29] (rev a2) (prog-if 00 [VGA controller]) 01:00.1 Audio device [0403]: NVIDIA Corporation GT216 HDMI Audio Controller [10de:0be2] (rev a1) Date: bios-release-date : 07/26/10 Use _DSM! 002 BenQ-Joybook_S42 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96 [GeForce 9600M GT] [10de:0649] (rev a1) (prog-if 00 [VGA controller]) (No audio device found) Date: bios-release-date : 04/10/2009 Use _DSM! 003
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 12:41:49PM -0400, Ilia Mirkin wrote: > On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu 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 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? Nope, I have a Clevo P651RA (GTX965M). That reporter has a Dell XPS 15, but it also seems present for the Lenovo ThinkPad T420s (see comment on bug), Asus N56VZ, MSI GT60 2PE, Dell L502x (Launchpad 1377653), Asus G46vw (Ask Ubuntu user). There is another AU report for a GT 525M (laptop brand/model unknown). Maybe there are more affected users, but then they did not notice it because they did not use HDMI audio. > > > > 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 :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. Yes it only affects those devices with _PR3. -- Kind regards, Peter Wu https://lekensteyn.nl
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote: > On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu 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 also had to runtime suspend/resume before lspci -H1 shows the device, loading with runpm=0 didn't return my HDMI audio device. 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 :01:00.1: no codecs initialized". -- Kind regards, Peter Wu https://lekensteyn.nl
[PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
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 this properly will require more work[4], until then you can kill the audio device and make runtime PM work properly: echo 1 > /sys/bus/pci/devices/:01:00.1/remove Kind regards, Peter [1]: https://lists.freedesktop.org/archives/nouveau/2016-July/025519.html [2]: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/?h=pci/pm [3]: http://www.spinics.net/lists/linux-pci/msg52601.html [4]: https://lists.freedesktop.org/archives/dri-devel/2016-July/112759.html Peter Wu (4): drm/nouveau/acpi: ensure matching ACPI handle and supported functions drm/nouveau/acpi: return supported DSM functions drm/nouveau/acpi: check for function 0x1B before using it drm/nouveau/acpi: fix lockup with PCIe runtime PM drivers/gpu/drm/nouveau/nouveau_acpi.c | 105 + 1 file changed, 68 insertions(+), 37 deletions(-) -- 2.9.0
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 12:40 PM, Alex Deucher wrote: > On Fri, Jul 15, 2016 at 12:31 PM, Ilia Mirkin wrote: >> On Fri, Jul 15, 2016 at 12:27 PM, Alex Deucher >> wrote: >>> On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin >>> wrote: On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu 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. >>> >>> I'd imagine there is a strap on the asic so the audio function is only >>> enabled if there is a connector actually wired to the dGPU. It >>> doesn't make much sense to expose audio if there is no way to use it. >> >> A lot of the time, there actually is a connector wired up. A lot of >> the other time, there is no connector, but the display unit is still >> there. Very recently, NVIDIA gpu's have started coming out marked as >> "3d accelerator", which sometimes but not always means that there's no >> display unit, and for those, I would assume there is no audio >> subfunction. >> > > Just because there is a display block, doesn't mean the audio function > is always enabled. I suspect it is disabled by hardware straps on > systems with no display connectors or other specific OEM configs. That's what I'm saying - it is not. There are straps, and they can be used to disable the display block. But they're often not set that way. -ilia
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu 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 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 :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
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 12:31 PM, Ilia Mirkin wrote: > On Fri, Jul 15, 2016 at 12:27 PM, Alex Deucher > wrote: >> On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin >> wrote: >>> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu 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. >> >> I'd imagine there is a strap on the asic so the audio function is only >> enabled if there is a connector actually wired to the dGPU. It >> doesn't make much sense to expose audio if there is no way to use it. > > A lot of the time, there actually is a connector wired up. A lot of > the other time, there is no connector, but the display unit is still > there. Very recently, NVIDIA gpu's have started coming out marked as > "3d accelerator", which sometimes but not always means that there's no > display unit, and for those, I would assume there is no audio > subfunction. > Just because there is a display block, doesn't mean the audio function is always enabled. I suspect it is disabled by hardware straps on systems with no display connectors or other specific OEM configs. Alex
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 12:27 PM, Alex Deucher wrote: > On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin wrote: >> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu 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. > > I'd imagine there is a strap on the asic so the audio function is only > enabled if there is a connector actually wired to the dGPU. It > doesn't make much sense to expose audio if there is no way to use it. A lot of the time, there actually is a connector wired up. A lot of the other time, there is no connector, but the display unit is still there. Very recently, NVIDIA gpu's have started coming out marked as "3d accelerator", which sometimes but not always means that there's no display unit, and for those, I would assume there is no audio subfunction. However this is a fraction of all devices using runpm. -ilia
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin wrote: > On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu 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. I'd imagine there is a strap on the asic so the audio function is only enabled if there is a connector actually wired to the dGPU. It doesn't make much sense to expose audio if there is no way to use it. Alex
[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu 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. -ilia
