similar to: [PATCH] clk: allow config option to enable reclocking

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

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

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

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

v2: Check for PFIFO, don't pause if it's not yet running. This should fix reclocking on boot Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nv50.c | 4 +- .../gpu/drm/nouveau/core/include/subdev/clock.h | 4 + drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c | 439

v2: Check for PFIFO, don't pause if it's not yet running. This should fix reclocking on boot v3: Tiny clean up Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nv50.c | 4 +- .../gpu/drm/nouveau/core/include/subdev/clock.h | 4 +

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

Add support for reclocking on GK20A, using a statically-defined pstates table. The algorithms for calculating the coefficients and setting the clocks are directly taken from the ChromeOS kernel. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 1 +

On Wed, Dec 10, 2014 at 5:53 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: > (This is a v3 of patch "drm/nouveau/fb/nv50: Add PFB writes") > > This fix a GPU lockup on 9400M (NVAC) when using acceleration, see > https://bugs.freedesktop.org/show_bug.cgi?id=27501 > > v2: > - Move code to subdev/fb/nv50.c as suggested by Roy Spliet; > - Remove arbitrary

On Thu, Dec 18, 2014 at 4:28 PM, Vince Hsu <vinceh at nvidia.com> wrote: > This patch creates a subdev for DVFS (Dynamic Voltage and Frequency Scaling) > support in Nouveau. This subdev refers to the status information provided by > the NVIDIA hardware and tries to adjust the performance level based on the > calculated target. Only the GK20A is supported right now. Hey Vince,

On Thu, Dec 18, 2014 at 8:13 PM, Vince Hsu <vinceh at nvidia.com> wrote: > Hello Ben, > > On 12/18/2014 05:34 PM, Ben Skeggs wrote: >> >> On Thu, Dec 18, 2014 at 4:28 PM, Vince Hsu <vinceh at nvidia.com> wrote: >>> >>> This patch creates a subdev for DVFS (Dynamic Voltage and Frequency >>> Scaling) >>> support in Nouveau. This

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

Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau_drm.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c index afb93bb..ffa1e4f 100644 --- a/drm/nouveau_drm.c +++ b/drm/nouveau_drm.c @@ -61,9 +61,10 @@ MODULE_PARM_DESC(debug, "debug string to pass to driver core"); static char

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.

Hello everyone, I would need testers to check that this patch doesn't break working NVAA/NVAC configurations. It fixes an issue where some NVAC would hang on boot; if similar issues exist on NVAA, it may fix them too. You will find the patch below in two different versions: one will apply on Ben Skeggs' repository, the other one will apply on a regular Linux tree. Thanks in advance,

This patch creates a subdev for DVFS (Dynamic Voltage and Frequency Scaling) support in Nouveau. This subdev refers to the status information provided by the NVIDIA hardware and tries to adjust the performance level based on the calculated target. Only the GK20A is supported right now. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/Kbuild | 2 +

i2c_bit_add_bus can call the pre_xfer function, which expects the func pointer to be set. Pass in func to the port creation logic so that it is set before i2c_bit_add_bus. See https://bugs.freedesktop.org/show_bug.cgi?id=68456 Reported-by: Hans-Peter Deifel <hpdeifel at gmx.de> Tested-by: Hans-Peter Deifel <hpdeifel at gmx.de> Signed-off-by: Ilia Mirkin <imirkin at

Hello Ben, On 12/18/2014 05:34 PM, Ben Skeggs wrote: > On Thu, Dec 18, 2014 at 4:28 PM, Vince Hsu <vinceh at nvidia.com> wrote: >> This patch creates a subdev for DVFS (Dynamic Voltage and Frequency Scaling) >> support in Nouveau. This subdev refers to the status information provided by >> the NVIDIA hardware and tries to adjust the performance level based on the

On 12/18/2014 11:25 AM, Ben Skeggs wrote: > On Thu, Dec 18, 2014 at 8:13 PM, Vince Hsu <vinceh at nvidia.com> wrote: >> Hello Ben, >> >> On 12/18/2014 05:34 PM, Ben Skeggs wrote: >>> On Thu, Dec 18, 2014 at 4:28 PM, Vince Hsu <vinceh at nvidia.com> wrote: >>>> This patch creates a subdev for DVFS (Dynamic Voltage and Frequency >>>>