similar to: [PATCH 0/3] drm/gk20a: support for reclocking

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

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

This series does some refactoring in the GK20A's volt and clk drivers (fixing a few things while we are at it) to let GM20B benefit from the GK20A's logic with which it is compatible. GM20B is capable of more sophisticated (and power-efficient) reclocking which will follow later. Even after this more fancy reclocking is merged, the present logic will remain used in the lowest speedo of

This series adds support for GM20B PLL's Maxwell features, namely glitchless switch and (more importantly) DFS support. DFS lets the PLL lower its output speed according to input current variations, making the clock more stable and allowing it to run safely at lower voltage. All GM20B additions are done in the last patch, which consequently ends up being considerably big ; fortunately, it

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 +

Hello Vince, One minor question inline. Op 28-11-14 om 12:13 schreef Vince Hsu: > The voltage value are calculated by the hardware characterized > result. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > > Resend this patch with the fuse change and proper patch prefix > per Thierry's request. > > drm/Kbuild | 1 + >

Some Tegra drivers might be complied as kernel modules, and they need the fuse information for initialization. One example is the GK20A Nouveau driver. It needs the GPU speedo value to calculate frequency-voltage table. So export the tegra_sku_info. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- v2: add more description why we need this patch drivers/soc/tegra/fuse/fuse-tegra.c | 1

Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- nvkm/subdev/volt/base.c | 67 ++++++++++++++++++++++++++++--------------------- 1 file changed, 38 insertions(+), 29 deletions(-) diff --git a/nvkm/subdev/volt/base.c b/nvkm/subdev/volt/base.c index 32794a999106..26ccd8df193f 100644 --- a/nvkm/subdev/volt/base.c +++ b/nvkm/subdev/volt/base.c @@ -101,6 +101,41 @@ nouveau_volt_set_id(struct

Some Tegra drivers might be compiled as kernel modules, and they need the fuse information for initialization. One example is the GK20A Nouveau driver. It needs the GPU speedo value to calculate frequency-voltage table. So export the tegra_sku_info. Signed-off-by: Vince Hsu <vinceh at nvidia.com> Acked-by: Alexandre Courbot <acourbot at nvidia.com> Acked-by: Thierry Reding <treding

Hello Vince, Op 28-11-14 om 12:57 schreef Vince Hsu: > Hi Roy, > > On 11/28/2014 07:25 PM, Roy Spliet wrote: >> Hello Vince, >> >> One minor question inline. >> >> Op 28-11-14 om 12:13 schreef Vince Hsu: >>> The voltage value are calculated by the hardware characterized >>> result. >>> >>> Signed-off-by: Vince Hsu

Some Tegra drivers might be compiled as kernel modules, and they need the fuse information for initialization. One example is the GK20A Nouveau driver. It needs the GPU speedo value to calculate frequency-voltage table. So export the tegra_sku_info. Signed-off-by: Vince Hsu <vinceh at nvidia.com> Acked-by: Alexandre Courbot <acourbot at nvidia.com> Acked-by: Thierry Reding <treding

Hi Ben, On 07/11/2014 10:07 AM, Ben Skeggs wrote: > On Thu, Jul 10, 2014 at 5:34 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: >> 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

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

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

Hi Karol, I have some comments below. On 05:42 PM - Dec 01 2015, Karol Herbst wrote: > 0: disable boosting (cap to base clock from the vbios) > 1: boost only to boost clock from the vbios > 2: boost to max clock available > --- > drm/nouveau/include/nvkm/subdev/clk.h | 10 +++++++++- > drm/nouveau/nvkm/subdev/clk/base.c | 17 ++++++++++++++++- >

this series solves different issues we encounter on kepler cards while reclocking: 1. core clock doesn't change at all and produces a volting error (patch 1) this can happen when the voltage table has only 0ed values in the header so we have to parse the entries itself, which contain the right voltages 2. kepler won't clock to highest cstates (patch 2) this happens, because there are

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.

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

This series fixes most of the issues regarding volting on GPUs with any form of GPU Boost inside their vbios, which is mainly Kepler and newer, but we find some boosting related tables in Fermi vbios' already In the end reclocking should work on most Kepler cards without any issues Karol Herbst (19): bios/volt: handle voltage table version 0x50 with 0ed header volt: properly detect entry