similar to: [PATCH 1/2] drm/nouveau: Unmap pushbuf BOs when we're done with them.

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

Before this patch they were being reset to zero on every context switch instead of leaving the saved value, causing some context switching weirdness (the most serious symptom was the memory manager corrupting the BOs it migrated because of a malfunctioning M2MF). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nv10_graph.c | 3 ++- 1 files changed,

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

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

From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be

Currently Nouveau will unvalidate all buffers if it is forced to wait on one, and then start revalidating from the beginning. While doing so, it destroys the operation fence, causing nouveau_fence_emit to crash. This patch fixes this bug by taking the fence object out of validate_op and creating it just before emit. The fence pointer is initialized to 0 and unref'ed unconditionally. In

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

nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 68 ++++++++++++++++++++++++++++++-

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

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

Changes in v2: - Addressed review comments nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 68

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

Instead of storing the map per CPU provide and use per task storage. That prepares for local kmaps which are preemptible. The context switch code is preparatory and not yet in use because kmap_atomic() runs with preemption disabled. Will be made usable in the next step. The context switch logic is safe even when an interrupt happens after clearing or before restoring the kmaps. The kmap index in

I have just finished a patch to linux 2.0.29 that provides the SYN cookies protection against SYN flood attacks. You can grab it from my home page at: http://www.dna.lth.se/~erics/software/tcp-syncookies-patch-1.gz You can also follow the pointers from my home page (see the signature) to get a very short blurb about this patch. Quick synopsys: This implements the SYN cookie defense against SYN

> Intel: > rpm -Uvh ftp://ftp.redhat.com/updates/4.0/i386/util-linux-2.5-29.i386.rpm > > Alpha: > rpm -Uvh ftp://ftp.redhat.com/updates/4.0/axp/util-linux-2.5-29.axp.rpm > > SPARC: > rpm -Uvh ftp://ftp.redhat.com/updates/4.0/sparc/util-linux-2.5-29.sparc.rpm > > All of these packages have been signed with Red Hat''s PGP key. But when you do this,

As far as i see, we reserve the bo in the gem pushbuf ioctl, and unreserve after the pushbuf and the fence have been emitted. This assumption holds if bo moves happen on the same channel or if a cpu copy happens and we're waiting on fences. But for nv50 it is very common for the bo move to happen on the kernel fifo, which does not guarantee anything. Is there any safety i missed? Maarten.

Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: > This patch is not meant to be merged, but rather to try and understand > why this is needed and what a more suitable solution could be. > > Allowing BOs to be write-cached results in the following happening when > trying to run any program on Tegra/GK20A: > > Unhandled fault: external abort on non-linefetch

Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: > On 05/19/2014 06:57 PM, Lucas Stach wrote: > > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: > >> This patch is not meant to be merged, but rather to try and understand > >> why this is needed and what a more suitable solution could be. > >> > >> Allowing BOs to be

op 21-06-14 14:12, Ilia Mirkin schreef: > On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the >> entire notifier, and use a offset in nv30_context_kick_notify. > It would be great if you could detail the list of transformations

op 23-06-14 09:24, Ben Skeggs schreef: > On Mon, Jun 23, 2014 at 5:17 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> op 21-06-14 14:12, Ilia Mirkin schreef: >>> On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst >>> <maarten.lankhorst at canonical.com> wrote: >>>> nv30 seems to not support dma objects with offset, so