similar to: [PATCH] pci/g92: Fix rearm

one rename and one enable patch. Tested on hardware and confirmed with traces Karol Herbst (2): pci: Rename g94 to g92 pci/g92: Enable changing pcie link speeds drm/nouveau/include/nvkm/subdev/pci.h | 2 +- drm/nouveau/nvkm/engine/device/base.c | 22 +++++++++++----------- drm/nouveau/nvkm/subdev/pci/Kbuild | 2 +- drm/nouveau/nvkm/subdev/pci/{g94.c => g92.c} |

before we can let nouveau fully reclock the gpu automatically, we should have a fail safe mechanism to prevent the card from overheating. Starting with G84 GPUs the so called FSRM does the job and automatically downclocks the GPU when specific temperatures thresholds are hit. Lucky for us the needed bits are already configured through a script inside the vbios at POST time and we only need to

Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvkm/subdev/volt.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 17 +++++----- drm/nouveau/nvkm/subdev/volt/Kbuild | 1 + drm/nouveau/nvkm/subdev/volt/gf100.c | 59 ++++++++++++++++++++++++++++++++++ 4 files changed, 70 insertions(+), 8 deletions(-) create mode 100644

This adds support for enabling automatic clockgating on nvidia GPUs for Fermi and later generations. This saves a little bit of power, bringing my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my kepler's idle power consumption from ~23.6W to ~21.65W. Similar to how the nvidia driver seems to handle this, we enable clockgating for each engine that supports it after

Hi Lyude, thanks for the great work. Just a view comments inline. 2017-04-25 20:38 GMT+02:00 Lyude <lyude at redhat.com>: > This adds support for enabling automatic clockgating on nvidia GPUs for > Fermi and later generations. This saves a little bit of power, bringing > my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my > kepler's idle power

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1, referred to as "CG" throughout the driver. This is one of two powersaving levels that Kepler1 supports. This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after initializing the GPU fully nvkm_therm_clkgate_fini() -

Thanks for the work so far. A quick scan through the first NVC4 trace at hand, using upstream demmio, reveals at least 20 writes to the BLCG registers of PGRAPH and a few in PXBAR prior to altering the value of register 0x20200 (see below). We know that these are related to the clock gating you enable. Are you 110% sure that fiddling with 0x20200 bits without first setting these values can

On Wed, 2017-04-26 at 00:49 +0200, Karol Herbst wrote: > Hi Lyude, > > thanks for the great work. Just a view comments inline. > > 2017-04-25 20:38 GMT+02:00 Lyude <lyude at redhat.com>: > > This adds support for enabling automatic clockgating on nvidia GPUs > > for > > Fermi and later generations. This saves a little bit of power, > > bringing >

On Fri, Jan 26, 2018 at 4:35 AM, Lyude Paul <lyude at redhat.com> wrote: > This adds support for enabling automatic clockgating on nvidia GPUs for > Kepler1. While this is not technically a clockgating level, it does > enable clockgating using the clockgating values initially set by the > vbios (which should be safe to use). > > This introduces two therm helpers for

G92's seem to require some additional bit of initialization before the BSP engine can work. It feels like clocks are not set up for the underlying VLD engine, which means that all commands submitted to the xtensa chip end up hanging. VP seems to work fine though. This still allows people to force-enable the bsp engine if they want to play around with it, but makes it harder for the card to

On Fri, Nov 24, 2017 at 03:56:26AM +0100, Karol Herbst wrote: > 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. I suppose this could happen if the GPU raises an interrupt after the driver's already called free_irq() on it, and hence the driver can't rearm itself in the

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

On Fri, Nov 24, 2017 at 3:02 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Fri, Nov 24, 2017 at 03:56:26AM +0100, Karol Herbst wrote: >> 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. > > I suppose this could happen if the GPU raises an

https://bugs.freedesktop.org/show_bug.cgi?id=86794 Bug ID: 86794 Summary: Several nouveau related errors with xf86-video-nouveau with NVIDIA G92 [GeForce 9800 GT] and GF108 [GeForce GT 620] (rev a1). Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW

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

GF117 appears to use the same register as GK104 (but still with the general Fermi readout mechanism). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- v1 -> v2: split out different regid into separate file. .../drm/nouveau/include/nvkm/subdev/volt.h | 1 + .../gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-

See https://bugs.freedesktop.org/show_bug.cgi?id=74492 Reported-by: Ronald <ronald645 at gmail.com> Suggested-by: Marcin Ko?cielnicki <koriakin at 0x04.net> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nv40.c | 10 ++---

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