search for: ttabi

Displaying 20 results from an estimated 32 matches for "ttabi".

Did you mean: tabi
2024 Jul 29
1
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
...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<mailto:ttabi at nvidia.com>> v2: added get/put_device calls Ugh, I forgot to move this to under the --- -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20240729/ebc3ff37/attach...
2024 Feb 02
3
[PATCH 1/2] drm/nouveau: don't fini scheduler if not initialized
...mmit we can also avoid to allocate a struct nouveau_sched in nouveau_abi16_ioctl_channel_alloc() at all, if the VM_BIND uAPI has been disabled due to the legacy uAPI being used. Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship") Reported-by: Timur Tabi <ttabi at nvidia.com> Closes: https://lore.kernel.org/nouveau/20240131213917.1545604-1-ttabi at nvidia.com/ Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 10 ++++--- drivers/gpu/drm/nouveau/nouveau_abi16.h | 2 +- drivers/gpu/drm/nouveau/nouv...
2024 Jul 29
2
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
...tore 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 --- .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 1 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 50 ++++++++++++------- 2 files changed, 34 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/d...
2023 Nov 16
3
[PATCH][next] nouveau/gsp: replace zero-length array with flex-array member and use __counted_by
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 the coming implementation by GCC and Clang of the `__counted_by` attribute. Flexible array members annotated with
2023 Feb 17
0
[PATCH] drm/nouveau: NV_DEBUG and NV_ATOMIC should call __drm_debug_enabled
...t enough to optimize ? Because the Nouveau macros NV_DEBUG and NV_ATOMIC call drm_debug_enabled(), this message can appear hundreds of times when the driver is loaded with debug messages enabled. To avoid this, these macros should call __drm_debug_enabled() instead. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index d6dd07bfa64a..5b4f87055202 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++...
2023 Dec 04
1
[PATCH] nouveau/gsp: add three notifier callbacks that we see in normal operation
On Tue, 2023-12-05 at 08:55 +1000, Dave Airlie wrote: > +static int > +r535_gsp_msg_ucode_libos_print(void *priv, u32 fn, void *repv, u32 repc) > +{ > +???????/* work out what we should do here. */ > +???????return 0; > +} This is part of my logrm debugfs patch. ?It contains the printf log from a PMU exception. Do you want me to research the other two RPCs and tell you exactly
2023 Dec 05
1
[PATCH] nouveau/gsp: add three notifier callbacks that we see in normal operation
On Tue, 5 Dec 2023 at 09:07, Timur Tabi <ttabi at nvidia.com> wrote: > > On Tue, 2023-12-05 at 08:55 +1000, Dave Airlie wrote: > > +static int > > +r535_gsp_msg_ucode_libos_print(void *priv, u32 fn, void *repv, u32 repc) > > +{ > > + /* work out what we should do here. */ > > + return 0; > &...
2024 Mar 30
1
[PATCH] nouveau/gsp: Avoid addressing beyond end of rpc->entries
...com> Cc: Lyude Paul <lyude at redhat.com> Cc: Danilo Krummrich <dakr at redhat.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at ffwll.ch> Cc: Dave Airlie <airlied at redhat.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Timur Tabi <ttabi at nvidia.com> Cc: dri-devel at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/...
2024 Aug 15
1
[PATCH] nouveau/firmware: using dma non-coherent interfaces for fw loading. (v2)
On Fri, 2024-08-16 at 06:19 +1000, Dave Airlie wrote: > Fix this by using the non-coherent allocator instead, I think there > might be a better answer to this, but it involve ripping up some of > APIs using sg lists. Thanks for fixing this, but what is the relationshio between non-coherent DMA and sg_set_buf()? ? You're still calling?sg_init_one() and hitting this check: #ifdef
2024 Dec 11
1
[PATCH -next] drm/nouveau/gsp/r535: Modify mismatched function name
No functional modification involved. drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:2174: warning: expecting prototype for create_debufgs(). Prototype was for create_debugfs() instead. Reported-by: Abaci Robot <abaci at linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=12292 Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com> ---
2024 Nov 25
2
[PATCH] drm/nouveau: create module debugfs root
Typically DRM drivers use the DRM debugfs root entry. However, since Nouveau is heading towards a split into a core and a DRM driver, create a module specific debugfs root directory. Subsequent patches make use of this new debugfs root in order to store GSP-RM log bufferes (optionally beyond a device driver binding). Signed-off-by: Danilo Krummrich <dakr at kernel.org> --- Unless there are
2024 Oct 30
2
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
...tore 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 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 50 ++++++++++++------- 2 files changed, 34 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include/n...
2023 Nov 16
1
[PATCH][next] nouveau/gsp: replace zero-length array with flex-array member and use __counted_by
...[1] in this case). Of course, that's probably more up to Timur to tell if this will work out. If we can't get a fix upstream, I'd probably prefer to silence warning elsewhere. [1] https://github.com/NVIDIA/open-gpu-kernel-modules [2] https://lore.kernel.org/all/20231107234726.854248-1-ttabi at nvidia.com/T/ > > #endif > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c > index dc44f5c7833f..228335487af5 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subd...
2024 Jun 18
1
[PATCH 2/2] [v5] drm/nouveau: expose GSP-RM logging buffers via debugfs
...<path>/logpmu logpmu where <path> is the PCI ID of the GPU (e.g. 0000:65:00.0). Since LOGPMU is not needed for normal GSP-RM operation, it is only created if debugfs is available. Otherwise, the NV_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT RPCs are ignored. Signed-off-by: Timur Tabi <ttabi at nvidia.com<mailto:ttabi at nvidia.com>> --- v5: rebased to drm-misc-next repaced nvkm_gsp_log with nvif_log minor rearrangement of some code drivers/gpu/drm/nouveau/include/nvif/log.h | 32 ++ .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 13 + drivers/gpu/drm/nouveau/n...
2024 Oct 30
2
[PATCH 2/2] [v9] drm/nouveau: expose GSP-RM logging buffers via debugfs
...Since LOGPMU is not needed for normal GSP-RM operation, it is only created if debugfs is available. Otherwise, the NV_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> --- v9: - rebased to drm-misc-next - move nvkm_gsp logging dentries into debugfs struct - add gsp_logging_debugfs_root and always create the root dentry - remove root struct in r535.c, along with mutex code - rename dir to dent - add missing calls to create_debugfs helper - r535...
2024 Jun 12
2
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
...tore 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 .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 1 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 36 ++++++++++--------- 2 files changed, 20 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/dri...
2024 Aug 02
1
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
...tore 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 .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 1 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 50 ++++++++++++------- 2 files changed, 34 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/...
2024 Jan 29
0
[PATCH] [v2] nouveau: add command-line GSP-RM registry support
...ty in concert with GSP-RM. Therefore, any keys which also require action by the driver may not function correctly when passed by Nouveau. Caveat emptor. The name and format of NVreg_RegistryDwords is the same as used by the Nvidia driver, to maintain compatibility. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- v2: fix typos and a memory leak .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 6 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 276 ++++++++++++++++-- 2 files changed, 258 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h...
2024 Feb 20
2
[PATCH] [v4] nouveau: add command-line GSP-RM registry support
...ty in concert with GSP-RM. Therefore, any keys which also require action by the driver may not function correctly when passed by Nouveau. Caveat emptor. The name and format of NVreg_RegistryDwords is the same as used by the Nvidia driver, to maintain compatibility. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 6 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 375 ++++++++++++++++-- 2 files changed, 357 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include...
2024 Sep 10
1
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
...tore 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 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 50 ++++++++++++------- 2 files changed, 34 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include/n...