similar to: [PATCH 00/12] drm/nouveau: support for GK20A, cont'd

Hi everyone, Way overdue v2 of the final patches that enable basic GK20A support. Hopefully all the issues raised with v1 have been addressed. Changes since v1: - Use gk20a clock driver by Ben instead of twiddling nv04's - Name new classes after gk20a instead of nvea - Addressed comments about BAR initialization code factorization - Removed non-essential code which only purpose was to avoid

Latest patches for GK20A, taking comments received for v3 into account. Changes since v3: - use only pfn_to_page() and page_to_pfn() in GK20A's FB. These functions are present on every arch and the physical address to page frame number conversion is also consistently a shift of PAGE_SHIFT. This part will probably be replaced by something nicer in the future anyway. - fixed a warning on

Changes since v2: - Enabled software class - Removed unneeded changes to nouveau_accel_init() - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with the portable page_to_phys()/phys_to_page() - Fixed incorrect comment/commit log talking about bytes instead of words Hope this looks good! Once this gets merged the next set will be to use this driver on Jetson and Venice2

Hello everyone, GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open

Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot: > Add a clumsy-but-working FB support for GK20A. This chip only uses system > memory, so we allocate a big chunk using CMA and let the existing memory > managers work on it. > > A better future design would be to allocate objects directly from system > memory without having to suffer from the limitations of a

Some BARs (like GK20A's) do not support being ioremapped write-combined. Add a boolean property to the BAR structure and handle that case in the Nouveau BO implementation. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/include/subdev/bar.h | 3 +++ drivers/gpu/drm/nouveau/nouveau_bo.c | 17 ++++++++++++----- 2 files changed, 15

On 6/27/14 8:56 PM, "Ben Skeggs" <skeggsb at gmail.com> wrote: >On Sat, Jun 28, 2014 at 4:51 AM, Ken Adams <KAdams at nvidia.com> wrote: >> quick note re: tegra and gpu bars... >> >> to this point we've explicitly avoided providing user-mode mappings due >>to >> power management issues, etc. >> looks to me like this would allow such

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

Some very trivial comments below: On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add support for initializing the priv ring of GK20A. This is done by the > BIOS on desktop GPUs, but needs to be done by hand on Tegra. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drivers/gpu/drm/nouveau/Makefile

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

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

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

We will use this subdev to disable temperature reading on cards that did not get a sensor calibration in the factory. Signed-off-by: Martin Peres <martin.peres at free.fr> --- configure.ac | 1 + drm/Kbuild | 4 ++ drm/core/include/subdev/fuse.h | 1 + drm/core/subdev/fuse/base.c | 1 + drm/core/subdev/fuse/g80.c | 1 +

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

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

--- drivers/gpu/drm/nouveau/core/include/subdev/ltcg.h | 7 + drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 55 +++++---- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 129 +++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/vm/nvc0.c | 58 +++++++++- 4 files changed, 220 insertions(+), 29 deletions(-) diff --git

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

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