similar to: [PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object

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> v2: added get/put_device calls ---

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

Hi Timur, On Mon, Jul 29, 2024 at 06:07:20PM -0500, Timur Tabi wrote: The patch looks great, just a few more nits below. > 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

On Mon, 2024-06-17 at 21:54 +0200, Danilo Krummrich wrote: Hi Timur, thanks for the follow-up on this patch series. On Wed, Jun 12, 2024 at 06:52:53PM -0500, Timur Tabi wrote: 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

On Tue, 2024-07-30 at 02:21 +0200, Danilo Krummrich wrote: > Hi Timur, > > > This method has the advantage that it allows the buffers to be parsed > > even when the logging ELF file is not available to the user. However, > > it has the disadvantage the debubfs entries need to remain until the > > debubfs -> debugfs Ok > > driver is unloaded. > >

[adding a bunch of list and people as well as Timur Tabi, who authored the culprit] Sid Pranjale, thx for the report. FWIW, I'm just replying to add this to the regression tracking to ensure it does not fall through the cracks. Nevertheless let me mention two things while at it: On 29.02.24 18:58, Sid Pranjale wrote: > Nouveau deallocates a few buffers post GPU init which are required for

On Tue, Jul 30, 2024 at 09:49:15PM +0000, Timur Tabi wrote: > > "Driver exit" is a bit of an undefined term, the closest thing is probably > > "driver detach" (from a device). In this case I think you actually mean > > "module > > exit" though. > > Yes, I use driver and module interchangeably, but I guess that's not > accurate.

These seem to get called, but it doesn't look like we have to care too much at this point. Signed-off-by: Dave Airlie <airlied at redhat.com> --- .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 24 ++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index

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

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

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

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

On Mon, 2024-07-29 at 18:07 -0500, Timur Tabi wrote: 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<mailto:ttabi at

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

smatch reports drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c:49:1: warning: symbol 'ga102_gsps' was not declared. Should it be static? This variable is only used in its defining file, so it should be static Signed-off-by: Tom Rix <trix at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

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

On Mon, 2024-03-04 at 13:57 +0100, Danilo Krummrich wrote: > > Thanks for sending a new version of the patch. > > Please make sure that for future patches you include a changelog, such that > it's easier for reviewers to keep track of what has changed. Will do. > > .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 6 + > >

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 Wed, 2024-07-31 at 16:54 +0200, Danilo Krummrich wrote: > > > > gsp_logs.shutdown(&gsp_logs) -- are you sure you want this? ?This is some > > weird C++ wanna-be code, IMHO. ?I don't think this is an improvement. I'd > > rather keep it as-is. > > That's why I wrote "maybe a bit too sneaky". :) > > I think what I asked for