similar to: MEMX improvements + DDR 2/3 MR generation

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,

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> ---

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 ++++++++++++++

On Fri, Sep 5, 2014 at 12:58 AM, Roy Spliet <rspliet at eclipso.eu> wrote: > Solves blinking on reclocking memory. The value set is an underestimate, but with non-reduced vblanking this should give us plenty of time Hey Roy, I've merged all (squashed the kepler change into the commit where it's needed too) except this patch, which needs to be rebased on top of 3.17-rc.

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

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

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 | 16 ++ drivers/gpu/drm/nouveau/core/subdev/fb/ramnva3.c | 318 +++++++++++++++++++-- .../gpu/drm/nouveau/core/subdev/pwr/fuc/memx.fuc | 111 +++++++ drivers/gpu/drm/nouveau/core/subdev/pwr/fuc/os.h | 5 +

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

Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression spotted on several G94 (FDObz #85160). This device seems to expect the vblank period to be set after setting scale instead of before. V2: shove this in a separate function This is a candidate bug-fix for 3.18 Signed-off-by: Roy Spliet <rspliet at eclipso.eu> Tested-by: Zlatko Calusic <zcalusic at bitsync.net>

On Fri, Oct 31, 2014 at 8:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Thu, Oct 30, 2014 at 5:57 PM, Roy Spliet <rspliet at eclipso.eu> wrote: >> Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression spotted >> on several G94 (FDObz #85160). This device seems to expect the vblank period to > > I believe that's often done as a >

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

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

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

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

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 to work as intended, so feel free to pick up as you please.

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 12/22/2014 05:11 PM, Vince Hsu wrote: > The platform device does not use the common nouveau_pwr_init() to initialize > the PWR, but it does need the .prob() be assigned to avoid NULL pointer > dereference in graph/nve4.c. s/prob/pgob/ :-( Will fix in next version. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > > v2: this patch is added since v2. (v1

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

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