similar to: [PATCH] pci/msi: disable MSI on big-endian platforms by default

704a6c008b7942bb7f30bb43d2a6bcad7f543662 broke pci msi rearm for g92 GPUs. g92 needs the nv46_pci_msi_rearm, where g94+ gpus used nv40_pci_msi_rearm. Reported-by: Andrew Randrianasulu <randrianasulu at gmail.com> Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/include/nvkm/subdev/pci.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 20 +++++++-------

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

Hi Emil, On 02/12/2014 11:18 PM, Emil Velikov wrote: > On 12/02/14 05:38, Alexandre Courbot wrote: >> Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead >> of PCI to which Nouveau is tightly dependent. This patch allows Nouveau >> to handle platform devices by: >> >> - abstracting PCI-dependent functions that were typically used for >>

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

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

overall it is for the most part the same as my older version. I cleaned up some copyright things, so that it is more like the others. Also I moved the print about the max speed supported into preinit and did some other minor cleanups in the 3rd commit. Happy testing (and performance for prime offloading setups) Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement

overall the same as the old stuff, but with better namings and tirivialy improved code here and there Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement generic code for PCIe speed change pci: implement pcie speed change for tesla pci: implement pcie speed change on Fermi pci: implement PCIe speed change for kepler+ bios/perf: parse the pci speed from the

this patch series implements PCIe speed changes for Tesla and newer. The Kepler and Fermi bits are tested on my cards at home. Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement generic code for PCIe speed change pci: implement pcie speed change for tesla pci: implement pcie speed change on Fermi pci: implement PCIe speed change for kepler+ bios/perf:

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

Several users have, over time, reported issues with MSI on these IGPs. They're old, rarely available, and MSI doesn't provide such huge advantages on them. Just disable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87361 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74492 Fixes: fa8c9ac72fe ("drm/nv4c/mc: nv4x igp's have a different msi rearm register")

On my GP107 when I load nouveau after unloading it, for some reason the GPU stopped sending or the CPU stopped receiving interrupts if MSI was enabled. Doing a rearm once before getting any interrupts fixes this. Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nvkm/subdev/pci/base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git

MSIs were only problematic on some old, broken chipsets. But now that we already see systems where PCI legacy interrupts are somewhat flaky, it's really time to move to MSIs. Signed-off-by: Lucas Stach <dev at lynxeye.de> --- drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 + drivers/gpu/drm/nouveau/core/subdev/mc/base.c | 17 +++++++++++++++++ 2 files changed, 18

Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs: > On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: > > MSIs were only problematic on some old, broken chipsets. But now that we > > already see systems where PCI legacy interrupts are somewhat flaky, it's > > really time to move to MSIs. > > > > Signed-off-by: Lucas Stach

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

Hi Team I'm facing following error while running libvirt on ppc platfrom with cpu model as e5500.. 2015-07-15 06:30:37.307+0000: 3976: warning : virQEMUCapsInit:1001 : Failed to get host CPU 2015-07-15 06:30:37.642+0000: 3976: error : virFirewallApply:936 : out of memory 2015-07-15 06:31:16.451+0000: 3969: error : cpuNodeData:344 : this function is not supported by the connection driver:

On Tue, 2015-07-21 at 15:12 +0530, abhishek jain wrote: > Hi Team > > I'm facing following error while running libvirt on ppc platfrom with > cpu model as e5500.. > > 2015-07-15 06:30:37.307+0000: 3976: warning : virQEMUCapsInit:1001 : > Failed to get host CPU > 2015-07-15 06:30:37.642+0000: 3976: error : virFirewallApply:936 : > out of memory > 2015-07-15

Hi Andrea Thanks for the reply. Below is some more information regarding the same.. uname -a Linux t1040rdb 3.12.37-rt51-QorIQ-SDK-V1.8+gf488de6 #2 SMP Mon Jul 20 14:43:02 IST 2015 ppc GNU/Linux libvirtd --version libvirtd (libvirt) 1.2.13 cat /usr/share/libvirt/cpu_map.xml </arch> <arch name='ppc64'> <model name='POWERPC_e5500'> <vendor

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