similar to: [PATCH 0/4] Add pdaemon load counters

these are usually used for dynamic reclocking on gt215 and newer The counters are used to get the load of the core, memory, video and pcie loads currently I expose the loads through a debugfs "current_load" file, but I want to move that to nvif and just add a wrapper around that in debugfs for convenience. Using nvif would have the advantage, that userspace tools can easily get loads

these are usually used for dynamic reclocking on gt215 and newer The counters are used to get the load of the core, memory, video and pcie loads currently I expose the loads through a debugfs "current_load" file, but I want to move that to nvif and just add a wrapper around that in debugfs for convenience Anyway there are still some issues I would like to discuss: 1. currently the

reworked this series quite a lot. Now we want the Host to configure the counters through the PMU. The series isn't complete though because it needs: 1. reordering 2. better commit messages but I felt like sending those out before doing a final version. I also found some weird register overwriting issue on the PMU I have to track down, because it interfers with the counter read out. I am

I think I am done reworking the series and getting to a point where I think it is basically finished. The configuration of the slots could be improved later on when working on dynamic reclocking, but for now it's good enough to report the current GPU utilization to userspace. Patches 1-4 imeplement PMU commands to setup and readout the counters. Patches 5-6 lets Nouveau make use of 1-4. Patch

while trying out my pmu_counter patches on a gk208 gpu, I notived that the pmu is pretty much screwed up there. Karol Herbst (4): pmu/fuc: fix imm32 for gk208+ pmu/fuc: replace mov+sethi with imm32 pmu/fuc: call# seems to be broken on gk208 pmu/fuc: movw is somewhat weird on gk208, use mov instead drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 1598 +++++++++++------------

this series fixes the PMU on falcons v5 which fixes memory recklocking on kepler2 and would also allow us to enable memory recklocking on maxwell Karol Herbst (4): pmu/fuc: fix imm32 for gk208+ pmu/fuc: replace mov+sethi with imm32 pmu/fuc: use the call macro instead of using the call instruction directly pmu/fuc: use imm32 in ld/st macros

Re-use the therm-exported fan structure with only two minor modifications: - pwm_freq: u16 -> u32; - add fan_type (toggle or PWM) v2: - Do not memset the table to 0 as it erases the pre-set default values Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/include/subdev/bios/fan.h | 1 + drm/core/subdev/bios/fan.c | 1

From: Karol Herbst <git at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 788 +++++++++++++++------------ drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4.h | 740 ++++++++++++++----------- drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4.h | 740 ++++++++++++++----------- drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 710 ++++++++++++++----------

fixes compilation issues with recent envytools, because movw was removed from fuc5, because it doesn't exist there anymore. The current code is most likely broken for fuc5 hardware as well and might have triggered all kinds of random memory reclocking fails. Changes in fuc3 binaries are tue do opcode optimizations using shorter opcodes when possible. Signed-off-by: Karol Herbst <kherbst

on gk208+ we can simply mov 32bits, so we should have a single mov there Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 1598 +++++++++++------------ drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4.h | 1494 +++++++++++----------- drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 1424 ++++++++++-----------

Fixes failure to compile with recent envyas as a result of the 'movw' alias being removed for v5. A bit of history: v3 only has a 16-bit sign-extended immediate mov op. In order to set the high bits, there's a separate 'sethi' op. envyas validates that the value passed to mov(imm) is between -0x8000 and 0x7fff. In order to simplify macros that load both the low and high word,

From: Karol Herbst <git at karolherbst.de> we need this, because since kepler there is PCOPY2 and this is needed for the counters later in this series --- drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4 | 70 + drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4.h | 1795 ++++++++++++++++++++++++++ drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 1 + drm/nouveau/nvkm/subdev/pmu/gk104.c |

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

Fixes failure to compile with recent envyas as a result of the 'movw' alias being removed for v5. A bit of history: v3 only has a 16-bit sign-extended immediate mov op. In order to set the high bits, there's a separate 'sethi' op. envyas validates that the value passed to mov(imm) is between -0x8000 and 0x7fff. In order to simplify macros that load both the low and high word,

Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 882 +++++++++++++-------------- drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +- 2 files changed, 442 insertions(+), 442 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h b/drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h index 8a2b628..11179c1 100644 ---

Is this expected result for Chipset: G98 (NV98)? $ modinfo nvidia -F version 304.123 $ stat -c %s mmiotrace.log 134659197 $ file mmiotrace.log mmiotrace.log: ASCII text $ grep -i lost mmiotrace.log ; echo $? 1 $ ./envytools/rnn/demmio -f mmiotrace.log | perl -e 'open($fh409c, ">fuc409c"); open($fh409d, ">fuc409d"); open($fh41ac, ">fuc41ac");

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

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

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

On 26/02/16 17:19, Karol Herbst wrote: > currently there is no change, because nobody uses those macros yet, but they > shouldn't stay broken > > Signed-off-by: Karol Herbst <nouveau at karolherbst.de> > --- > drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git