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
: 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
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 |
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
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
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
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
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
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
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
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
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 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
>
> 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
__
Hey,
Op 19-08-13 20:12, Peter Hurley schreef:
> On 08/12/2013 07:50 AM, Maarten Lankhorst wrote:
>> This fixes a deadlock inversion when vblank is enabled/disabled by drm.
>> &dev->vblank_time_lock is always taken when the vblank state is toggled,
>> which caused a de
Op 22-08-13 02:10, Ilia Mirkin schreef:
> The code expects non-VRAM mem nodes to have a pages list. If that's not
> set, it will do a null deref down the line. Warn on that condition and
> return an error.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>
> Reported-by: Pasi Kärkkäinen
Op 28-08-13 08:29, Pasi Kärkkäinen schreef:
> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
>> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
>>> Op 22-08-13 02:10, Ilia Mirkin schreef:
>>>> The code expects non-VRAM mem nodes t
This increases the chance slightly that recovery from lockup can happen
succesfully.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nv84_fence.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c
b/drivers/gpu/drm/nouveau
I was getting a order 4 allocation failure from kmalloc when testing some game
after a few days uptime with some suspend/resumes. For big allocations vmalloc
should be used instead.
Also limit size more aggressively to 256 KiB.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau
There are a lot of places that allocate multiples of 1000,
but do not set alignment correctly and still require this
alignment implicitly or explicitly.
---
drivers/gpu/drm/nouveau/core/core/gpuobj.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/core/gpuo
nv50_bo_move_m2mf might copy to tiled gart, in which case linear copy is not
appropriate.
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 42
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nou
I don't see why the display engine would need write access to the entirety of
vram, when read-only access is enough.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nv50_display.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gp
Op 03-09-13 16:20, Pasi Kärkkäinen schreef:
> On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote:
>> Op 28-08-13 08:29, Pasi Kärkkäinen schreef:
>>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
>>>> On Thu, Aug 22, 2013 at 09:12
Op 04-09-13 05:41, Ben Skeggs schreef:
> On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> wrote:
>> Op 22-08-13 02:10, Ilia Mirkin schreef:
>>> The code expects non-VRAM mem nodes to have a pages list. If that's not
>>> set, it will do a null deref down t
Op 04-09-13 05:34, Ben Skeggs schreef:
> On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
> wrote:
>> There are a lot of places that allocate multiples of 1000,
>> but do not set alignment correctly and still require this
>> alignment implicitly or explicitly.
> Th
Op 04-09-13 05:31, Ben Skeggs schreef:
> On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
> wrote:
>> I was getting a order 4 allocation failure from kmalloc when testing some
>> game
>> after a few days uptime with some suspend/resumes. For big allocations
>
Op 04-09-13 05:21, Ben Skeggs schreef:
> On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
> wrote:
>> This increases the chance slightly that recovery from lockup can happen
>> succesfully.
> I'd *really* love to see proof of this. When channels die, all
> out
Op 04-09-13 03:24, Ben Skeggs schreef:
> On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
> wrote:
>> Op 15-07-13 08:05, Ben Skeggs schreef:
>>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
>>> wrote:
>>>> I have no idea what this bogus
Hey,
Op 24-09-13 06:44, Andy Ritger schreef:
> Hi Nouveau developers,
>
> NVIDIA is releasing public documentation on certain aspects of our GPUs,
> with the intent to address areas that impact the out-of-the-box usability
> of NVIDIA GPUs with Nouveau. We intend to provide more documentation
> o
only up to D3hot
is allowed.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 89efeff..566e544 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -945,7 +945,7 @@ s
Signed-off-by: Maarten Lankhorst
Cc: # v3.7+
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1551,7 +1579,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo
op 11-11-13 16:31, Jerry Cooperstein schreef:
> Hi:
>
> commit bd9c5a2016307164c419c5e24a46921c10e620a0
>
> (drm/nouveau: require contiguous bo for framebuffer)
> produces about 2000 lines of
>
> nouveau E[ DRM] framebuffer requires contiguous bo
>
> on system boot and more on shutdown, but I d
op 11-11-13 17:05, Jerry Cooperstein schreef:
> On 11/11/2013 09:57 AM, Maarten Lankhorst wrote:
>> op 11-11-13 16:31, Jerry Cooperstein schreef:
>>> Hi:
>>>
>>> commit bd9c5a2016307164c419c5e24a46921c10e620a0
>>>
>>> (drm/nouveau: require
From: Maarten Lankhorst
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Relocations are handled by trying with
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 9ecb874..bb3734d 100644
--- a/drivers/gpu
From: Maarten Lankhorst
Make sure that buffers are always aligned.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 40 +++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b
From: Maarten Lankhorst
No need to map the same vma multiple times.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_fence.h | 4 ++--
drivers/gpu/drm/nouveau/nv50_display.c | 13 ++---
drivers/gpu/drm/nouveau/nv50_display.h | 2 +-
drivers/gpu/drm/nouveau
From: Maarten Lankhorst
Map the GART to the bar and use that mapping, to hide all the tiling details
from users.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c | 5 -
drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 5 -
drivers/gpu/drm/nouveau
From: Dan Carpenter
We care about the upper 32 bits here so we have to use 1ULL instead of 1
to avoid a shift wrapping bug.
Signed-off-by: Dan Carpenter
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
From: Maarten Lankhorst
Commit de7b7d59d54852c introduced tiled GART, but a linear copy is
still performed. This may result in errors on eviction, fix it by
checking tiling from memtype.
Signed-off-by: Maarten Lankhorst
Cc: sta...@vger.kernel.org #3.10+
---
drivers/gpu/drm/nouveau
Coefficients are based on the formula:
uV = 0.1 * arg[0] + 150.5 * arg[1] + 22.65025 * arg[2]
It seems to be rounded downwards. I have no idea why the voltage isn't
specified in the bios directly.
Signed-off-by: Maarten Lankhorst
diff --git a/drivers/gpu/drm/nouveau/core/subdev
Not holding the mutex potentially causes corruption of the kernel
channel when page flipping.
Cc: sta...@vger.kernel.org #3.13
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 29c3efdfc7dd
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 900fae01793e..20959e445d05 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -153,10 +153,12 @@ nouveau_abi16_
Fixes a regression introduced by d5c1e84b3a130f0
"drm/nouveau: hold mutex while syncing to kernel channel".
Cc: sta...@vger.kernel.org #3.13
Reported-by: Fengguang Wu
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/d
t;device)->card_type < NV_50 || !node->memtype)
/* untiled */
break;
/* fallthrough, tiled memory */
Acked-by: Maarten Lankhorst
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
This commit breaks loading nouveau on my optimus laptop. I get the following
spam in dmesg:
[ 24.102587] MXM: GUID detected in BIOS
[ 24.103167] ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x3) is
beyond end of object (length 0x0) (20131218/exoparg2-420)
[ 24.103242] ACPI Error:
: Maarten Lankhorst
---
---
nouveau/nouveau.c | 108 +++---
nouveau/private.h | 3 +-
2 files changed, 89 insertions(+), 22 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index ee7893b..75dfb0e 100644
--- a/nouveau/nouveau.c
+++ b
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
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon.h| 15 +--
drivers/gpu/drm/radeon/radeon_device.c |1
drivers/gpu/drm/radeon/radeon_fence.c | 189 +---
3 files changed, 153 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu
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 | 434
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 |
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 31c4a6dd722d..6fe1f4bf37ed 100644
--- a/drivers
---
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
are converted to the fence api, fence_lock is removed
and rcu is used in its place.
qxl is the first driver to use shared fence slots, but when these patches
are applied it's easy to convert nouveau too. I've done it as part of the
cross-device gpu synchronization patch series.
--
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
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
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
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
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
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 20a1a866ceeb..79e950df3018 100644
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
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
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
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
op 14-05-14 17:29, Christian König schreef:
+/* did fence get signaled after we enabled the sw irq? */
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq) {
+radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring);
+return false;
+}
+
+fen
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian König schreef:
+/* did fence get signaled after we enabled the sw irq? */
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) &
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian König schreef:
+/* did fence get signaled after we enabled the sw irq
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11
op 15-05-14 18:13, Christian König schreef:
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
op 15-05-14 18:13, Christian König schreef:
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15
op 19-05-14 14:30, Christian König schreef:
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole approach collides with the way we do reset
handling from a
Changes since v1:
- Fixed interaction with reset handling.
+ Use exclusive_lock, either with trylock or blocking.
+ Bump sw irq refcount in the recovery function to prevent fiddling
with irq registers during gpu recovery.
- Add radeon lockup detection to the default fence wait function.
--
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst
---
Splitted out version, I've noticed that I forgot to convert
radeon_fence_wait_empty to long r, fixed.
drivers/gpu/drm/radeon/radeon_fence.c
Signed-off-by: Maarten Lankhorst
---
Oops, changed unsigned long in __radeon_fence_wait to long, fixing a subtle
bug.
drivers/gpu/drm/radeon/radeon.h| 15 +--
drivers/gpu/drm/radeon/radeon_device.c | 60 -
drivers/gpu/drm/radeon/radeon_fence.c | 223
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 | 60 +++
1 file changed, 40 insertions(+), 20 deletions
Signed-off-by: Maarten Lankhorst
---
src/gallium/drivers/nouveau/nouveau_fence.c | 76 -
src/gallium/drivers/nouveau/nouveau_fence.h | 22 +--
src/gallium/drivers/nouveau/nouveau_screen.c| 9 +++
src/gallium/drivers/nouveau/nouveau_screen.h| 14
Signed-off-by: Maarten Lankhorst
---
src/gallium/drivers/nouveau/nouveau_fence.c | 76 -
src/gallium/drivers/nouveau/nouveau_fence.h | 22 +--
src/gallium/drivers/nouveau/nouveau_screen.c| 9 +++
src/gallium/drivers/nouveau/nouveau_screen.h| 14
If init doesn't run then disp->outp might not be initialized, resulting in an
oops.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c
b/drivers/gpu/drm/nouveau/core/engine/disp/base.c
index c41f656abe64..9c38c5e40500 100644
--- a/drivers
Hey,
This patch causes a regression on my display-less nvd7.
Commenting out the aux, aux_stat and aux_mask members in nvd0_i2c_oclass fixes
boot, and makes things work normally again.
broken dmesg:
[ 40.314470] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch -
Found [Buffer], A
op 21-06-14 14:12, Ilia Mirkin schreef:
> On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst
> 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.
&g
op 23-06-14 09:24, Ben Skeggs schreef:
> On Mon, Jun 23, 2014 at 5:17 PM, Maarten Lankhorst
> wrote:
>> op 21-06-14 14:12, Ilia Mirkin schreef:
>>> On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst
>>> wrote:
>>>> nv30 seems to not support dma
op 24-06-14 14:23, Alexandre Courbot schreef:
> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot
> wrote:
>> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>
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
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 20a1a866ceeb..79e950df3018 100644
---
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
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
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_reser
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
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
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 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 |
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 | 60 ++---
1 file changed, 40 insertions(+), 20 deletions
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
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
1 - 100 of 242 matches
Mail list logo
