similar to: [PATCH] drm/nouveau/fifo/gk104-: Silence a locking warning

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

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

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

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

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

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

A channel may still be processed by the PBDMA even after removal, unless it is properly kicked. Some chips are more sensible to this than others, with GM20B triggering the issue very easily (the PBDMA will try to fetch methods from the previously-removed channel after a new one is added). Make sure this cannot happen by kicking the channel right after it is disabled, and before the new runlist is

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

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

This reverts commit 1addc1264852 This commit seems to cause crashes in gk104_fifo_intr_runlist() by returning 0xbad0da00 when register 0x2a00 is read. Since this commit was intended for GM20B which is not completely supported yet, let's revert it for the time being. Reported-by: Eric Biggers <ebiggers3 at gmail.com> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> ---

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

On (06/14/19 11:50), Sergey Senozhatsky wrote: > dmesg > > nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon > nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery > nouveau 0000:01:00.0: fifo: channel 5: killed > nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery >

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

On Tue, Mar 01, 2016 at 04:59:05PM +0900, Alexandre Courbot wrote: > > Eric, since you reported the regression on the first version, would you mind trying > this one and giving us your Tested-by? I have tested it on dGPU but unfortunately > could not set it up in an optimus-like manner, with power management kicking in. > Thanks. I've tested Linux 4.5-rc6 with your patch

On Wed, Mar 2, 2016 at 12:53 PM, Eric Biggers <ebiggers3 at gmail.com> wrote: > On Tue, Mar 01, 2016 at 04:59:05PM +0900, Alexandre Courbot wrote: >> >> Eric, since you reported the regression on the first version, would you mind trying >> this one and giving us your Tested-by? I have tested it on dGPU but unfortunately >> could not set it up in an optimus-like

On Wed, Mar 2, 2016 at 6:07 PM, Alexandre Courbot <gnurou at gmail.com> wrote: > On Wed, Mar 2, 2016 at 12:53 PM, Eric Biggers <ebiggers3 at gmail.com> wrote: >> On Tue, Mar 01, 2016 at 04:59:05PM +0900, Alexandre Courbot wrote: >>> >>> Eric, since you reported the regression on the first version, would you mind trying >>> this one and giving us your

On Mon, Mar 07, 2016 at 11:10:16AM +0900, Alexandre Courbot wrote: > > Hi Eric, just to follow up - are you still happy with this patch? Yes, I still haven't had any problems with it.

On Mon, Mar 7, 2016 at 11:32 AM, Eric Biggers <ebiggers3 at gmail.com> wrote: > On Mon, Mar 07, 2016 at 11:10:16AM +0900, Alexandre Courbot wrote: >> >> Hi Eric, just to follow up - are you still happy with this patch? > > Yes, I still haven't had any problems with it. Awesome. Clear to add your Tested-by?

2015-08-12 16:37 GMT+09:00 Afzal Mohammed <afzal.mohd.ma at gmail.com>: > Hi, > > On Wed, Aug 12, 2015 at 04:12:15PM +0900, Alexandre Courbot wrote: > >> Could you let me know what your card is? It may be useful to know the >> range of affected cards when trying to fix this. > > grep of nouveau on dmesg as follows, if the following information is > not