similar to: [PATCH] pmu: remove reset() hook

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

Have an instance of nvkm_falcon in the PMU structure, ready to be used by other subdevs (i.e. secboot). Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/subdev/pmu.h | 2 ++ drm/nouveau/nvkm/subdev/pmu/base.c | 4 ++++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drm/nouveau/include/nvkm/subdev/pmu.h

I think I am done reworking the series and getting to a point where I think it is basically finished. The configuration of the slots could be improved later on when working on dynamic reclocking, but for now it's good enough to report the current GPU utilization to userspace. Patches 1-4 imeplement PMU commands to setup and readout the counters. Patches 5-6 lets Nouveau make use of 1-4. Patch

reworked this series quite a lot. Now we want the Host to configure the counters through the PMU. The series isn't complete though because it needs: 1. reordering 2. better commit messages but I felt like sending those out before doing a final version. I also found some weird register overwriting issue on the PMU I have to track down, because it interfers with the counter read out. I am

Fixes failure to compile with recent envyas as a result of the 'movw' alias being removed for v5. A bit of history: v3 only has a 16-bit sign-extended immediate mov op. In order to set the high bits, there's a separate 'sethi' op. envyas validates that the value passed to mov(imm) is between -0x8000 and 0x7fff. In order to simplify macros that load both the low and high word,

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

From: Karol Herbst <git at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 788 +++++++++++++++------------ drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4.h | 740 ++++++++++++++----------- drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4.h | 740 ++++++++++++++----------- drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 710 ++++++++++++++----------

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

Fixes failure to compile with recent envyas as a result of the 'movw' alias being removed for v5. A bit of history: v3 only has a 16-bit sign-extended immediate mov op. In order to set the high bits, there's a separate 'sethi' op. envyas validates that the value passed to mov(imm) is between -0x8000 and 0x7fff. In order to simplify macros that load both the low and high word,

fixes compilation issues with recent envytools, because movw was removed from fuc5, because it doesn't exist there anymore. The current code is most likely broken for fuc5 hardware as well and might have triggered all kinds of random memory reclocking fails. Changes in fuc3 binaries are tue do opcode optimizations using shorter opcodes when possible. Signed-off-by: Karol Herbst <kherbst

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

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

From: Karol Herbst <git at karolherbst.de> --- drm/nouveau/include/nvif/device.h | 1 + drm/nouveau/include/nvkm/subdev/pmu.h | 10 ++++++++++ drm/nouveau/nouveau_debugfs.c | 23 +++++++++++++++++++++++ drm/nouveau/nvkm/subdev/pmu/base.c | 18 ++++++++++++++++++ 4 files changed, 52 insertions(+) diff --git a/drm/nouveau/include/nvif/device.h

From: Karol Herbst <git at karolherbst.de> v2: optimize macro and fixed data array type --- drm/nouveau/include/nvif/device.h | 1 + drm/nouveau/include/nvkm/subdev/pmu.h | 10 ++++++++++ drm/nouveau/nouveau_debugfs.c | 23 +++++++++++++++++++++++ drm/nouveau/nvkm/subdev/pmu/base.c | 18 ++++++++++++++++++ 4 files changed, 52 insertions(+) diff --git

From: Karol Herbst <git at karolherbst.de> v2: optimize macro and fixed data array type v3: fix bug I added in the last version --- drm/nouveau/include/nvif/device.h | 1 + drm/nouveau/include/nvkm/subdev/pmu.h | 10 ++++++++++ drm/nouveau/nouveau_debugfs.c | 23 +++++++++++++++++++++++ drm/nouveau/nvkm/subdev/pmu/base.c | 18 ++++++++++++++++++ 4 files changed, 52

on gk208+ we can simply mov 32bits, so we should have a single mov there Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 1598 +++++++++++------------ drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4.h | 1494 +++++++++++----------- drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 1424 ++++++++++-----------

On Mon, Oct 26, 2015 at 2:13 PM, Karol Herbst <nouveau at karolherbst.de> wrote: > From: Karol Herbst <git at karolherbst.de> > > --- > drm/nouveau/include/nvif/device.h | 1 + > drm/nouveau/include/nvkm/subdev/pmu.h | 10 ++++++++++ > drm/nouveau/nouveau_debugfs.c | 23 +++++++++++++++++++++++ > drm/nouveau/nvkm/subdev/pmu/base.c | 18

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

- 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 by reporting Perf counters. 3.Be critical for GPU

I encountered while stresstesting the reclocking code, that rarely (1 out of 20.000+ requests) we don't get any IRQ in nvkm_pmu_intr. This means we have a queued message on the pmu, but nouveau doesn't read it and waits infinitely in nvkm_pmu_send: if (reply) { wait_event(pmu->recv.wait, (pmu->recv.process == 0)); therefore let us use wait_event_timeout with a 1s timeout frame