similar to: [PATCH v2 0/4] nouveau RPM fixes for Optimus

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

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). An older (obsolete) patch for the first issue was tested by the reporter: https://bugzilla.kernel.org/show_bug.cgi?id=104791#c11 (it is replaced by "check for function 0x1B

Hi Peter, On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > can be runtime-suspended which disables power resources via ACPI. This > is incompatible with DSM, resulting in a GPU device which is still in D3 > and locks up the kernel on resume. > > Mirror the behavior of

On 27 May 2016 at 22:31, Peter Wu <peter at lekensteyn.nl> wrote: > On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote: >> Hi Peter, >> >> On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: >> > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port >> > can be runtime-suspended which disables

Replace nouveau_pr3_present() in favor of a more generic one, pci_pr3_present(). Also the presence of upstream bridge _PR3 doesn't need to go hand in hand with device's _DSM, so check _PR3 before _DSM. Signed-off-by: Kai-Heng Feng <kai.heng.feng at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 44 ++++++-------------------- 1 file changed, 10 insertions(+), 34

This is especially true when variables or functions are just called dsm without precising the v1. Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 64 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +-- drm/nouveau/nouveau_drm.c | 4 +-- drm/nouveau/nouveau_vga.c | 10 ++++---- 4 files changed, 41 insertions(+), 41

This is especially true when variables or functions are just called dsm without specifying the v1. Changes since v1: * Fix typo in commit explanation * Change has_dsm to has_mux in nouveau_dsm_detect Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 72 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +--

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- Hi, I am not sure what exactly 0x1B is used for, it seems related to HDMI

From: Sui Jingfeng <suijingfeng at loongson.cn> There is no function that can be used to get all PCI(e) devices in a system by matching against its the PCI base class code only, while keep the sub-class code and the programming interface ignored. Therefore, add the pci_get_base_class() function to suit the need. For example, if an application want to process all PCI(e) display devices in a

Ensure that the returned set of supported DSM functions (MUX, Optimus) match the ACPI handle that is set in nouveau_dsm_pci_probe. As there are no machines with a MUX function on just one PCI device and an Optimus on another, there should not be a functional impact. This change however makes this implicit assumption more obvious. Convert int to bool and rename has_dsm to has_mux while at it. Let

Ensure that the returned set of supported DSM functions (MUX, Optimus) match the ACPI handle that is set in nouveau_dsm_pci_probe. As there are no machines with a MUX function on just one PCI device and an Optimus on another, there should not be a functional impact. This change however makes this implicit assumption more obvious. Convert int to bool and rename has_dsm to has_mux while at it. Let

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 18 +++++++++++++----- 1 file

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Reviewed-by: Hans de Goede <hdegoede at redhat.com> Signed-off-by: Peter Wu <peter at lekensteyn.nl> ---

Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port can be runtime-suspended which disables power resources via ACPI. This is incompatible with DSM, resulting in a GPU device which is still in D3 and locks up the kernel on resume (on a Clevo P651RA, GTX965M). Mirror the behavior of Windows 8 and newer[1] (as observed via an AMLi debugger trace) and stop using the

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 17 ++++++++++++----- 1 file

There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin

Check whether the kernel really supports power resources for a device, otherwise the power might not be removed when the device is runtime suspended (DSM should still work in these cases where PR does not). Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398 Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM") Signed-off-by: Peter Wu <peter at

Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port can be runtime-suspended which disables power resources via ACPI. This is incompatible with DSM, resulting in a GPU device which is still in D3 and locks up the kernel on resume. Mirror the behavior of Windows 8 and newer[1] (as observed via an AMLi debugger trace) and stop using the DSM functions for D3cold when

Hi, same for me. The screen does not freeze anymore and the boot succeeds. But now I have this kernel message during boot (for the second card): [ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22 Do you want to have the complete dmesg log? I think this is a new bug. Your patch works for the previous one, so you can close it. Yours, Claas On

On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote: > Hi Peter, > > On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: > > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > > can be runtime-suspended which disables power resources via ACPI. This > > is incompatible with DSM, resulting in a GPU device