similar to: [PATCH AUTOSEL 5.6 084/129] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges

Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state, currently in D3" "nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config space

in addition to that 028a12f5aa829 "drm/nouveau/gr/gp107,gp108: implement workaround for HW hanging during init" should probably get picked as well as it's fixing some runtime pm related issue on a handful of additional GPUs. I have a laptop myself which requires both of those patches. Applies to 5.5 and 5..4 as well. And both commits should probably get applied to older trees as

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ] Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state,

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ] Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state,

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ] Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state,

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ] Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state,

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ] Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state,

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ] Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state,

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ] Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state,

Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state, currently in D3" "nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config space

On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote: > > Fixes the infamous 'runtime PM' bug many users are facing on Laptops with > > Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. > > > > Depending on the used kernel there might be

Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device states. v2: convert to pci_dev quirk put a proper technical explanation of the issue as a in-code comment v3: disable it only for certain combinations of intel and nvidia hardware v4: simplify quirk by setting flag on the GPU itself v5: restructure quirk to make it easier to add new IDs fix whitespace issues

On Sat, Mar 21, 2020 at 2:02 AM Karol Herbst <kherbst at redhat.com> wrote: > > On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > > > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote: > > > Fixes the infamous 'runtime PM' bug many users are facing on Laptops with > > > Nvidia Pascal GPUs by skipping

On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote: > Fixes the infamous 'runtime PM' bug many users are facing on Laptops with > Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. > > Depending on the used kernel there might be messages like those in demsg: > > "nouveau 0000:01:00.0: Refused to change power state, currently in

Hi, On Tue, Mar 03, 2020 at 11:10:52AM +0100, Karol Herbst wrote: > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device > states. I think it is good to explain bit more here why this fix is needed. > v2: convert to pci_dev quirk > put a proper technical explanation of the issue as a in-code comment > v3: disable it only for certain combinations of

On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline <jcline at redhat.com> wrote: > > Make use of the devm_drm_dev_alloc() API to bind the lifetime of > nouveau_drm structure to the drm_device. This is important because a > reference to nouveau_drm is accessible from drm_device, which is > provided to a number of DRM layer callbacks that can run after the > deallocation of

On Sat, 2019-05-04 at 18:32 +0200, Karol Herbst wrote: > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/nouveau_acpi.c | 6 +++--- > drm/nouveau/nouveau_acpi.h | 4 ++-- > drm/nouveau/nouveau_drm.c | 15 +++++++++++---- > drm/nouveau/nouveau_drv.h | 2 ++ > 4 files changed, 18 insertions(+), 9 deletions(-) > > diff --git

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the

On Wed, Mar 4, 2020 at 10:33 AM Mika Westerberg <mika.westerberg at intel.com> wrote: > > Hi, > > On Tue, Mar 03, 2020 at 11:10:52AM +0100, Karol Herbst wrote: > > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device > > states. > > I think it is good to explain bit more here why this fix is needed. > is something like this fine?

While investigating the runpm issues on my GP107 I noticed that something inside devinit makes runpm break. If Nouveau loads up to the point right before doing devinit, runpm works without any issues, if devinit is ran, not anymore. Out of curiousity I even tried to "bisect" devinit by not running it on vbios provided signed PMU image, but on the devinit parser we have inside Nouveau.