similar to: Reclocking support for NVA0

In bulletpoints: - Add some support for G94 and G96 reclocking. Has been tested on literally two cards, which is hardly adequate as "full coverage". On the other hand, the changes were small enough to make me confident this might work for others as well. - Fix NV50 wait for VBLANK when no monitor is plugged in. - Voltage related inprovements for GT21x. - Slightly improve Keplers

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/ramcfg.h | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/bios/rammap.c | 3 ++- drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c | 2 ++ drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c | 6 ++++-- 4 files changed, 9 insertions(+), 3 deletions(-) diff --git

Following a series of patches that implement memory reclocking for NVA3/5/8 with DDR2, DDR3 and GDDR3 on board. I tested these patches on 6 different graphics cards, but I expect reclocking now to work on many more. Testers can pick up these patches and test it by enabling pstate (nouveau.pstate=1). They should then be able to change clocks by writing to /sys/class/drm/card0/device/pstate. Correct

Patch 1 fixes nva3 bailing due to not finding the right ramcfg Patch 2 is a resend rebased on 3.17.0-rc4 for setting the vblank period Patch 3-5 handle writes to per-partition registers, for which NVA3 does not have special broadcast regs available. Patch 6 removes local structs from NVA3 reclocking in favour of the already existing "ram->base." variables, like in NVE0 As always,

Hello, Attached a small patch that correctly identifies the DLLoff bit for >=GF100. Marked RFC because I haven't seen any GDDR5 samples that *enable* the DLL. I'd like to verify whether the DLL should be reset when enabled. Could increase likelihood of succesfull reclock. Ben: could you do some experiments with this bit to see if GDDR5 needs some DLL reset logic? Thanks, and happy

Two patches went missing as a result of PEBCAK. No v2 marks as nothing changed really. Just resending for easier enforcement of patch order in other people's trees. Sorry for the noise. Original message: No, no, these will not implement Fermi reclocking. This set of patches contains some of the preparatory work that I deem stable enough to move upstream. Notable changes - Training pattern

Patch 1 and 2 implement wait-for-vblank, required to remove flicker when reclocking memory Patch 3 and 4 allow me to do things between waiting for VBLANK and disabling FB, like pause PFIFO and wait for the engines to idle. This minimises the time PFIFO is paused, thus maximises performance. The rest of the patches speak for themselves. As the actual memory reclocking script is still somewhat prone

No, no, these will not implement Fermi reclocking. This set of patches contains some of the preparatory work that I deem stable enough to move upstream. Notable changes - Training pattern upload routines from GK104+ now shared with GT215+ - Timing calculation for Fermi - GDDR5 MR calculation from VBIOS timing table v1.0. Also useful for that pesky GT 240. - A routine to translate a VBIOS init

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/nvkm/subdev/bus/hwsq.h | 44 ++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/hwsq.h b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/hwsq.h index 3394a5e..ebf709c 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/hwsq.h +++

Sometimes boot scripts leave the "DLL reset" bit on, but it shouldn't be set on every MR write. V2 addresses this by forcing DLL reset off in MR generation

Hi, Static Analysis with CoverityScan as detected an issue with the setting of the RON pull value in function nvkm_gddr3_calc in drm/nouveau/bios/ramcfg.c This was introduced by commit: c25bf7b6155cb ("drm/nouveau/bios/ramcfg: Separate out RON pull value") CoverityScan reports the issue as follows: 84 case 0x20: 85 CWL = (ram->next->bios.timing[1] &

Fix typo introduced when converting to core infrastructure. Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin at mentor.com> --- drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c b/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c index 5fcce5d..ad577db 100644 ---

On 12/01/2016 05:48 AM, Karol Herbst wrote: > v2: Set entry to 0xff if not found > Add cap entry for ver 0x30 tables > Rework to fix memory leak > v3: More error checks > Simplify check for invalid entries > > Signed-off-by: Karol Herbst <karolherbst at gmail.com> > --- > .../include/nvkm/subdev/bios/power_budget.h | 25 +++++ >

From: Markus Elfring <elfring at users.sourceforge.net> Date: Wed, 21 Sep 2016 09:09:09 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Use kmalloc_array() in nvbios_iccsense_parse() Use kmalloc_array() in gt215_link_train() Delete unnecessary braces Adjust a kzalloc() call in gt215_ram_new() Add space after an

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Hope I understood you correctly wrt the mem exec stuff. nvkm/subdev/fb/ramnv50.c | 2 +- nvkm/subdev/fb/ramnva3.c | 2 +- nvkm/subdev/fb/ramnvc0.c | 2 +- nvkm/subdev/fb/ramnve0.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/nvkm/subdev/fb/ramnv50.c b/nvkm/subdev/fb/ramnv50.c index ef91b6e..e5d12c2 100644

https://bugs.freedesktop.org/show_bug.cgi?id=91523 Bug ID: 91523 Summary: [NVE7] driver cannot initialize gpu(failed to parse ramcfg data) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium

There is an optinal header field in the power budget table we can use to read out the power cap of the GPU. We should have this in the kernel before actually using it to catch errors and see how reliable this is, but as it seems it works on all GPUs as expected on Kepler und Maxwells with the power cap field set in the vbios. This series keeps things really simple for now until we figure out

Here's a quick-but-I-guess-tidy-fix for faulty behaviour someone reported in NVAF. I'm just not sure if the check for nvaa/nvac should still be in nv50_pm_clocks_pre... I believe this is wrong as they can reclock perfectly well (except the non-existing memory). Anyone has a definite answer to that?

There is an optinal header field in the power budget table we can use to read out the power cap of the GPU. We should have this in the kernel before actually using it to catch errors and see how reliable this is, but as it seems it works on all GPUs as expected on Kepler und Maxwells with the power cap field set in the vbios. This series keeps things really simple for now until we figure out

There is an optinal header field in the power budget table we can use to read out the power cap of the GPU. Sadly it is optional and if that field isn't sad, things beome complicated. Anyhow, this is good enough for most cards and we can use it later for capping the power consumption of the GPUs, but first, just export those values through hwmon. First design, will change stuff, want