search for: debugfs_create_blob

...ou can see, 'dir' is the second most popular name. So I think it's fine. Besides, couldn't you have make this suggestion during one of the previous 7 versions of this patch? I'm never going to get this patch finished if you keep asking for cosmetic changes. > > + dir = debugfs_create_blob(name, 0444, gsp->dir, blob); > > + if (IS_ERR(dir)) { > > + nvkm_error(&gsp->subdev, > > + "failed to create %s debugfs entry\n", name); > > + return NULL; > > + } > > + > > + /* > > + * For some reason, debugfs_create_blob...

...s reply.) So I'm not 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_bl...

...ging buffer with the name 'name'. > + */ > +static struct dentry *create_debugfs(struct nvkm_gsp *gsp, const char *name, > + struct debugfs_blob_wrapper *blob) > +{ > + struct dentry *dir; I think `dir` is confusing, what about `dent` or `entry`? > + > + dir = debugfs_create_blob(name, 0444, gsp->dir, blob); > + if (IS_ERR(dir)) { > + nvkm_error(&gsp->subdev, > + "failed to create %s debugfs entry\n", name); > + return NULL; > + } > + > + /* > + * For some reason, debugfs_create_blob doesn't set the size of the > +...

...GSP-RM and must be only 4KB. We create it here because it's + * only useful if there is a debugfs entry to expose it. If we get the PMU + * logging RPC and there is no debugfs entry, the RPC is just ignored. + * + * The blob_init, blob_rm, and blob_pmu objects can't be transient + * because debugfs_create_blob doesn't copy them. + * + * NOTE: OpenRM loads the logging elf image and prints the log messages + * in real-time. We may add that capability in the future, but that + * requires loading an ELF images that are not distributed with the driver, + * and adding the parsing code to Nouveau. + * + * I...

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 +

..._DEV_INITRD +static struct debugfs_blob_wrapper initrd_blob; + +static int __init export_initrd(void) +{ + struct dentry *d; + initrd_blob.data = (char *)initrd_start; + initrd_blob.size = initrd_end - initrd_start; + + if (!do_retain_initrd) + return 0; + + if (!initrd_start) + return 0; + + d = debugfs_create_blob("initrd", S_IFREG, NULL, &initrd_blob); + + if (!d) + return 1; + + return 0; +} + +__initcall(export_initrd); +#endif

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

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.

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

...KB. We create it here because it's > + * only useful if there is a debugfs entry to expose it. If we get the PMU > + * logging RPC and there is no debugfs entry, the RPC is just ignored. > + * > + * The blob_init, blob_rm, and blob_pmu objects can't be transient > + * because debugfs_create_blob doesn't copy them. > + * > + * NOTE: OpenRM loads the logging elf image and prints the log messages > + * in real-time. We may add that capability in the future, but that > + * requires loading an ELF images that are not distributed with the driver, > + * and adding the parsing c...

The 4-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. The V2 change discussion was in:

The 4-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. The V2 change discussion was in:

The 5-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. Changes in V4: - reabsed to 3.2.0 pre. - use APIC

The 5-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. Changes in V4: - reabsed to 3.2.0 pre. - use APIC

The 6-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. one MSR is added to aid live migration. Changes

The 6-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. one MSR is added to aid live migration. Changes