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 sh
s in page 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
ma_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
>
> 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
__
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 have a
: 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
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
> interested
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 atomic
le swap_state changes.
Signed-off-by: Maarten Lankhorst
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nv50_display.c | 72 +-
1 file changed, 37 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/dr
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Maarten Lankhorst
Link:
http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-2-maarten.lankho...@linux.intel.com
Reviewed-by: Sean Paul
[mlankhorst: Use if (ret) to remove the goto in success case.]
R
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
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Link:
http://patchwork.freedesktop.org/patch/msgid
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
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
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
---
drivers
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
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nv50_display.c | 5 -
1 file
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nv50_display.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_displ
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
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
tel-...@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
---
drivers/gpu/drm/drm_atomic_helper.c |
: 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
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
drivers/gpu/drm/drm_atomic_helper.c | 18
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
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
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: nouveau@lists.freedesktop.org
> ---
> drivers/gpu/drm/nouveau/nouveau_prime.c | 2
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
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 #irc
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 51 ++
drivers
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
---
drivers/gpu/drm/drm_atomic_helper.c | 51 ++
drivers/gpu/drm/nouveau
-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
Il
Op 23-05-15 om 08:45 schreef Alexandre Courbot:
> On Fri, May 22, 2015 at 3:23 AM, Martin Peres wrote:
>> On 21/05/2015 11:47, Ben Skeggs wrote:
>>> On 21 May 2015 at 16:08, Alexandre Courbot wrote:
Add a flag allowing Nouveau to specify that an object should be coherent
at allocation t
Op 15-05-15 om 09:11 schreef Alexandre Courbot:
> Re-pinging Marteen on an email address that still exists :P
>
> On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot wrote:
>> On Sun, Mar 15, 2015 at 5:41 PM, Alexandre Courbot
>> wrote:
>>> On 03/14/2015 04:
nouveau_allocate_surface the effect is still the same.
Signed-off-by: Maarten Lankhorst
---
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/nouveau_dri2.c b/
in
nouveau_allocate_surface the effect is still the same.
Signed-off-by: Maarten Lankhorst
---
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 in
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 drive
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
---
nouveau/nouveau.c | 46 ++-
ncreases 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
Reviewed-By: Emil Velikov
---
configure.ac | 1 +
nouveau/nouveau.c | 69 ++--
Signed-off-by: Maarten Lankhorst
---
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 atomic_set(x, val) ((x)->ato
Signed-off-by: Maarten Lankhorst
---
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)->atomic)
# define atomic_
On 25-02-15 15:14, Emil Velikov wrote:
> On 24 February 2015 at 09:01, Maarten Lankhorst
> wrote:
>> While I've closed off most races in a previous patch, a small race still
>> existed
>> where importing then unreffing cound cause an invalid bo. Add a test fo
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 safe
Hey,
On 25-02-15 18:05, Ilia Mirkin wrote:
> On Wed, Feb 25, 2015 at 11:59 AM, Patrick Baggett
> 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. Basi
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 <
>&g
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 schreef Emil Velikov:
>>> On 24 February 2015 at 09:01, Maarten Lankhorst
>>> wrote:
>&g
Op 25-02-15 om 15:11 schreef Emil Velikov:
> On 24 February 2015 at 09:01, Maarten Lankhorst
> 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
efcount was increased to 1 and skip deletion from list
and closing the handle.
Signed-off-by: Maarten Lankhorst
---
configure.ac | 1 +
nouveau/nouveau.c | 69 +++
tests/Makefile.am | 4 ++
tests/nouveau/.gitignore | 1 +
tests/nouveau/Makefi
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
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index
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
Signed-off-by: Maarten Lankhorst
---
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
@@ -370,6 +370,7
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
>>> t
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 obj
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
> ---
> drm/nouveau_bo.c | 8
> drm/nouveau_bo.h | 4 ++--
> drm/nouveau_drm.c
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
> ---
> drivers/gpu/drm/drm_prime.c | 41 +
Op 23-09-14 om 07:35 schreef Ben Skeggs:
> On Tue, Sep 23, 2014 at 2:23 AM, Ted Percival wrote:
>> On 09/22/2014 03:08 AM, Maarten Lankhorst wrote:
>>> This fixes a regression introduced by "drm/nouveau: rework to new fence
>>> interface"
>>> (commi
paround in case 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
Signed-off-by: Maarten Lankhorst
---
diff
Allows userspace to detect shared fences are supported.
Signed-off-by: Maarten Lankhorst
---
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's vdpau 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]) {
> d
-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 scheduling
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:
>>>&g
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:
>>>>>&
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
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 mean
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.
>>>
>>> A
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 schr
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
>> ---
>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
>> allowing radeon_fence_driver_check_lockup to take exclusive_
Only one type was ever used. This is needed to simplify the fence
support in the next commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |5 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14
Signed-off-by: Maarten Lankhorst
---
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 f0a689ba9685..a43930162eb6 100644
It seems some drivers really want this as a parameter,
like vmwgfx.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c|2 +-
drivers/gpu/drm/radeon/radeon_object.c |2 +-
drivers/gpu/drm/radeon/radeon_uvd.c |2 +-
drivers/gpu/drm/radeon/radeon_vm.c
Signed-off-by: Maarten Lankhorst
---
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..d119ae4419d4 100644
--- a/drivers
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 res
Signed-off-by: Maarten Lankhorst
---
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 |9 -
4 files changed, 200
---
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 +
drivers/gpu/drm/qxl/qxl_drv
Signed-off-by: Maarten Lankhorst
---
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..7ba883843668 100644
--- a/drivers/gpu
With the conversion to the reservation api this should be safe.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu
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
---
drivers/gpu/drm/radeon/radeon.h | 18 +-
drivers/gpu/drm/radeon/radeon_device.c | 22
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
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/nouveau_fence.c | 435
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_fence.c | 50 -
1 file changed, 30 insertions(+), 20 deletions
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
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++---
drivers/gpu/drm/nouveau/nouveau_display.c |6
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 b/drivers/gpu/drm/tt
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 a/drivers/gpu/drm/nouveau/nouve
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
---
drivers/gpu/drm/qxl/Makefile |2
drivers/gpu/drm/qxl/qxl_cmd.c |5 -
drivers/gpu/drm/qxl/qxl_debu
Signed-off-by: Maarten Lankhorst
---
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 +
drivers/gpu/drm/radeon
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
---
drivers/gpu/drm/qxl/qxl_release.c |
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
fence_is_signaled callback should support being run in
atomic context, but not in irq context.
Signed-off-by: Maarten Lankhorst
---
include/linux/fence.h | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
ade things 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
dr
fence_is_signaled callback should support being run in
atomic context, but not in irq context.
Signed-off-by: Maarten Lankhorst
---
include/linux/fence.h | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
This hides all the abi16_* functions and the nouveau_debug variable,
they should have been private to begin with.
Signed-off-by: Maarten Lankhorst
---
nouveau/Makefile.am | 1 +
nouveau/bufctx.c| 10 +-
nouveau/nouveau.c | 40
nouveau
omap/exynos: unchanged as far as I can tell
Signed-off-by: Maarten Lankhorst
---
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 = \
libdrm_exynos_la_LTLIBRARIES = libdrm_exynos.la
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
>>> wrote:
>>>>> And the dma-buf would still have fences bel
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
>> wrote:
And the dma-buf would still have fences belonging to both drivers, and it
would still call from outside the driver.
>>>
>>> Calling fro
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
>> 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. We must kee
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
>> 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 require a hardware
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
>> wrote:
>>> Just imagine an application using prime is locking up Radeon and because of
>>> that gets killed by the user. Nothing else in the system would
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
>> wrote:
>>> It's not a locking problem I'm talking about here. Radeons lockup handling
>>> kicks in when anything calls into the driver from the outside,
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
>> wrote:
>>>> Can we somehow avoid the need to call fence_signal() at all? The
>>>> interrupts at least on
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
>>>> wro
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
>> wrote:
>>> Drivers exporting fences need to provide a fence->signaled and a fence->wait
>>> function, everything else like fence->enable_signaling or cal
Hey,
op 22-07-14 17:02, Christian König schreef:
> Am 22.07.2014 16:44, schrieb Maarten Lankhorst:
>> op 22-07-14 15:45, Christian König schreef:
>>> Am 22.07.2014 15:26, schrieb Daniel Vetter:
>>>> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian König wr
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.
er wrote:
>>>>> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian König wrote:
>>>>>> Am 22.07.2014 06:05, schrieb Dave Airlie:
>>>>>>> On 9 July 2014 22:29, Maarten Lankhorst
>>>>>>> wrote:
>>>>>>>>
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 u
ie:
>>>>> On 9 July 2014 22:29, Maarten Lankhorst
>>>>> wrote:
>>>>>> Signed-off-by: Maarten Lankhorst
>>>>>> ---
>>>>>> drivers/gpu/drm/radeon/radeon.h| 15 +-
>&
Hey,
op 22-07-14 06:05, Dave Airlie schreef:
> On 9 July 2014 22:29, Maarten Lankhorst
> wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/radeon/radeon.h| 15 +-
>> drivers/gpu/drm/radeon/radeon_device.c | 60 -
>> d
_DMA1_INDEX: return "radeon.dma1";
>> +case R600_RING_TYPE_UVD_INDEX: return "radeon.uvd";
> Radeon supports vce rings on newer ascis. Probably want to add the case for
> those here too.
>
> Alex
>
Indeed, how about this?
--8<---
Signed-of
1 - 100 of 242 matches
Mail list logo
