linux-dev/drivers/gpu/drm/nouveau/nvkm/engine/fifo, branch master

drm/nouveau/ce/gv100-: move method buffer to ce ctx

2022-07-13T03:56:50Z

Didn't really know what this buffer was when initially implemented, but these days we do, so move it somewhere more appropriate. Signed-off-by: Ben Skeggs Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie

drm/nouveau/fifo: remove rd32/wr32 accessors from channels

2022-07-13T03:56:42Z

No need for these, we always map USERD to the client. Signed-off-by: Ben Skeggs Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie

drm/nouveau/fifo: rip out cevent, never used

2022-07-13T03:56:36Z

Signed-off-by: Ben Skeggs Reviewed-by: Lyude Paul Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie

drm/nouveau/fifo/gv100-: set gv100_fifo_runlist storage-class to static

2022-05-31T19:41:04Z

sparse reports drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c:56:1: warning: symbol 'gv100_fifo_runlist' was not declared. Should it be static? gv100_fifo_runlist is only used in gv100.c, so change it to static. Signed-off-by: Tom Rix Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20220528141836.4155970-1-trix@redhat.com

Merge drm/drm-next into drm-misc-next

2021-11-18T08:36:39Z

Backmerging from drm/drm-next for v5.16-rc1. Signed-off-by: Thomas Zimmermann

drm/nouveau/fifo: make tu102_fifo_runlist static

2021-11-12T22:46:05Z

Fix the following sparse warning: drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.c:53:1: warning: symbol 'tu102_fifo_runlist' was not declared. Should it be static? Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Signed-off-by: Ben Skeggs Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10

drm/nouveau/fifo: Reinstate the correct engine bit programming

2021-10-15T05:04:58Z

Commit 64f7c698bea9 ("drm/nouveau/fifo: add engine_id hook") replaced fifo/chang84.c g84_fifo_chan_engine() call with an indirect call of fifo/g84.c g84_fifo_engine_id(). The G84_FIFO_ENGN_* values returned from the later g84_fifo_engine_id() are incremented by 1 compared to the previous g84_fifo_chan_engine() return values. This is fine either way for most of the code, except this one line where an engine bit programmed into the hardware is derived from the return value. Decrement the return value accordingly, otherwise the wrong engine bit is programmed into the hardware and that leads to the following failure: nouveau 0000:01:00.0: gr: 00000030 [ILLEGAL_MTHD ILLEGAL_CLASS] ch 1 [003fbce000 DRM] subc 3 class 0000 mthd 085c data 00000420 On the following hardware: lspci -s 01:00.0 01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 880M] (rev a2) lspci -ns 01:00.0 01:00.0 0300: 10de:0a3c (rev a2) Fixes: 64f7c698bea9 ("drm/nouveau/fifo: add engine_id hook") Signed-off-by: Marek Vasut Cc: # 5.12+ Cc: Ben Skeggs Cc: Karol Herbst Cc: Lyude Paul Reviewed-by: Karol Herbst Reviewed-by: Ben Skeggs Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20211007214117.231472-1-marex@denx.de Signed-off-by: Dave Airlie

drm/nouveau/fifo/ga102: initialise chid on return from channel creation

2021-10-06T09:12:18Z

Turns out caller isn't zero-initialised after-all. Fixes: 49b2dfc08182 ("drm/nouveau/ga102-: support ttm buffer moves via copy engine") Reported-by: Karol Herbst Signed-off-by: Ben Skeggs Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210921090735.247236-1-skeggsb@gmail.com Signed-off-by: Maarten Lankhorst

drm/nouveau/ga102-: support ttm buffer moves via copy engine

2021-10-06T09:05:45Z

We don't currently have any kind of real acceleration on Ampere GPUs, but the TTM memcpy() fallback paths aren't really designed to handle copies between different devices, such as on Optimus systems, and result in a kernel OOPS. A few options were investigated to try and fix this, but didn't work out, and likely would have resulted in a very unpleasant experience for users anyway. This commit adds just enough support for setting up a single channel connected to a copy engine, which the kernel can use to accelerate the buffer copies between devices. Userspace has no access to this incomplete channel support, but it's suitable for TTM's needs. A more complete implementation of host(fifo) for Ampere GPUs is in the works, but the required changes are far too invasive that they would be unsuitable to backport to fix this issue on current kernels. v2: fix GPFIFO length in RAMFC (reported by Karol) Signed-off-by: Ben Skeggs Cc: Lyude Paul Cc: Karol Herbst Cc: # v5.12+ Reviewed-by: Karol Herbst Tested-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210916220406.666454-1-skeggsb@gmail.com Signed-off-by: Maarten Lankhorst

drm/nouveau: rip out nvkm_client.super

2021-08-18T09:00:15Z

No longer required now that userspace can't touch anything that might need it, and should fix DRM MM operations racing with each other, and the random hangs/crashes that come with that. Signed-off-by: Ben Skeggs Reviewed-by: Lyude Paul