similar to: [PATCH 0/2] PMU communications improvements

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

I hit this while loop in an error state of the gpu v2: unlock mutex only if reply == true Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/base.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pmu/base.c b/drm/nouveau/nvkm/subdev/pmu/base.c index 81a5583..eb248fd 100644 ---

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

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

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

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

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: Colin Ian King <colin.king at canonical.com> Currently the uninitialized values in the array reply are printed out when exec is false and nvkm_pmu_send has not updated the array. Avoid confusion by only dumping out these values if they have been actually updated. Detected by CoverityScan, CID#1271291 ("Uninitialized scaler variable") Fixes: ebb58dc2ef8c

- 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

This revision includes initial signed PMU firmware support for GM20B (Tegra X1). This PMU code will also be used as a basis for dGPU signed PMU firmware support. With the PMU code, the refactoring of secure boot should also make more sense. ACR (secure boot) support is now separated by the driver version it originates from. This separation allows to run any version of the ACR on any chip,

these are usually used for dynamic reclocking on gt215 and newer The counters are used to get the load of the core, memory, video and pcie loads currently I expose the loads through a debugfs "current_load" file, but I want to move that to nvif and just add a wrapper around that in debugfs for convenience Anyway there are still some issues I would like to discuss: 1. currently the

these are usually used for dynamic reclocking on gt215 and newer The counters are used to get the load of the core, memory, video and pcie loads currently I expose the loads through a debugfs "current_load" file, but I want to move that to nvif and just add a wrapper around that in debugfs for convenience. Using nvif would have the advantage, that userspace tools can easily get loads

this series makes use of the load counters we can use to get information about the current load of the gpu. This series includes the needed pmu bits and a debugfs interface to read them out. Currently the values are between 0 and 255, because it is much easier to implement it this way on the pmu. Karol Herbst (4): subdev/pmu/fuc: add gk104 pmu/fuc: add macros for pdaemon pwr counters

This is needed for using Nouveaus PMU image after performing secboot. This will be helpfull for Maxwell2 reclocking on boards without externally controlled fans like on most laptops or fanless boards. Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/nvkm/subdev/secboot/acr_r352.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git

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

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

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

I hit this while loop in an error state of the gpu Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/base.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pmu/base.c b/drm/nouveau/nvkm/subdev/pmu/base.c index fafbe2a..398b6a8 100644 --- a/drm/nouveau/nvkm/subdev/pmu/base.c +++

> Emil Velikov <emil.l.velikov at gmail.com> hat am 14. November 2015 um 23:44 > geschrieben: > > On 14 November 2015 at 19:51, Karol Herbst <nouveau at karolherbst.de> wrote: > > I hit this while loop in an error state of the gpu > > > > v2: unlock mutex only if reply == true > > > > Signed-off-by: Karol Herbst <nouveau at