Re: [Nouveau] [PATCH] driver: gpu: Fixing warning directly dereferencing a rcu pointer

Hey, Den 2023-11-13 kl. 09:10, skrev Abhinav Singh: This patch fixes a sparse warning with this message "warning:dereference of noderef expression". In this context it means we are dereferencing a __rcu tagged pointer directly. We should not be directly dereferencing a rcu pointer, rather we

Re: [Nouveau] [PATCH] drm/nouveau: Drop mutex_lock_nested for atomic

flipping paths > > due to > > commit b580c9e2b7ba5030a795aa2fb73b796523d65a78 > Author: Maarten Lankhorst > Date: Thu Jun 27 13:48:18 2013 +0200 > > drm/nouveau: make flipping lockdep safe > > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Ben Skeggs > Cc: Dave Airli

Re: [Nouveau] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

d dma_resv. >> >> Fix this by adding a slowpath for when we need relocations, and by >> pushing the writeback of the new presumed offsets to the very end. >> >> Aside from "it compiles" entirely untested unfortunately. >> >> Signed-off-by: Daniel Vette

Re: [Nouveau] [PATCH] drm/fbdev: Make skip_vt_switch the default

Thanks to Michel Dänzer for pointing this one out. Maybe just reload the gamma lut on resume for radeon, instead of relying on fbcon? Otherwise patch looks sane, would be nice if radeon was fixed instead of worked around. Reviewed-by: Maarten Lankhorst

