similar to: [PATCH] fifo/gk104: fix engine status register offset

From: Xia Yang <xiay at nvidia.com> Fix the channel id bit mask in FIFO schedule timeout error handling. FIFO_ENGINE_STATUS_NEXT_ID is bit 27:16 thus 0x0fff0000. FIFO_ENGINE_STATUS_ID is bit 11:0 thus 0x00000fff. Signed-off-by: Xia Yang <xiay at nvidia.com> Reviewed-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/engine/fifo/gk104.c | 4 ++-- 1 file

Hello, The Tegra GPU system software team has begun to align our new-chip development efforts with Nouveau. In particular we would like to arrive at a place where the Nouveau kernel driver code base is our primary development environment. To that end I'd like to add some "official" hardware reference headers to Nouveau. The headers are derived from the information we use

Signed-off-by: ZhiHu <huzhi001 at 208suo.com> --- .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index d8a4d773a58c..b99e0a7c96bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

not sure how i got signed up for this and i don?t see a way to unsubscribe. this is flooding my email with things i don?t care about. On Fri, Jul 14, 2023, at 1:14 AM, huzhi001 at 208suo.com wrote: > Signed-off-by: ZhiHu <huzhi001 at 208suo.com> > --- > .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- > 1 file changed, 29 insertions(+), 11 deletions(-)

Signed-off-by: ZhiHu <huzhi001 at 208suo.com> --- .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index d8a4d773a58c..b99e0a7c96bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

NAK - checkpatch.pl is a (strongish) guideline, but not a rule. In the cases corrected in the patch series here, we format the switch cases on single lines as it dramatically improves the readability of what is otherwise just a /long/ list of slightly different static mappings. I don't believe we're the only part of the kernel to do this either. On Fri, 2023-07-14 at 14:58 +0800, huzhi001

Hi there, Resending these now that they've had some more polish and testing, and I heard that Ben's vacation is over :-) These patches work as a starting point for more explicit error mechanisms and better robustness. At the moment, when a job hangs or faults, it seems that nouveau doesn't quite know how to handle the situation and often results in a hang. Some of these situations

This is an initial series of patches to improve channel recovery on Turing GPUs with the goal of improving reliability enough to eventually enable SVM for Turing. It's likely follow up patches will be required to fully address problems with less trivial workloads than what I have been able to test thus far. This series primarily addresses a number of hardware changes to interrupt layout and

Hi, I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' value read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' variable to be assigned the value 9, which is invalid; then wake_up() is called on an uninitialized waitqueue which causes the

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

Indeed, and I am actually surprised to see one here. I will double-check that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Alexandre, could you

smatch reports drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:33:18: warning: symbol 'nvkm_engn_cgrp_get' was not declared. Should it be static? nvkm_engn_cgrp_get is only used in runl.c, so it should be static Signed-off-by: Tom Rix <trix at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Mmm in that case it is probably best to revert that commit for the time being. It was targeting GM20B (and maybe other Maxwells too) so reverting it should not hurt anyone at the moment. I think Ben is on holidays for now, is there anyone else who can send a pull request to Dave Airlie for this? We don't want 4.2 to ship with a crash every other reboot... On Wed, Aug 12, 2015 at 10:01 AM,

Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system memory. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/engine/fifo/gf100.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/engine/fifo/gf100.c

this prevents double fini/init on engines and also fixes the "gr: fecs falcon already acquired by gr!" error I was seeing. RFC comment: not sure if this is the right solution, but it does fix the issue for me. And I guess if this is a valid approach older/newer chipset might need similiar fixes? Signed-off-by: Karol Herbst <kherbst at redhat.com> ---

For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the same way as NVC0, but with a couple of different values. Also make sure that the PPP engine is handled in the fifo/mc/vm. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It seems like VP4.0 is basically working here... only mpeg2/vc1 work, but I'm pretty sure that's just a user-side issue. My guess is

On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > 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

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

https://bugs.freedesktop.org/show_bug.cgi?id=99584 Bug ID: 99584 Summary: XVMC on nv43 class card broken with recent mesa + kernel. Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component:

We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no