similar to: nouveau GSP fixes

From: Dave Airlie <airlied at redhat.com> The upper layer transfer functions expect EBUSY as a return for when retries should be done. Fix the AUX error translation, but also check for both errors in a few places. Fixes: eb284f4b3781 ("drm/nouveau/dp: Honor GSP link training retry timeouts") Signed-off-by: Dave Airlie <airlied at redhat.com> ---

From: Dave Airlie <airlied at redhat.com> eb284f4b3781 drm/nouveau/dp: Honor GSP link training retry timeouts tried to fix a problem with panel retires, however it appears the auxch also needs the same treatment, so add the same retry wrapper around it. This fixes some eDP panels after a suspend/resume cycle. Fixes: eb284f4b3781 ("drm/nouveau/dp: Honor GSP link training retry

I've recently been seeing some unexplained GSP errors on my RTX 6000 from failed aux transactions: [ 132.915867] nouveau 0000:1f:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff While the cause of these is not yet clear, these messages made me notice that the aux transactions causing these transactions were succeeding - not failing. As it turns out, this

Hi folks: Here is the leftover of the previous spin of NVKM GSP RPC fixes, which is handling the return of large GSP message. PATCH 1 and 2 in the previous spin were merged [1], and this spin is based on top of PATCH 1 and PATCH 2 in the previous spin. Besides the support of the large GSP message, kernel doc and many cleanups are introduced according to the comments in the previous spin [2].

Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- v2: rebased to drm-misc-next

Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 1 +

Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- Notes: v2: added get/put_device calls

Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> v2: added get/put_device calls ---

Hello Ben Skeggs, The patch 176fdcbddfd2: "drm/nouveau/gsp/r535: add support for booting GSP-RM" from Sep 19, 2023 (linux-next), leads to the following Smatch static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1016 r535_gsp_rpc_unloading_guest_driver() warn: 'rpc' isn't an ERR_PTR drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c 1010 static int

Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 1 +

Fake flexible arrays (zero-length and one-element arrays) are deprecated, and should be replaced by flexible-array members. So, replace zero-length array with a flexible-array member in `struct PACKED_REGISTRY_TABLE`. Also annotate array `entries` with `__counted_by()` to prepare for the coming implementation by GCC and Clang of the `__counted_by` attribute. Flexible array members annotated with

On 11/7/23 15:34, Dan Carpenter wrote: > Hello Ben Skeggs, > > The patch 176fdcbddfd2: "drm/nouveau/gsp/r535: add support for > booting GSP-RM" from Sep 19, 2023 (linux-next), leads to the > following Smatch static checker warning: > > drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1016 r535_gsp_rpc_unloading_guest_driver() > warn: 'rpc' isn't an

The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers that have printf-like logs from GSP-RM and PMU encoded in them. LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA addresses are passed to GSP-RM during initialization. The buffers are required for GSP-RM to initialize properly. LOGPMU is also allocated by Nouveau, but its contents are updated when Nouveau

The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers that have printf-like logs from GSP-RM and PMU encoded in them. LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA addresses are passed to GSP-RM during initialization. The buffers are required for GSP-RM to initialize properly. LOGPMU is also allocated by Nouveau, but its contents are updated when Nouveau

On 11/7/23 20:00, Danilo Krummrich wrote: > On 11/7/23 15:34, Dan Carpenter wrote: >> Hello Ben Skeggs, >> >> The patch 176fdcbddfd2: "drm/nouveau/gsp/r535: add support for >> booting GSP-RM" from Sep 19, 2023 (linux-next), leads to the >> following Smatch static checker warning: >> >> ????drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1016

Add the NVreg_RegistryDwords command line parameter, which allows specifying additional registry keys to be sent to GSP-RM. This allows additional configuration, debugging, and experimentation with GSP-RM, which uses these keys to alter its behavior. Note that these keys are passed as-is to GSP-RM, and Nouveau does not parse them. This is in contrast to the Nvidia driver, which may parse some

From: Dave Airlie <airlied at redhat.com> These can happen in normal operations esp with auxch transactions. Gets rid of nouveau 0000:01:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff in logs. Cc: Lyude <lyude at redhat.com> Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 2 +- 1 file

Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup: kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03

From: Dave Airlie <airlied at redhat.com> This aligns with what open gpu does, the 0x15 hex is just to trick you. Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c

This should let the upper layers retry as needed on EAGAIN. There may be other values we will care about in the future, but this covers our present needs. Signed-off-by: Dave Airlie <airlied at redhat.com> --- .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 26 +++++++++++++++---- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c