search for: r535_gsp_copy_log

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.