similar to: [PATCH] pci/gp100: Enable changing pcie link speeds

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

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

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

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

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.

not much changed since the last time I sent those patches out, but there are a couple of annoying bug fixes, which users would probably never hit unless they do rmmod/modprobe nouveau cycles. Biggest change is that I force the link to a 8.0 speed rather than the speed the GPU came up with. Also this series depends on the PCIe improvement patches I sent out recently. Karol Herbst (4): pci:

CCing linux-pci and Bjorn Helgaas. Maybe we could get better insights on how a reasonable fix would look like. Anyway, to me this entire issue looks like something which has to be fixed on a PCI level instead of inside a driver, so it makes sense to ask the pci folks if they have any better suggestions. Original cover letter: While investigating the runpm issues on my GP107 I noticed that

I merged the both series I sent out recently into one bigger one so that it's more obvious on why all of that is needed. Biggest changes since last sent: * reworked the ASPM patch * removed "pci: add nvkm_pcie_get_speed" patch Please test this on Laptops and report back if it either breaks something or doesn't fix runpm. Thanks Karol Herbst (6): pci: disable ASPM before

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

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

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

First three patches are removing ACPI workarounds which should have never landed. The last four are adding a workaround to nouveau which seem to help quite a lot with the RTD3 issues with Nouveau, so let's discuss and get wider testing of those and see if there is any fallout or laptops where the issues don't get fixed. Karol Herbst (7): Revert "ACPI / OSI: Add OEM _OSI string to

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

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, 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 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.