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