similar to: [PATCH][next] drm/nouveau/gsp: remove extraneous ; after mutex

Displaying 20 results from an estimated 4000 matches similar to: "[PATCH][next] drm/nouveau/gsp: remove extraneous ; after mutex"

2024 Jan 29
0
[PATCH] [v2] nouveau: add command-line GSP-RM registry support
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
2024 Feb 20
2
[PATCH] [v4] nouveau: add command-line GSP-RM registry support
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
2024 Mar 20
1
[PATCH] [v4] nouveau: add command-line GSP-RM registry support
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 + > >
2024 Jun 12
2
[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
2024 Aug 02
1
[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> --- Notes: v2: added get/put_device calls
2024 Jul 29
2
[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: added get/put_device calls ---
2023 Nov 08
1
[PATCH] nouveau/gsp/r535: Fix a NULL vs error pointer bug
The r535_gsp_cmdq_get() function returns error pointers but this code checks for NULL. Also we need to propagate the error pointer back to the callers in r535_gsp_rpc_get(). Returning NULL will lead to a NULL pointer dereference. Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Signed-off-by: Dan Carpenter <dan.carpenter at linaro.org> ---
2023 Dec 04
1
[PATCH] nouveau/gsp: add three notifier callbacks that we see in normal operation
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
2023 Dec 05
0
[PATCH] nouveau/gsp: add three notifier callbacks that we see in normal operation (v2)
Add NULL callbacks for some things GSP calls that we don't handle, but know about so we avoid the logging. v2: Timur suggested allowing null fn. Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
2024 Jul 30
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
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
2024 Jan 30
1
[PATCH] nouveau/gsp: use correct size for registry rpc.
From: Dave Airlie <airlied at redhat.com> Timur pointed this out before, and it just slipped my mind, but this might help some things work better, around pcie power management. Fixes: 8d55b0a940bb ("nouveau/gsp: add some basic registry entries.") Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 2 +- 1 file changed, 1
2024 Jun 18
1
[PATCH 2/2] [v5] drm/nouveau: expose GSP-RM logging buffers via debugfs
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
2023 Nov 07
1
[bug report] drm/nouveau/gsp/r535: add support for booting GSP-RM
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
2024 Jul 29
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
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
2023 Nov 07
3
[bug report] drm/nouveau/gsp/r535: add support for booting GSP-RM
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
2023 Nov 07
2
[bug report] drm/nouveau/gsp/r535: add support for booting GSP-RM
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
2023 Dec 22
1
[PATCH 07/11] nouveau/gsp: convert gsp errors to generic errors
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
2024 Jul 30
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
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. > >
2024 Mar 30
1
[PATCH] nouveau/gsp: Avoid addressing beyond end of rpc->entries
Using the end of rpc->entries[] for addressing runs into both compile-time and run-time detection of accessing beyond the end of the array. Use the base pointer instead, since was allocated with the additional bytes for storing the strings. Avoids the following warning in future GCC releases with support for __counted_by: In function 'fortify_memcpy_chk', inlined from
2023 Nov 16
1
[PATCH][next] nouveau/gsp: replace zero-length array with flex-array member and use __counted_by
Hi Gustavo, On Thu, Nov 16, 2023 at 12:11:43PM -0600, Gustavo A. R. Silva wrote: > 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