similar to: NVA3 clock tree improvements

Re-resend of patch #7 to move the _post and _pre function prototypes to nva3.h

Resend of patch #7 to fix behaviour when failing to pause parts of the GPU

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c | 73 +++++++++++++++--------- drivers/gpu/drm/nouveau/core/subdev/clock/nva3.h | 2 +- drivers/gpu/drm/nouveau/core/subdev/fb/ramnva3.c | 2 +- 3 files changed, 48 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c

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

Second version of the gk20a clock patches. I have tried to keep the therm and volt devices mandatory in the clock driver, but unfortunately they are too tied to bios to allow this, at least for the moment. Consequently this version is mostly a port of the first version to Ben's tree. Ben, please let me know what I have done wrong in terms of integration to your tree, as the main purpose of

Reclocking of NVAA/NVAC is substantially different from NV50+, enough to justify a separate clock implementation. This code is a forward-port of reclocking code that has been sitting in a branch for a while, and has been tested on my NVAC. Traces show no significant reasons why this shouldn't work on NVAA, but testers are always welcome. And since these are IGPs without dedicated RAM to

Adds a NvReclock boolean option to allow the user to enable (or disable) reclocking. All chipsets default to off, except NVAA/NVAC, which are reportedly complete. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Ben, I know you've been saying that reclocking is in a pretty bad state, but I do think that there are going to be groups of people for whom the current code can work

This series adds support for reclocking on GK20A. The first two patches touch the clock subsystem to allow GK20A to operate, by making the presence of the thermal and voltage devices optional, and allowing pstates to be provided directly instead of being probed using the BIOS (which Tegra does not have). The last patch adds the GK20A clock device. Arguably the clock can be seen as a stripped-down

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

Hey Alex, Thanks. I have a couple of questions and remarks, but really, those should be treated as discussion points rather than anything else. Besides some inline comments, I was curious whether it is not necessary to pause PFIFO and the engines like done with at least NVA3-NVAF? Or is the transition smooth enough? op 10-07-14 09:34, Alexandre Courbot schreef: > Add support for

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- .../gpu/drm/nouveau/core/include/subdev/clock.h | 3 ++ drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c | 45 ++++++++++++++++++++++ drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c | 30 ++++----------- 3 files changed, 55 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h

V2: always call post correctly even if pre fails Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- .../gpu/drm/nouveau/core/include/subdev/clock.h | 3 ++ drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c | 52 +++++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c | 36 +++++---------- 3 files changed, 66 insertions(+), 25 deletions(-) diff --git

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,

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ Signed-off-by: Martin Peres <martin.peres at labri.fr> ---

On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: > > Adds a NvReclock boolean option to allow the user to enable (or disable) > reclocking. All chipsets default to off, except NVAA/NVAC, which are > reportedly complete. Hey Ilia, I think I've expressed my thoughts on this previously via IRC, but let me stick them here too so there's a record

From: Martin Peres <martin.peres at labri.fr> Some vbioses have extra useless entries after "the end" of the table. This is problematic since all of the vbios I found with this issue redefine the pwm freq divider to insane levels (52750 Hz instead of 2500), thus breaking fan management. The first solution to solve this mess would be to change the length of the table. The solution

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

On Wed, Jan 7, 2015 at 3:10 PM, Vince Hsu <vinceh at nvidia.com> wrote: > Hello Ben and Martin, > > Any comments for this series? Hey Vince, Ah sorry, I thought my comment on the other patch indicated I was fine with it. I'll merge them now so they don't get lost :) Thanks, Ben. > > Thanks, > Vince > > > On 12/22/2014 05:11 PM, Vince Hsu wrote: >>

Hi, This is a try to have some simple DVFS (Dynamic Voltage and Frequency Scaling) support for GK20A. Instead of relying on other existing frequency scaling framework, we create a simple subdev in Nouveau for the same purpose. That's because we don't want to make the DVFS implementation for GK20A far more than enough in the beginning and hinder the implementation for dGPU in the future.

Fixes regression introduced in commit 70790f4f "drm/nouveau/clock: pull in the implementation from all over the place" When code was moved from nv50_crtc_set_clock to nvc0_clock_pll_set, the PLLs it is used for got limited to only the first two VPLLs. nv50_crtc_set_clock was only called to change VPLLs, so it didn't limit what it was used for in any way. Since nvc0_clock_pll_set is