similar to: [PATCH drm-misc-next] drm/nouveau: uapi: don't pass NO_PREFETCH flag implicitly

On Tue, Aug 22, 2023 at 6:41?PM Danilo Krummrich <dakr at redhat.com> wrote: > Currently, NO_PREFETCH is passed implicitly through > drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. > > Since this is a direct representation of how the HW is programmed it > isn't really future proof for a uAPI. Hence, fix this up for the new > uAPI and split up

Currently, NO_PREFETCH is passed implicitly through drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. Since this is a direct representation of how the HW is programmed it isn't really future proof for a uAPI. Hence, fix this up for the new uAPI and split up the va_len field of struct drm_nouveau_exec_push, such that we keep 32bit for va_len and 32bit for flags. For

nouveau_fence_emit() can fail before and after initializing the dma-fence and hence before and after initializing the dma-fence' kref. In order to avoid nouveau_fence_emit() potentially failing before dma-fence initialization pass the channel to nouveau_fence_new() already and perform the required check before even allocating the fence. While at it, restore the original behavior of

I didn't file an Issue as I understand the cause and have a successful patch that I've been running here for several days. gitlab.freedesktop.org is RO (ie, I can't fork/stage a PR there) so I committed the absurdity of creating a PR on the public gitlab mirror in order to have a URL to point to: https://gitlab.com/freedesktop-mirror/drm/-/merge_requests/1 copypasting the commit

On 1/27/23 02:05, Matthew Brost wrote: > On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote: >> This commit provides the interfaces for the new UAPI motivated by the >> Vulkan API. It allows user mode drivers (UMDs) to: >> >> 1) Initialize a GPU virtual address (VA) space via the new >> DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel

Am 27.01.23 um 02:26 schrieb Danilo Krummrich: > On 1/27/23 02:05, Matthew Brost wrote: >> On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote: >>> This commit provides the interfaces for the new UAPI motivated by the >>> Vulkan API. It allows user mode drivers (UMDs) to: >>> >>> 1) Initialize a GPU virtual address (VA) space via the new

On 7/22/23 00:58, Faith Ekstrand wrote: > > On Wed, Jul 19, 2023 at 7:15?PM Danilo Krummrich <dakr at redhat.com > <mailto:dakr at redhat.com>> wrote: > > This commit provides the interfaces for the new UAPI motivated by the > Vulkan API. It allows user mode drivers (UMDs) to: > > 1) Initialize a GPU virtual address (VA) space via the new >

- In case of suspend lockups it's nice to know it happened in nouveau. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drv.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index 874adf5..ec8452f 100644 ---

A cleanup of nouveau_dma_wait(): extract a sub-function and eliminate two variables to improve readability. No functional changes. Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_dma.c | 72 ++++++++++++++++++--------------- 1 files changed, 39 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c

Commit "drm/nouveau: port all engines to new engine module format" changed IB size calculation to be less wasteful, but didn't take into account already existing off-by-one bugs :). So: - ib_max is the last entry, so we need to +1 when calculating number of free entries - nv50_dma_wait already does +1 (for FIRE_RING), so we don't need another +1 on nouveau_gem_ioctl_pushbuf

From: Ben Skeggs <bskeggs at redhat.com> There was at least one situation we could get into in the old code where we'd end up overrunning the push buffer with the jumps back to the start of the buffer in an attempt to get more space. In addition, the new code prevents misdetecting a GPU hang by resetting the timeout counter if we see the GPU GET pointer advancing, and simplifies the

On 1/27/23 04:21, Matthew Brost wrote: > On Fri, Jan 27, 2023 at 02:43:30AM +0100, Danilo Krummrich wrote: >> >> >> On 1/27/23 02:05, Matthew Brost wrote: >>> On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote: >>>> This commit provides the interfaces for the new UAPI motivated by the >>>> Vulkan API. It allows user mode drivers

nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call their corresponding *_fini() counterpart. This can lead to nouveau_sched_fini() being called without struct nouveau_sched ever being initialized in the first place. Instead of embedding struct nouveau_sched into struct nouveau_cli and struct nouveau_chan_abi16, allocate struct nouveau_sched separately, such that we can check

Revised patch set v2. [PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c [PATCH 2/8] drm/nouveau: use bo accessors for push buffers [PATCH 3/8] drm/nouveau: OUT_RINGp - optimize OUT_RING loops [PATCH 4/8] drm/nv50: proper notifier_bo access in nv50_display_vblank_crtc_handler() [PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors [PATCH 6/8] drm/nouveau: screen_base and

- This is not yet a generic implementation that will work everywhere, but it's a start. - This will fix the corruption surrounding pixmap/texture bo moves on nv50. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 ++- drivers/gpu/drm/nouveau/nouveau_channel.c | 9 ++- drivers/gpu/drm/nouveau/nouveau_dma.c | 26

Introduce accessors for TTM buffer object memory that has been mapped into the kernel virtual address space or as IO memory. IO memory needs to be accessed via special accessor functions, not by dereferencing the iomem cookie. The wrappers hide the details of 32-bit access and honour the TTM map type. nv04_crtc_cursor_set() is changed to use the new wrappers. 'cursor' is received from

Use ioremap() for mapping the channel user regs (that are never exposed to user space) instead of drm_addmap(). This removes the last use cases of drm_addmap/drm_rmmap from Nouveau. Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 13 ++++++------- drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +++------

It will be useful for various synchronization purposes, mostly stolen from "[PATCH] drm/nv50: synchronize user channel after buffer object move on kernel channel" by Maarten Maathuis. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 4 +++- drivers/gpu/drm/nouveau/nouveau_dma.c | 17 +++++++++++++++++

This fixes kms for 9800M and possibly 9600M Signed-off-by: Maxime COSTE <frrrwww at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_dma.h | 8 ++++++++ drivers/gpu/drm/nouveau/nv50_crtc.c | 5 +++++ drivers/gpu/drm/nouveau/nv50_cursor.c | 2 ++ drivers/gpu/drm/nouveau/nv50_display.c | 2 ++ 4 files changed, 17 insertions(+), 0 deletions(-) diff --git

The following patchset remove use of the deprecated drmP.h header file in the nouveau driver(s). As preparation a dependency on drm_os_linux.h is dropped. The list of include files are sorted and are in some cases divided up in blocks of linux/* drm/* etc. The removal is divided up in a few patches that was the logical steps to remove the use of drmP.h. Build tested with allmodconfig and