similar to: [PATCH v2] drm/nouveau: Move irq setup/teardown to pci ctor/dtor

For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline

For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline

Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nvkm/subdev/pci/gk104.c | 8 ++++---- drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++++++++++ drm/nouveau/nvkm/subdev/pci/priv.h | 5 +++++ 3 files changed, 19 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pci/gk104.c b/drm/nouveau/nvkm/subdev/pci/gk104.c index e6803050..66489018 100644 ---

Signed-off-by: Karol Herbst <kherbst at redhat.com> Reviewed-by: Lyude Paul <lyude at redhat.com> --- drm/nouveau/nvkm/subdev/pci/gk104.c | 8 ++++---- drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++++++++++ drm/nouveau/nvkm/subdev/pci/priv.h | 5 +++++ 3 files changed, 19 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pci/gk104.c

v2: add force disable ASPM func pointer Signed-off-by: Karol Herbst <kherbst at redhat.com> Reviewed-by: Lyude Paul <lyude at redhat.com> (v1) --- drm/nouveau/nvkm/subdev/pci/gk104.c | 8 ++++---- drm/nouveau/nvkm/subdev/pci/gp100.c | 11 +++++++++++ drm/nouveau/nvkm/subdev/pci/priv.h | 5 +++++ 3 files changed, 20 insertions(+), 4 deletions(-) diff --git

this code is pretty usefull for now as nothing triggers it, but the link speed can be changed with a "gk104_pcie_set_link(pci, NVKM_PCIE_SPEED_8_0, 16);" as the last call inside gk104_pcie_init. In the future this should be helpful when using reverse prime with high resolutions on Pascal GPUs. I still need to verify this with a mmiotrace and do more testing, but everybody suffering

Signed-off-by: Karol Herbst <kherbst at redhat.com> Reviewed-by: Lyude Paul <lyude at redhat.com> --- drm/nouveau/nvkm/subdev/pci/gk104.c | 8 ++++---- drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++++++++++ drm/nouveau/nvkm/subdev/pci/priv.h | 5 +++++ 3 files changed, 19 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pci/gk104.c

On Thu, Jan 25, 2018 at 06:29:53PM -0500, Lyude Paul wrote: > This was made apparent by what appeared to be a regression in the > mainline kernel that started introducing suspend/resume issues for > nouveau: > > a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation) I'm just a dumb user here, but I confirm: CPU: AMD Phenom II X6 1055T, GPU: GTX 560 Ti 100% fail to

Apperantly things go south if we suspend the device with a different PCIE link speed set than it got booted with. Fixes runtime suspend on my gp107. This all looks like some bug inside the pci subsystem and I would prefer a fix there instead of nouveau, but maybe there is no real nice way of doing that outside of drivers? v2: squashed together patch 4 and 5 Signed-off-by: Karol Herbst

Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/include/nvkm/subdev/pci.h | 5 +++-- drm/nouveau/nvkm/subdev/pci/base.c | 7 +++++-- drm/nouveau/nvkm/subdev/pci/pcie.c | 15 +++++++++++---- drm/nouveau/nvkm/subdev/pci/priv.h | 1 + 4 files changed, 20 insertions(+), 8 deletions(-) diff --git a/drm/nouveau/include/nvkm/subdev/pci.h

On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > Apperantly things go south if we suspend the device with a different PCIE > > link speed set than it got booted with. Fixes runtime suspend on my gp107. > > > > This all looks like some bug inside the pci subsystem

Apperantly things go south if we suspend the device with a PCIe link speed set to 2.5. Fixes runtime suspend on my gp107. This all looks like some bug inside the pci subsystem and I would prefer a fix there instead of nouveau, but maybe there is no real nice way of doing that outside of drivers? v2: squashed together patch 4 and 5 v3: only restore pcie speed on machines with runpm add

On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > Apperantly things go south if we suspend the device with a different PCIE > link speed set than it got booted with. Fixes runtime suspend on my gp107. > > This all looks like some bug inside the pci subsystem and I would prefer a > fix there instead of nouveau, but maybe there is no real nice way of doing > that

On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > > > Apperantly things go south if we suspend the device

fixes runtime suspend on my gp107 Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nvkm/subdev/pci/base.c | 2 ++ drm/nouveau/nvkm/subdev/pci/pcie.c | 8 ++++++++ drm/nouveau/nvkm/subdev/pci/priv.h | 1 + 3 files changed, 11 insertions(+) diff --git a/drm/nouveau/nvkm/subdev/pci/base.c b/drm/nouveau/nvkm/subdev/pci/base.c index b6ebee6f..d9fb5a83 100644 ---

On Tue, Sep 17, 2019 at 8:01 AM Ben Skeggs <skeggsb at gmail.com> wrote: > > On Fri, 13 Sep 2019 at 21:33, Karol Herbst <kherbst at redhat.com> wrote: > > > > Apperantly things go south if we suspend the device with a PCIe link speed > > set to 2.5. Fixes runtime suspend on my gp107. > > > > This all looks like some bug inside the pci subsystem and I

On Tue, Sep 17, 2019 at 10:21 AM Ben Skeggs <skeggsb at gmail.com> wrote: > > On Tue, 17 Sep 2019 at 18:07, Karol Herbst <kherbst at redhat.com> wrote: > > > > On Tue, Sep 17, 2019 at 8:01 AM Ben Skeggs <skeggsb at gmail.com> wrote: > > > > > > On Fri, 13 Sep 2019 at 21:33, Karol Herbst <kherbst at redhat.com> wrote: > > > >

On Tue, May 21, 2019 at 4:13 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Tue, May 21, 2019 at 03:28:48PM +0200, Karol Herbst wrote: > > On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > > > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas

On Fri, 13 Sep 2019 at 21:33, Karol Herbst <kherbst at redhat.com> wrote: > > Apperantly things go south if we suspend the device with a PCIe link speed > set to 2.5. Fixes runtime suspend on my gp107. > > This all looks like some bug inside the pci subsystem and I would prefer a > fix there instead of nouveau, but maybe there is no real nice way of doing > that outside

On Tue, 17 Sep 2019 at 18:07, Karol Herbst <kherbst at redhat.com> wrote: > > On Tue, Sep 17, 2019 at 8:01 AM Ben Skeggs <skeggsb at gmail.com> wrote: > > > > On Fri, 13 Sep 2019 at 21:33, Karol Herbst <kherbst at redhat.com> wrote: > > > > > > Apperantly things go south if we suspend the device with a PCIe link speed > > > set to 2.5.