similar to: [PATCH] drm/nouveau: fix bogus GPL-2 license header

https://bugs.freedesktop.org/show_bug.cgi?id=107874 Bug ID: 107874 Summary: Incorrect SPDX-License-Identifier on various nouveau drm kernel source files? Product: xorg Version: unspecified Hardware: Other OS: NetBSD Status: NEW Severity: normal Priority: medium

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,

It's supposed to always be 0, but at least nv_iowr() temporarily violates this. Since the ih touches $r0, it should be stored. Signed-off-by: Roy Spliet <rs855 at cam.ac.uk> --- drm/nouveau/nvkm/engine/gr/fuc/gpc.fuc | 2 + drm/nouveau/nvkm/engine/gr/fuc/gpcgf100.fuc3.h | 80 ++++---- drm/nouveau/nvkm/engine/gr/fuc/gpcgf117.fuc3.h | 82 ++++----

On Wed, Nov 1, 2017 at 12:51 PM, Karol Herbst <kherbst at redhat.com> wrote: > 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

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

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

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,

On 01/03/16 23:38, Ilia Mirkin wrote: > On Tue, Mar 1, 2016 at 4:36 PM, Martin Peres <martin.peres at free.fr> wrote: >> On 26/02/16 17:19, Karol Herbst wrote: >>> currently there is no change, because nobody uses those macros yet, but >>> they >>> shouldn't stay broken >>> >>> Signed-off-by: Karol Herbst <nouveau at

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

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

On Tue, Mar 1, 2016 at 4:36 PM, Martin Peres <martin.peres at free.fr> wrote: > On 26/02/16 17:19, Karol Herbst wrote: >> >> currently there is no change, because nobody uses those macros yet, but >> they >> shouldn't stay broken >> >> Signed-off-by: Karol Herbst <nouveau at karolherbst.de> >> --- >>

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

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

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

On 26/02/16 17:19, Karol Herbst wrote: > currently there is no change, because nobody uses those macros yet, but they > shouldn't stay broken > > Signed-off-by: Karol Herbst <nouveau at karolherbst.de> > --- > drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

for some reasons these calls don't really go there where they should go leading to various corruptions of the PMU state Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 12 ++++++------ drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc | 6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git

From: Kees Cook <keescook at chromium.org> [ Upstream commit 25feda6fbd0cfefcb69308fb20d4d4815a107c5e ] More arrays (and arguments) for dcpd were set to 16, when it looks like DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen with GCC 13: ../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp': ../include/linux/fortify-string.h:57:33:

More arrays (and arguments) for dcpd were set to 16, when it looks like DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen with GCC 13: ../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp': ../include/linux/fortify-string.h:57:33: warning: array subscript 'unsigned char[16][0]' is partly outside array bounds of 'u8[15]' {aka

The reset hook of pmu_func is never called, and gt215 was the only chip to implement. Remove this dead code. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/pmu/gt215.c | 9 --------- drm/nouveau/nvkm/subdev/pmu/priv.h | 2 -- 2 files changed, 11 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pmu/gt215.c b/drm/nouveau/nvkm/subdev/pmu/gt215.c index