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].

On Thu, Oct 31, 2024 at 01:52:37AM -0700, Zhi Wang wrote: > The name "repc" has different meanings in different contexts. > > To improve the readability, it's better to refine it to a name that > reflects what it actually represents. > > Rename "repc" to "gsp_rpc_len" in the GSP message recv path. Add an > section in the doc to explain the

No functional modification involved. drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:2174: warning: expecting prototype for create_debufgs(). Prototype was for create_debugfs() instead. Reported-by: Abaci Robot <abaci at linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=12292 Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com> ---

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 +

Hi Zhi, On Thu, Oct 31, 2024 at 01:52:36AM -0700, Zhi Wang wrote: > In order to explain the name clean-ups in GSP RPC routines, a kernel > doc to explain the memory layout and terms is required. > > Add a kernel doc to introduce the GSP RPC. Thanks for adding this -- very much appreciated! > > Signed-off-by: Zhi Wang <zhiw at nvidia.com> > --- >

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