Re: [Nouveau] [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere

Op 12-11-18 om 17:11 schreef Sean Paul: > On Mon, Nov 12, 2018 at 04:01:14PM +0100, Maarten Lankhorst wrote: >> We already have __drm_atomic_helper_connector_reset() and >> __drm_atomic_helper_plane_reset(), extend this to crtc as well. >> >> Most drivers already hav

[Nouveau] [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere

-by: Maarten Lankhorst Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: David Airlie Cc: Liviu Dudau Cc: Brian Starkey Cc: Mali DP Maintainers Cc: Boris Brezillon Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic De

Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

Op 14-02-18 om 09:46 schreef Lukas Wunner: > Dear drm-misc maintainers, > > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote: >> Fix a deadlock on hybrid graphics laptops that's been present since 2013: > This series has been reviewed, consent has been expressed by the most >

Re: [Nouveau] [Intel-gfx] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property

Op 25-07-17 om 10:01 schreef Daniel Vetter: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_connector_set_property. > > The only special case is nouveau which used one function for both > pre-nv50 legacy modeset code and post-nv50

[Nouveau] [PATCH v2 6/7] drm/nouveau: Convert nouveau to use new iterator macros, v2.

ate changes. Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Cc: Ben Skeggs <bske...@redhat.com> Cc: nouveau@lists.freedesktop.org --- drivers/gpu/drm/nouveau/nv50_display.c | 72 +- 1 file changed, 37 insertions(+), 35 deletions

[Nouveau] [PATCH 01/12] drm/nouveau: Fix error handling in nv50_disp_atomic_commit

edhat.com> Cc: dri-de...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: <sta...@vger.kernel.org> # v4.10+ Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-2-maarten.lankho...@linux

[Nouveau] [PATCH 03/12] drm/nouveau: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Cc: Ben Skeggs <bske...@redhat.com> Cc: nouveau@lists.freedesk

Re: [Nouveau] [Intel-gfx] [PATCH 15/16] drm/nouveau: Convert nouveau to use new iterator macros

Op 13-07-17 om 14:33 schreef Daniel Vetter: > On Wed, Jul 12, 2017 at 10:13:43AM +0200, Maarten Lankhorst wrote: >> Use the new atomic iterator macros, the old ones are about to be >> removed. With the new macros, it's more easy to get old and new state so >> get them fr

[Nouveau] [PATCH 15/16] drm/nouveau: Convert nouveau to use new iterator macros

Use the new atomic iterator macros, the old ones are about to be removed. With the new macros, it's more easy to get old and new state so get them from the macros instead of from obj->state. Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Cc: Ben Skeggs <bske..

[Nouveau] [PATCH v2 03/12] drm/nouveau: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Cc: Ben Skeggs <bske...@redhat.com> Cc: nouveau@lists.fre

[Nouveau] [PATCH v2 01/12] drm/nouveau: Fix error handling in nv50_disp_atomic_commit

edhat.com> Cc: dri-de...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: <sta...@vger.kernel.org> # v4.10+ Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> --- drivers/gpu/drm/nouveau/nv50_display.c | 7 +-- 1 file changed, 5 insertions(+), 2 deleti

Re: [Nouveau] [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

Op 30-06-17 om 15:56 schreef Daniel Vetter: > On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote: >> We want to change swap_state to wait indefinitely, but to do this >> swap_state should wait interruptibly. This requires propagating >> the error to each dri

Re: [Nouveau] [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

Op 30-06-17 om 15:56 schreef Daniel Vetter: > On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote: >> We want to change swap_state to wait indefinitely, but to do this >> swap_state should wait interruptibly. This requires propagating >> the error to each dri

[Nouveau] [PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.

gt; Cc: Eric Anholt <e...@anholt.net> Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-media...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: n

[Nouveau] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-media...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-te...@vger.kernel.org Signed-off-by: Maarten Lankhorst

Re: [Nouveau] [PATCH 1/6] drm/nouveau: Fail fb creation from imported dma-bufs.

0) > return >base; I don't know if there's really a hard requirement for nouveau to scan out from GART on nv50+, but it might be a bigger problem on earlier platforms. Acked-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> _

Re: [Nouveau] [PATCH 2/6] drm/nouveau: Pin bos from imported dma-bufs to GTT.

Op 29-03-17 om 02:27 schreef r...@ubuntu.com: > From: Christopher James Halse Rogers > > Attempting to migrate the bo will break the sharing of the buffer. > > Signed-off-by: Christopher James Halse Rogers > > CC:

Re: [Nouveau] [Intel-gfx] [PATCH 1/3] drm/atomic: Make disable_all helper fully disable the crtc.

Op 23-02-17 om 16:03 schreef Sean Paul: > On Tue, Feb 21, 2017 at 02:51:40PM +0100, Maarten Lankhorst wrote: >> It seems that nouveau requires this, so best to do this in the helper. >> This allows nouveau to use the atomic suspend helper. > Pardon the stupid question, but why

[Nouveau] [PATCH 1/3] drm/atomic: Make disable_all helper fully disable the crtc.

It seems that nouveau requires this, so best to do this in the helper. This allows nouveau to use the atomic suspend helper. Cc: nouveau@lists.freedesktop.org Acked-by: Ben Skeggs <bske...@redhat.com> #irc Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> --- dri

[Nouveau] [PATCH 3/3] drm/atomic: Make disable_all helper fully disable the crtc.

It seems that nouveau requires this, so best to do this in the helper. This allows nouveau to use the atomic suspend helper. Cc: nouveau@lists.freedesktop.org Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> --- drivers/gpu/drm/drm_atomic_helper.c

[Nouveau] [ANNOUNCE] xf86-video-nouveau 1.0.13

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Jackson (1): Adapt Block/WakeupHandler signature for ABI 23 Ben Skeggs (2): fix use of out-of-scope data exa/nv50-: fix some potential incomplete pushes Hans de Goede (1): Properly cleanup fb for reverse-prime-offload

Re: [Nouveau] [PATCH v2] nouveau: add coherent BO attribute

Op 23-05-15 om 08:45 schreef Alexandre Courbot: On Fri, May 22, 2015 at 3:23 AM, Martin Peres martin.pe...@free.fr wrote: On 21/05/2015 11:47, Ben Skeggs wrote: On 21 May 2015 at 16:08, Alexandre Courbot acour...@nvidia.com wrote: Add a flag allowing Nouveau to specify that an object should be

Re: [Nouveau] [PATCH] nouveau: add coherent BO attribute

, Maarten Lankhorst wrote: Hey, Op 13-03-15 om 07:27 schreef Alexandre Courbot: Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs

[Nouveau] [PATCH ddx] Add support for VRAM-less devices to the ddx

in nouveau_allocate_surface the effect is still the same. Signed-off-by: Maarten Lankhorst d...@mblankhorst.nl --- The only thing still missing is adding NOUVEAU_BO_COHERENT to nouveau_allocate_surface, the scratch buffer, and nouveau_exa_scratch. After that xorg stays up long enough to crash

[Nouveau] [PATCH v2 ddx] Add support for VRAM-less devices to the ddx

in nouveau_allocate_surface the effect is still the same. Signed-off-by: Maarten Lankhorst d...@mblankhorst.nl --- Changes since v1: Fix nouveau_exa_create_pixmap to not trigger the = 32 MB code for vram_size == 0. This makes tegra work correctly with set_shared_pixmap. diff --git a/src

Re: [Nouveau] [PATCH] nouveau: add coherent BO attribute

Hey, Op 13-03-15 om 07:27 schreef Alexandre Courbot: Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver

[Nouveau] [PATCH v2 4/4] nouveau: Do not add most bo's to the global bo list.

Only add wrapped bo's and bo's that have been exported through flink or dma-buf. This avoids a lock in the common case, and decreases traversal needed for importing a dma-buf or flink. Signed-off-by: Maarten Lankhorst maarten.lankho...@ubuntu.com --- nouveau/nouveau.c | 46

[Nouveau] [PATCH v2 2/4] Use __sync_add_and_fetch instead of __sync_fetch_and_add for atomic_dec_and_test

Signed-off-by: Maarten Lankhorst maarten.lankho...@ubuntu.com --- xf86atomic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xf86atomic.h b/xf86atomic.h index 17fb088..194554c 100644 --- a/xf86atomic.h +++ b/xf86atomic.h @@ -50,7 +50,7 @@ typedef struct { # define

[Nouveau] [PATCH v2 1/4] Add atomic_inc_return to atomics.

Signed-off-by: Maarten Lankhorst maarten.lankho...@ubuntu.com --- xf86atomic.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xf86atomic.h b/xf86atomic.h index 8c4b696..17fb088 100644 --- a/xf86atomic.h +++ b/xf86atomic.h @@ -49,6 +49,7 @@ typedef struct { # define atomic_read(x) ((x

[Nouveau] [PATCH v2 3/4] nouveau: make nouveau importing global buffers completely thread-safe, with tests

refcount to 1. - thread 2 decreases refcount to zero, blocks on acquiring nvdev-lock. At this point the 2 threads will clean up the same bo. Signed-off-by: Maarten Lankhorst maarten.lankho...@ubuntu.com Reviewed-By: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 1 + nouveau

Re: [Nouveau] [PATCH 2/2] nouveau: Do not add most bo's to the global bo list.

Op 25-02-15 om 15:11 schreef Emil Velikov: On 24 February 2015 at 09:01, Maarten Lankhorst maarten.lankho...@ubuntu.com wrote: Only add wrapped bo's and bo's that have been exported through flink or dma-buf. This avoids a lock in the common case, and decreases traversal needed

Re: [Nouveau] [PATCH 2/2] nouveau: Do not add most bo's to the global bo list.

Op 25-02-15 om 16:28 schreef Patrick Baggett: On Wed, Feb 25, 2015 at 9:07 AM, Maarten Lankhorst maarten.lankho...@ubuntu.com wrote: Op 25-02-15 om 16:04 schreef Patrick Baggett: On Wed, Feb 25, 2015 at 8:59 AM, Maarten Lankhorst maarten.lankho...@ubuntu.com wrote: Op 25-02-15 om 15:11

Re: [Nouveau] [PATCH 2/2] nouveau: Do not add most bo's to the global bo list.

On 25-02-15 18:26, Patrick Baggett wrote: In general things don't get optimized across function calls, except in case of inlinable functions. And for compiler attributes it's the opposite,__attribute__((const)) and __attribute((pure)) can be used to indicate some kind of safety to

Re: [Nouveau] [PATCH 2/2] nouveau: Do not add most bo's to the global bo list.

Hey, On 25-02-15 18:05, Ilia Mirkin wrote: On Wed, Feb 25, 2015 at 11:59 AM, Patrick Baggett baggett.patr...@gmail.com wrote: If code like x = *a; pthread_mutex_lock or unlock or __memory_barrier() y = *a; doesn't cause a to get loaded twice, then the compiler's in serious trouble.

[Nouveau] [PATCH 1/2] nouveau: make nouveau importing global buffers completely thread-safe, with tests

was increased to 1 and skip deletion from list and closing the handle. Signed-off-by: Maarten Lankhorst maarten.lankho...@ubuntu.com --- configure.ac | 1 + nouveau/nouveau.c | 69 +++ tests/Makefile.am | 4 ++ tests/nouveau/.gitignore | 1 + tests

[Nouveau] [PATCH] drm/nouveau: dont switch vt on suspend

Restore the nv50 cursor bo on resume, and load the lut in nv50_display_display_init so it gets set on resume too. Tested on a fermi and a curie. Signed-off-by: Maarten Lankhorst maarten.lankho...@ubuntu.com --- diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau

[Nouveau] drm/nouveau: dont switch vt on suspend

Signed-off-by: Maarten Lankhorst maarten.lankho...@ubuntu.com --- diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 3ed12a8cfc91..a4a586807903 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c

[Nouveau] [PATCH try2 incomplete] drm/nouveau: dont switch vt on suspend

Seems the first try was incomplete and because of no_console_suspend in my cmdline I never noticed. This patch is still incomplete, it seems Xorg returns with a black screen after suspend, but after a vt switch this is cleared. At least the cursor works now... I'm open for feedback on the black

Re: [Nouveau] [RFC] Explicit synchronization for Nouveau

Hey, On 01-10-14 17:14, Lauri Peltonen wrote: Thanks Daniel for your input! On Mon, Sep 29, 2014 at 09:43:02AM +0200, Daniel Vetter wrote: On Fri, Sep 26, 2014 at 01:00:05PM +0300, Lauri Peltonen wrote: (2) Stop automatically storing fences to the buffers that user space wants to

Re: [Nouveau] [RFC PATCH 7/7] drm/prime: Support explicit fence on export

On 26-09-14 12:00, Lauri Peltonen wrote: Allow user space to provide an explicit sync fence fd when exporting a dma-buf from gem handle. The fence will be stored as the explicit fence to the reservation object. Signed-off-by: Lauri Peltonen lpelto...@nvidia.com ---

Re: [Nouveau] [RFC PATCH 6/7] drm/nouveau: Support marking buffers for explicit sync

Hey, On 26-09-14 12:00, Lauri Peltonen wrote: Do not attach fences automatically to buffers that are marked for explicit synchronization. Signed-off-by: Lauri Peltonen lpelto...@nvidia.com --- drm/nouveau_bo.c | 8 drm/nouveau_bo.h | 4 ++--

Re: [Nouveau] [RFC PATCH 1/7] android: Support creating sync fence from drm fences

Hey, On 26-09-14 12:00, Lauri Peltonen wrote: Modify sync_fence_create to accept an array of 'struct fence' objects. This will allow drm drivers to create sync_fence objects and pass sync fd's between user space with minimal modifications, without ever creating sync_timeline or sync_pt

Re: [Nouveau] [PATCH] drm/nv84+: fix fence context seqno's

Op 23-09-14 om 07:35 schreef Ben Skeggs: On Tue, Sep 23, 2014 at 2:23 AM, Ted Percival t...@tedp.id.au wrote: On 09/22/2014 03:08 AM, Maarten Lankhorst wrote: This fixes a regression introduced by drm/nouveau: rework to new fence interface (commit 29ba89b2371d466). The fence sequence

[Nouveau] [PATCH] drm/nv84+: fix fence context seqno's

of a channel being destroyed after a hang, and unblocking any other channel that may wait on the about-to-be-deleted channel to signal. I'm nothing if not optimistic about any hope of recovery from that. ;-) Reported-by: Ted Percival t...@tedp.id.au Signed-off-by: Maarten Lankhorst

[Nouveau] [PATCH] nouveau: bump driver patchlevel to 1.2.1

Allows userspace to detect shared fences are supported. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_drm.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Dave, can you include this in drm-next? It should allow me to optimize

[Nouveau] [ANNOUNCE] xf86-video-nouveau 1.0.11

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Highlights: - Support for server managed fd's. - Glamor support. - Maxwell support. - DRI3 and initial Present support. - vsync'ed kms pageflip performance fixes when running on Linux 3.13+ - Multi-display vsync, vblank, swap

Re: [Nouveau] Errors during vdpau mpeg2 decoding

Hey, On 04-09-14 05:53, Ilia Mirkin wrote: Hi Maarten, I'm seeing these prints, which feel like they're accompanied by bad frames: 0x7f7fcb29ab70 is not a real ref: -0.011 72712/72709 0% 35% 1.0% 0 0 This comes from if (dec-refs[idx].vidbuf != refs[i]) {

Re: [Nouveau] [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

op 04-08-14 19:04, Christian König schreef: Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst: op 04-08-14 17:04, Christian König schreef: Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst: op 04-08-14 16:45, Christian König schreef: Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst: op 04-08

Re: [Nouveau] [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

op 04-08-14 10:36, Christian König schreef: Hi Maarten, Sorry for the delay. I've got way to much todo recently. Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst: On 01-08-14 18:35, Christian König wrote: Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: Signed-off-by: Maarten Lankhorst

Re: [Nouveau] [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

Hey, op 04-08-14 13:57, Christian König schreef: Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst: op 04-08-14 10:36, Christian König schreef: Hi Maarten, Sorry for the delay. I've got way to much todo recently. Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst: On 01-08-14 18:35

Re: [Nouveau] [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

op 04-08-14 16:37, Christian König schreef: It'a pain to deal with gpu reset. Yeah, well that's nothing new. I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup. But this meant that the

Re: [Nouveau] [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

op 04-08-14 16:45, Christian König schreef: Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst: op 04-08-14 16:37, Christian König schreef: It'a pain to deal with gpu reset. Yeah, well that's nothing new. I've now tried other solutions but that would mean reverting to the old style during

Re: [Nouveau] [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

op 04-08-14 17:04, Christian König schreef: Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst: op 04-08-14 16:45, Christian König schreef: Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst: op 04-08-14 16:37, Christian König schreef: It'a pain to deal with gpu reset. Yeah, well that's nothing

Re: [Nouveau] [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

On 01-08-14 18:35, Christian König wrote: Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- V1 had a nasty bug breaking gpu lockup recovery. The fix is not allowing radeon_fence_driver_check_lockup to take exclusive_lock

[Nouveau] [libdrm PATCH 1/3] nouveau: Only export public functions.

This hides all the abi16_* functions and the nouveau_debug variable, they should have been private to begin with. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- nouveau/Makefile.am | 1 + nouveau/bufctx.c| 10 +- nouveau/nouveau.c | 40

[Nouveau] [PATCH 01/18] fence: add debugging lines to fence_is_signaled for the callback

fence_is_signaled callback should support being run in atomic context, but not in irq context. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- include/linux/fence.h | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux

[Nouveau] [PATCH 00/17] Convert TTM to the new fence interface. v2

easier for me. - Added a delayed work for radeon that checks gpu lockups. - Reworked the radeon fence implementation to remove deadlocks, and end up slightly cleaner. --- Maarten Lankhorst (18): fence: add debugging lines to fence_is_signaled for the callback drm/ttm: add

[Nouveau] [PATCH 01/19] fence: add debugging lines to fence_is_signaled for the callback

fence_is_signaled callback should support being run in atomic context, but not in irq context. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- include/linux/fence.h | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux

[Nouveau] [PATCH 03/19] drm/ttm: kill off some members to ttm_validate_buffer

This reorders the list to keep track of what buffers are reserved, so previous members are always unreserved. This gets rid of some bookkeeping that's no longer needed, while simplifying the code some. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/qxl

[Nouveau] [PATCH 04/19] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

Apart from some code inside ttm itself and nouveau_bo_vma_del, this is the only place where ttm_bo_wait is used without a reservation. Fix this so we can remove the fence_lock later on. After the switch to rcu the reservation lock will be removed again. Signed-off-by: Maarten Lankhorst

[Nouveau] [PATCH 05/19] drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence

This will ensure we always hold the required lock when calling those functions. --- drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++ drivers/gpu/drm/nouveau/nouveau_display.c | 17 + 2 files changed, 15 insertions(+), 4 deletions(-) diff --git

[Nouveau] [PATCH 12/19] drm/qxl: rework to new fence interface

Final driver! \o/ This is not a proper dma_fence because the hardware may never signal anything, so don't use dma-buf with qxl, ever. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/qxl/Makefile |2 drivers/gpu/drm/qxl/qxl_cmd.c |5

[Nouveau] [PATCH 06/19] drm/ttm: call ttm_bo_wait while inside a reservation

This is the last remaining function that doesn't use the reservation lock completely to fence off access to a buffer. --- drivers/gpu/drm/ttm/ttm_bo.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

[Nouveau] [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- V1 had a nasty bug breaking gpu lockup recovery. The fix is not allowing radeon_fence_driver_check_lockup to take exclusive_lock, and kill it during lockup recovery instead. --- drivers/gpu/drm/radeon/radeon.h|3

[Nouveau] [PATCH 07/19] drm/ttm: kill fence_lock

No users are left, kill it off! :D Conversion to the reservation api is next on the list, after that the functionality can be restored with rcu. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++--- drivers/gpu/drm

[Nouveau] [PATCH 08/19] drm/nouveau: rework to new fence interface

From: Maarten Lankhorst maarten.lankho...@ubuntu.com Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/core/core/event.c |4 drivers/gpu/drm/nouveau/nouveau_bo.c |6 drivers/gpu/drm/nouveau/nouveau_display.c |4 drivers/gpu/drm

[Nouveau] [PATCH 11/19] drm/radeon: use common fence implementation for fences, v2

on the global fence_queue to pick up gpu resets. - Process all fences in radeon_gpu_reset after reset to close a race with the trylock in enable_signaling. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/radeon/radeon.h | 18 +- drivers/gpu/drm

[Nouveau] [PATCH 10/19] drm/radeon: add timeout argument to radeon_fence_wait_seq

This makes it possible to wait for a specific amount of time, rather than wait until infinity. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Reviewed-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon_fence.c | 50

[Nouveau] [PATCH 17/19] drm/radeon: use rcu waits in some ioctls

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/radeon/radeon_gem.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index d09650c1d720

[Nouveau] [PATCH 14/19] drm/vmwgfx: rework to new fence interface

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 299 ++ drivers/gpu/drm/vmwgfx/vmwgfx_fence.h| 29 ++- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c

[Nouveau] [PATCH 16/19] drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep

With the conversion to the reservation api this should be safe. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_gem.c | 28 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/nouveau

[Nouveau] [PATCH 15/19] drm/ttm: flip the switch, and convert to dma_fence

--- drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +--- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +--- drivers/gpu/drm/nouveau/nouveau_fence.h |2 drivers/gpu/drm/nouveau/nouveau_gem.c| 16 ++- drivers/gpu/drm/qxl/qxl_debugfs.c|6 +

Re: [Nouveau] [PATCH 00/17] Convert TTM to the new fence interface. v2

op 31-07-14 17:30, Maarten Lankhorst schreef: This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking

[Nouveau] [PATCH 19/19] drm/ttm: use rcu in core ttm

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/ttm/ttm_bo.c | 76 +++--- 1 file changed, 13 insertions(+), 63 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 9d36cffad3b7

[Nouveau] [PATCH 13/19] drm/vmwgfx: get rid of different types of fence_flags entirely

Only one type was ever used. This is needed to simplify the fence support in the next commit. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |5 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 - drivers/gpu/drm/vmwgfx

[Nouveau] [PATCH 18/19] drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index

[Nouveau] [PATCH 02/19] drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers

It seems some drivers really want this as a parameter, like vmwgfx. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/qxl/qxl_release.c|2 +- drivers/gpu/drm/radeon/radeon_object.c |2 +- drivers/gpu/drm/radeon/radeon_uvd.c |2

[Nouveau] [PATCH] libdrm: hide all private symbols

omap/exynos: unchanged as far as I can tell Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- diff --git a/exynos/Makefile.am b/exynos/Makefile.am index 0a2663a..0cd753d 100644 --- a/exynos/Makefile.am +++ b/exynos/Makefile.am @@ -7,7 +7,8 @@ AM_CFLAGS

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 23-07-14 08:52, Christian König schreef: Am 23.07.2014 08:40, schrieb Maarten Lankhorst: op 22-07-14 17:59, Christian König schreef: Am 22.07.2014 17:42, schrieb Daniel Vetter: On Tue, Jul 22, 2014 at 5:35 PM, Christian König christian.koe...@amd.com wrote: Drivers exporting fences need

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 23-07-14 09:15, Christian König schreef: Am 23.07.2014 09:09, schrieb Daniel Vetter: On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 23-07-14 09:37, Christian König schreef: Am 23.07.2014 09:31, schrieb Daniel Vetter: On Wed, Jul 23, 2014 at 9:26 AM, Christian König deathsim...@vodafone.de wrote: It's not a locking problem I'm talking about here. Radeons lockup handling kicks in when anything calls into the driver from

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 23-07-14 10:20, Christian König schreef: Am 23.07.2014 10:07, schrieb Daniel Vetter: On Wed, Jul 23, 2014 at 9:58 AM, Christian König deathsim...@vodafone.de wrote: Just imagine an application using prime is locking up Radeon and because of that gets killed by the user. Nothing else in the

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 23-07-14 11:36, Christian König schreef: Am 23.07.2014 11:30, schrieb Daniel Vetter: On Wed, Jul 23, 2014 at 11:27 AM, Christian König christian.koe...@amd.com wrote: You submit a job to the hardware and then block the job to wait for radeon to be finished? Well than this would indeed

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 23-07-14 11:47, Christian König schreef: Am 23.07.2014 11:44, schrieb Daniel Vetter: On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: The scheduler needs to keep track of a lot of fences, so I think we'll have to register callbacks, not a simple wait function.

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 23-07-14 14:36, Christian König schreef: Am 23.07.2014 12:52, schrieb Daniel Vetter: On Wed, Jul 23, 2014 at 12:13 PM, Christian König christian.koe...@amd.com wrote: And the dma-buf would still have fences belonging to both drivers, and it would still call from outside the driver.

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 23-07-14 15:16, Maarten Lankhorst schreef: op 23-07-14 14:36, Christian König schreef: Am 23.07.2014 12:52, schrieb Daniel Vetter: On Wed, Jul 23, 2014 at 12:13 PM, Christian König christian.koe...@amd.com wrote: And the dma-buf would still have fences belonging to both drivers

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

Lankhorst maarten.lankho...@canonical.com wrote: Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/radeon/radeon.h| 15 +- drivers/gpu/drm/radeon/radeon_device.c | 60 - drivers/gpu/drm/radeon/radeon_fence.c | 223

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 22-07-14 16:24, Christian König schreef: No, you really shouldn't be doing much in the check anyway, it's meant to be a lightweight check. If you're not ready yet because of a lockup simply return not signaled yet. It's not only the lockup case from radeon I have in mind here. For

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

:13AM +0200, Christian König wrote: Am 22.07.2014 06:05, schrieb Dave Airlie: On 9 July 2014 22:29, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/radeon/radeon.h| 15 +- drivers/gpu/drm

Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 22-07-14 16:39, Christian König schreef: Am 22.07.2014 16:27, schrieb Maarten Lankhorst: op 22-07-14 16:24, Christian König schreef: No, you really shouldn't be doing much in the check anyway, it's meant to be a lightweight check. If you're not ready yet because of a lockup simply return

[Nouveau] [PATCH 05/17] drm/ttm: call ttm_bo_wait while inside a reservation

This is the last remaining function that doesn't use the reservation lock completely to fence off access to a buffer. --- drivers/gpu/drm/ttm/ttm_bo.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

[Nouveau] [PATCH 13/17] drm/ttm: flip the switch, and convert to dma_fence

--- drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +--- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +--- drivers/gpu/drm/nouveau/nouveau_fence.h |2 drivers/gpu/drm/nouveau/nouveau_gem.c| 16 ++- drivers/gpu/drm/qxl/qxl_debugfs.c|6 +

[Nouveau] [PATCH 10/17] drm/qxl: rework to new fence interface

Final driver! \o/ This is not a proper dma_fence because the hardware may never signal anything, so don't use dma-buf with qxl, ever. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/qxl/Makefile |2 drivers/gpu/drm/qxl/qxl_cmd.c |5

[Nouveau] [PATCH 00/17] Convert TTM to the new fence interface.

available instead, and the extra reservations can be dropped again. :-) I've done at least basic testing on all the drivers I've converted at some point, but more testing is definitely welcomed! --- Maarten Lankhorst (17): drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers

[Nouveau] [PATCH 01/17] drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers

It seems some drivers really want this as a parameter, like vmwgfx. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/qxl/qxl_release.c|2 +- drivers/gpu/drm/radeon/radeon_object.c |2 +- drivers/gpu/drm/radeon/radeon_uvd.c |2

[Nouveau] [PATCH 06/17] drm/ttm: kill fence_lock

No users are left, kill it off! :D Conversion to the reservation api is next on the list, after that the functionality can be restored with rcu. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++--- drivers/gpu/drm

  1   2   3   >