similar to: pwr/macros: Stop playing Russian roulette on data memory

On Sun, Aug 3, 2014 at 1:15 AM, Roy Spliet <rspliet at eclipso.eu> wrote: > This patch fixes the pwr firmware to play nicely at least on NVA3. Because Martin might send more patches soon, I didn't include a regenerated nvXX.fuc.h. To me it makes more sense if all patches are merged then, and a final patch regenerates the headers in one go. Of course, I did test this patch and found it

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

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,

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

This should probably be folded into the previous patch to avoid breaking bisectability on nve0 On Thu, Sep 4, 2014 at 10:58 AM, Roy Spliet <rspliet at eclipso.eu> wrote: > This used to be done implicitly > > Signed-off-by: Roy Spliet <rspliet at eclipso.eu> > --- > drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c | 5 +++++ > 1 file changed, 5 insertions(+) >

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

this series makes use of the load counters we can use to get information about the current load of the gpu. This series includes the needed pmu bits and a debugfs interface to read them out. Currently the values are between 0 and 255, because it is much easier to implement it this way on the pmu. Karol Herbst (4): subdev/pmu/fuc: add gk104 pmu/fuc: add macros for pdaemon pwr counters

Adds reclocking for NVA0, and a whole lot of work for other cards. Had these patches collecting dust for a little, but tested them with both my NVA0, and Martin's a while back. Success not guaranteed, but should be quite a leap forward. Happy reviewing and testing. Cheers, Roy

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

There might be some callers of nouveau_clock_astate(), and they are from inetrrupt context. So we must ensure that this function can be atomic in that condition. This patch adds one parameter which is subsequently passed to nouveau_pstate_calc(). Therefore we can choose whether we want to wait for the pstate work's completion or not. Signed-off-by: Vince Hsu <vinceh at nvidia.com> ---

From: Martin Peres <martin.peres at labri.fr> --- nvkm/subdev/pwr/fuc/kernel.fuc | 13 +++++++++++++ nvkm/subdev/pwr/fuc/nv108.fuc.h | 25 +++++++++++-------------- nvkm/subdev/pwr/fuc/nva3.fuc.h | 23 ++++++++++------------- nvkm/subdev/pwr/fuc/nvc0.fuc.h | 23 ++++++++++------------- nvkm/subdev/pwr/fuc/nvd0.fuc.h | 23 ++++++++++------------- 5 files changed, 54 insertions(+), 53

From: Karol Herbst <git at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc index c5ec61f..86b8fd4 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc @@ -66,6

So, I've spent the last few days messing around with replacing our use of NVIDIA's context programs on GeForce 6/7 hardware and have something that works on the 4 (2xNV44, NV46, NV4B) cards I have. The context programs are *much* less complex than NVIDIA's and don't handle nearly everything NVIDIA's do, however they do work for our needs, and it's as good a starting point

Hi all, I'm having trouble getting access to the pwr. This is on Ubuntu Lucid Lynx, 64 bit. I'm installing pwr via packages.install('pwr'), and loading it via library(pwr), both of which appear successful. Strangely, I never get access to the pwr object in R. I tried installing it to /usr/local/lib/R/site-library and ~/R/x86_64-pc-linux-gnu-library. I also tried installing it

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

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

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

Needs to be done after wait-for-VBLANK, and NVA3 requires register writes in between. Rather than hard-coding register writes, just split out fb_disable and fb_enable. Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/core/include/subdev/pwr.h | 2 ++ drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h | 14 ++++++++++++++