similar to: [PATCH V2] pmu/gk20a: PMU boot support.

It adds PMU boot support.It loads PMU firmware into PMU falcon.RM/Kernel driver receives INIT ack (through interrupt mechanism) from PMU when PMU boots with success. Signed-off-by: Deepak Goyal <dgoyal at nvidia.com> --- drm/nouveau/include/nvkm/subdev/pmu.h | 26 +- drm/nouveau/nvkm/subdev/pmu/base.c | 108 ++ drm/nouveau/nvkm/subdev/pmu/gk20a.c | 2131

Hi Deepak, There's... a lot of stuff going on here. Can you describe the goal of this patch (which could then be used as the patch commit message)? The current one basically boils down to "Add support for loading PMU", but merely loading the fw into a fuc engine is just a handful lines of code. Also, except in rare cases, it's customary to split up patches of this size into

From: Deepak Goyal <dgoyal at nvidia.com> - Maps PMU firmware into PMU virtual memory. - Copy bootloader into PMU memory and start it. - Allow the PMU to interact with HOST via interrupts. PMU after successful configurations (to follow after this patch) will: 1.Autonomously power gate graphics engine when not in use.It will save us a lot of power. 2.Provide better way to scale frequencies

Hi Mirkin, Your observations are quiet correct. After the boot code is submitted successfully, I will submit the code to configure & enable features of PMU.(This will be done by sending cmds to PMU). Now talking about this patch: Apart from just the boot code, I have also included some things in this patch that I can remove for now(I will include these things in later digestible chunks): -

On 13 April 2015 at 20:42, Alexandre Courbot <acourbot at nvidia.com> wrote: > Ben, I guess our main remaining concern with this patch is how it should > integrate wrt. the existing PMU code. Since it is designed to interact with > the NVIDIA firmware, maybe we should use a different base code, or do you > think we can somehow share code and data structures? Hey Alexandre, Sorry

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---

Add a PMU constructor so implementations that extend the nvkm_pmu structure can have all base members properly initialized. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/pmu/base.c | 21 +++++++++++++++------ drm/nouveau/nvkm/subdev/pmu/priv.h | 2 ++ 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pmu/base.c

Two trivial PMU-related fixes for Tegra: - Add a dummy func member to GK20A, since nvkm_pmmu_pgob() unconditionally dereferences it - Check whether a PMU actually exists before calling nvkm_pmmu_pgob(). During early bringup we are likely to not have a PMU Alexandre Courbot (2): pmu/gk20a: add dummy func gr/gf100: do not assume a PMU is present drm/nouveau/nvkm/engine/gr/gf100.c | 3 ++-

This was the first step of the secure boot refactoring - as Ben asked for some fixes, I now submit it as its own series to make it easier to review (and also because rebasing secure boot on top of this takes time and I don't want to do it until this is validated!). This series attempts to factorize the duplicate falcon-related code into a single library, using the existing nvkm_falcon

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

GK20A's timer is directly attached to the system timer and cannot be calibrated. Skip the calibration phase on that chip since the corresponding registers do not exist. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git

GK20A's timer is directly attached to the system timer and cannot be calibrated. Skip the calibration phase on that chip since the corresponding registers do not exist. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > GK20A's timer is directly attached to the system timer and cannot be > calibrated. Skip the calibration phase on that chip since the > corresponding registers do not exist. Just a curiosity: What timer resolution does the HW initialise at? > > Signed-off-by: Alexandre Courbot <acourbot

The various register access wrappers in nouveau_hw.h are so noisy when drm.debug > 0, that some of them can overflow the kernel message buffer. Add nouveau.ko parameter 'reg_debug', a bitmask that enables each of the wrapper debug messages individually. By default, nothing is printed. Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_drv.c | 6

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

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 +

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

The hdmi device is required for runtime pm. However it is not available on many esp older devices, which were all seeing these error messages. Take this opportunity to also convert to nv_debug instead of the DRM_* messages, like the rest of nouveau does. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 11 +++++------ 1 file changed, 5

From: Martin Peres <martin.peres at labri.fr> This patchset is mostly about fixing fdo bug #66177, reported by Dash Four. This bug is about fan/temp management not working after a suspend/resume cycle. Fan/therm management relies on ptimer's alarm feature to call periodically multiple callbacks that poll the temperature and update the fan speed if needed. The problem is that there is