similar to: [PATCH 0/5] Improve Robust Channel (RC) recovery for Turing

From: Thierry Reding <treding at nvidia.com> The purpose of BAR1 is primarily to make memory accesses coherent. However, some GPUs do not have BAR1 functionality. For example, the GV11B found on the Xavier SoC is DMA coherent and therefore doesn't need BAR1. Implement a variant of FIFO channels that work without a mapping of instance memory through BAR1. XXX ensure memory barriers are

The following functions are not declared outside of the file they are in, so make them static to avoid these warnings: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:745:1: warning: symbol 'gf100_gr_fecs_start_ctxsw' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:760:1: warning: symbol 'gf100_gr_fecs_stop_ctxsw' was not declared. Should it be

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

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

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

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

The offset should be 8 on Kepler and later. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/nouveau/nvkm/engine/fifo/gk104.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Hi, According to the header[1] the offset for engine status register is 8. [1] https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gk104/fifo.h Thanks, Vince diff --git

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

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

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

Changes since last sent: * add a patch to set the device into DRM_SWITCH_POWER_CHANGING state (can be dropped actually, I thought I was needing it, came up with a different approach and forgot to delete it, doesn't hurt though) * expose information about runtime suspending to nvkm so that we can run the pcie workaround only on runtime suspend Karol Herbst (8): pci: disable ASPM

smatch reports drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: symbol 'tu102_gr_load' was not declared. Should it be static? This function is not used so remove it. Signed-off-by: Tom Rix <trix at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for ?tu102_gr_load? [-Wmissing-prototypes] Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: ?tu102_gr_load? defined but not used [-Wunused-function] Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at ffwll.ch>

From: Arnd Bergmann <arnd at arndb.de> tu102_gr_load() is completely unused and can be removed to address this warning: drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype for 'nv50_display_create' Another patch was sent in the meantime to mark the function static but that would just cause a different warning about an unused function. Fixes: 1cd97b5490c8

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Lee Jones (15): drm/xlnx/zynqmp_disp: Use correct kerneldoc formatting in zynqmp_disp drm/xlnx/zynqmp_dp: Fix function name zynqmp_dp_link_train() -> zynqmp_dp_train() drm/vkms/vkms_composer: Fix a few different kerneldoc formatting

From: Dave Airlie <airlied at redhat.com> The fence code uses the total number of channel ids to allocate a bunch of memory for fencing. This is probably not the best way to do this, but it's hard to fix right now. The GSP code realises it can fit 8 channels into a USERD page, so it claims it can support 256 channels max, but it then allocates channel ids sparsely (0, 8, 16 etc). This

Presumably we can never actually hit this return, but static checkers complain that we should unlock before we return. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index 3a24788c3185..a7e55c422501 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

Turing introduced a new simplified page kind scheme, reducing the number of possible page kinds from 256 to 16. It also is the first NVIDIA GPU in which the highest possible page kind value is not reserved as an "invalid" page kind. To address this, the invalid page kind is made an explicit property of the MMU HAL, and a new table of page kinds is added to the tu102 MMU HAL. One