search for: nvif_logs

Displaying 9 results from an estimated 9 matches for "nvif_logs".

Did you mean: nvif_log
2024 Jul 31
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
...er it in module_exit(). > > > + * backing resources, such as logging buffers. > > > + */ > > > +struct nvif_log { > > > + struct list_head entry; > > > + void (*shutdown)(struct nvif_log *log); > > > +}; > > > + > > > +#define NVIF_LOGS_DECLARE(_log) \ > > > + struct nvif_log _log = { LIST_HEAD_INIT(_log.entry) } > > > > If you declare this as > > > > #define NVIF_LOGS_DECLARE(_log) \ > > struct nvif_log _log = { LIST_HEAD_INIT(_log.entry), nvif_log_shutdown } > > > > and ch...
2024 Jul 30
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
...non-PCI versions of Turing+ GPUs do not exist. Even the GH100, which uses an nvlink data connection between GPU to the ARM host, still uses PCI for control. > > > > +/** > > + * nvif_log - structure for tracking logging buffers > > + * @entry: an entry in a list of struct nvif_logs > > + * @shutdown: pointer to function to call to clean up > > + * > > + * Structure used to track logging buffers so that they can be cleaned > > up > > + * when the driver exits. > > "Driver exit" is a bit of an undefined term, the closest thing is p...
2024 Jun 18
1
[PATCH 2/2] [v5] drm/nouveau: expose GSP-RM logging buffers via debugfs
...entifier: MIT */ +/* SPDX-FileCopyrightText: Copyright (c) 2024 NVIDIA CORPORATION & AFFILIATES. */ + +#ifndef __NVIF_LOG_H__ +#define __NVIF_LOG_H__ + +/** + * nvif_log - structure for tracking logging buffers + * @head: list head What about "@entry: an entry in a list of struct nvif_logs". Done. + * @shutdown: pointer to function to call to clean up I'd be a bit more specific and say that this frees all backing resources, such as logging buffer, etc. Done. + * + * Structure used to track logging buffers so that they can be cleaned up + * when the driver exits....
2024 Jul 31
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
...t. I'd > > rather keep it as-is. > > That's why I wrote "maybe a bit too sneaky". :) > > I think what I asked for originally in one of the last versions of this patch > is having both, struct nvif_log (exactly the way you have it) and a separate > struct nvif_logs: > > struct nvif_logs { > struct list_head head; > }; > > Then you use this in NVIF_LOGS_DECLARE() and nvif_log_shutdown() > > static inline void nvif_log_shutdown(struct nvif_logs *logs) > > and in nouveau_drm_exit() you just pass &gsp_logs. > > n...
2024 Jul 30
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
...t; > A simple way to test the buffer migration feature is to have > nvkm_gsp_init() return an error code. > > Signed-off-by: Timur Tabi <ttabi at nvidia.com> > > v6: > rebased onto drm-misc-next > renamed nvif_log.head to entry > only one space after . > added NVIF_LOGS_DECLARE > added nvif_log_shutdown > documented NV_GSP_MSG_EVENT_UCODE_LIBOS_CLASS_PMU > removed the "See xxx" comments > replaced camelcase with lowercase in r535_gsp_msg_libos_print > replaced 0x100c with NV_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT > added r535_gsp_libos_debugf...
2024 Jul 29
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
...V_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT RPCs are ignored. A simple way to test the buffer migration feature is to have nvkm_gsp_init() return an error code. Signed-off-by: Timur Tabi <ttabi at nvidia.com> v6: rebased onto drm-misc-next renamed nvif_log.head to entry only one space after . added NVIF_LOGS_DECLARE added nvif_log_shutdown documented NV_GSP_MSG_EVENT_UCODE_LIBOS_CLASS_PMU removed the "See xxx" comments replaced camelcase with lowercase in r535_gsp_msg_libos_print replaced 0x100c with NV_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT added r535_gsp_libos_debugfs_fini miscellaneous comment i...
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 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