Displaying 7 results from an estimated 7 matches for "r535_gsp_copy_log".
2024 Jul 31
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
...sure what you're asking now. I definitely think that the "if
(!root)" check is necessary, because we don't want to accidentally create
these debugfs entries in /sys/kernel/debug/0000:65:00.0/.
So that leaves the error checks for debugfs_create_dir() and
debugfs_create_blob() in r535_gsp_copy_log(). Both of these functions could
fail.
If I ignore the error from debugfs_create_dir(), then the code will allocate
buffers that are never used, and make false statements about the existence
of them.
Same thing is true with debugfs_create_blob().
dir = debugfs_create_blob(name, 0444, parent,...
2024 Jul 29
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
...shut down, that means that the
+ * buffer was never written to, so it can be ignored.
+ *
+ * This test also works for logpmu, even though it doesn't have a put pointer.
+ */
+static bool is_empty(struct debugfs_blob_wrapper *b)
+{
+ u64 *put = b->data;
+
+ return *put == 0;
+}
+
+static int r535_gsp_copy_log(struct dentry *parent,
+ const char *name,
+ struct debugfs_blob_wrapper *s,
+ struct debugfs_blob_wrapper *d)
+{
+ struct dentry *dir;
+
+ /* If the buffer is empty, just skip it. */
+ if (is_empty(s))
+ return 0;
+
+ d->data = kmemdup(s->data, s->size, GFP_KERNEL);...
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
---
2024 Jul 30
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
...tten to, so it can be ignored.
> + *
> + * This test also works for logpmu, even though it doesn't have a put pointer.
> + */
> +static bool is_empty(struct debugfs_blob_wrapper *b)
> +{
> + u64 *put = b->data;
> +
> + return *put == 0;
> +}
> +
> +static int r535_gsp_copy_log(struct dentry *parent,
> + const char *name,
> + struct debugfs_blob_wrapper *s,
> + struct debugfs_blob_wrapper *d)
> +{
> + struct dentry *dir;
> +
> + /* If the buffer is empty, just skip it. */
> + if (is_empty(s))
> + return 0;
> +
> + d-&...
2024 Jul 31
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
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.