drmmode_crtc_scanout_free
Keith Packard (3):
modesetting: Record non-desktop kernel property at PreInit time
modesetting: Create CONNECTOR_ID properties for outputs [v2]
Add RandR leases support
Michel Dänzer (55):
Bail from dri2_create_buffer2 if we can't get a pixmap
glamor: Bail
on output_get_property
Enable setting of color properties via RandR
Compose non-legacy with legacy regamma LUT
Also compose LUT when setting legacy gamma
Michel Dänzer (48):
Post-release version bump
Ignore AMDGPU_DRM_QUEUE_ERROR (0) in amdgpu_drm_abort_entry
Track DRM event
pulation with list helper, it
> should not trigger the list corruption. The usage of those helpers should
> ensure the list operation safely...
There's nothing the helpers can do about being passed in pointers to
stack memory. It's a bug in the code using the helpers.
--
Earthling Miche
reservation_object_assert_held(pos->first->resv);
> + reservation_object_assert_held(pos->last->resv);
> +
> lru = >first->bdev->glob->swap_lru[i];
> - ttm_bo_bulk_move_helper(>swap[i], lru, true);
>
From: Michel Dänzer
We would crash due to dereferencing the NULL mode_res->crtc pointer.
Bugzilla: https://bugs.freedesktop.org/107913
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/drmmode_display.c b/src/drmmode_displa
On 2018-09-12 2:48 p.m., Kazlauskas, Nicholas wrote:
> On 09/12/2018 04:13 AM, Michel Dänzer wrote:
>> On 2018-09-11 6:18 p.m., Nicholas Kazlauskas wrote:
>>> These patches are part of a proposed new interface for supporting
>>> variable refresh rate via DR
From: Michel Dänzer
The entries were only initialized once in amdgpu_sa_bo_new. If a fence
wasn't signalled yet in the first amdgpu_sa_bo_next_hole call, but then
got signalled before a later amdgpu_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting
ncobj_reset
> amdgpu_cs_syncobj_signal
> amdgpu_cs_syncobj_wait
> +amdgpu_cs_syncobj_timeline_wait
> +amdgpu_cs_syncobj_query
> amdgpu_cs_wait_fences
> amdgpu_cs_wait_semaphore
> amdgpu_device_deinitialize
This file should be sorted in lexical order.
--
Earthling Michel Dänzer
into this after the upcoming Xorg driver 18.1 releases. Or I
can give guidance if one of you wants to look into it.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
ernally by kernel clients, including gfx,
> - * uvd, etc. for kernel managed allocations used by the GPU.
> - *
> - */
This comment shouldn't be removed, should it? Otherwise the commit log
needs to explain this, and the reference in Documentation/gpu/amdgpu.rst
needs to be removed as well.
--
Earthling Michel
On 2018-09-10 5:58 p.m., Michel Dänzer wrote:
> On 2018-09-10 1:14 p.m., Aaron Liu wrote:
>> Add gamma_lut/degamma_lut/ctm checking before pushing
>> staged color management properties on the CRTC.
>> If above object is NULL, return directly.
>
> (How) were y
On 2018-09-11 10:20 a.m., Christian König wrote:
> Am 11.09.2018 um 09:55 schrieb Michel Dänzer:
>> On 2018-09-11 9:46 a.m., Christian König wrote:
>>> Am 11.09.2018 um 09:37 schrieb Michel Dänzer:
>>>> On 2018-09-11 8:49 a.m., Christian König wrote:
>>>&
On 2018-09-11 9:46 a.m., Christian König wrote:
> Am 11.09.2018 um 09:37 schrieb Michel Dänzer:
>> On 2018-09-11 8:49 a.m., Christian König wrote:
>>> But another question: Why do you want to clear VRAM on allocation? We
>>> perfectly support allocating VRAM wi
ring when userspace sets AMDGPU_GEM_CREATE_VRAM_CLEARED
would break the userspace ABI, so that's no go.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
;
(How) were you able to actually trigger this condition in practice? The
only way I could imagine is via drmmode_output_set_property, in which
case I think it would be better to guard all the *cm_* related code
there with
if (drmmode_cm_enabled(drmmode_output->drmmode)) {
...
q=8322, emitted seq=8325
> [drm] GPU recovery disabled.
>
> I tested that it doesn't happen with 4.17.14 kernel.
Can you bisect between 4.17 and 4.18?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
ter
> + * @adev: drm device pointer
> * @pasid: PASID identifier for VM
> * @task_info: task_info to fill.
> */
>
Queued in the amdgpu tree (with fixed spelling of "warnings"), thanks!
--
Earthling Michel Dänzer
From: Michel Dänzer
No need to process any events in that case.
(Ported from amdgpu commit ca5eb9894fff153c0a1df7bdc4a4745713309e27)
Signed-off-by: Michel Dänzer
---
src/radeon_drm_queue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/radeon_drm_queue.c b/src
From: Michel Dänzer
Fixes server reset.
Pointed out by clang:
../../src/radeon_kms.c:2721:9: warning: variable 'pitch' is used uninitialized
whenever 'if' condition is false [-Wsometimes-uninitialized]
if (!info->front_buffer) {
^~~
../../src/radeon_kms.c:2765
From: Michel Dänzer
We left entries without a handler hook in the list, so the list could
keep taking longer to process and use up more memory.
(Ported from amdgpu commit 7eea3e2cd74eed22e982319144e18ae5b1087b78)
Signed-off-by: Michel Dänzer
---
src/radeon_drm_queue.c | 2 +-
1 file changed
From: Michel Dänzer
drm_wait_pending_flip can get called from drm_handle_event, in which
case xorg_list_for_each_entry_safe can end up processing the same entry
in both. To avoid this, just process the first list entry until the list
is empty.
(Ported from amdgpu commit
From: Michel Dänzer
No need to process any events in that case.
v2:
* Re-check drmmode_crtc->flip_pending after processing each event
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/amdgpu_drm_queue.c b/
o.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -438,10 +438,9 @@ int amdgpu_bo_free(amdgpu_bo_handle buf_handle)
> return 0;
> }
>
> -int amdgpu_bo_inc_ref(amdgpu_bo_handle bo)
> +void amdgpu_bo_inc_ref(amdgpu_bo_handle bo)
> {
> atomic_
pu_bo_handle bo)
> +{
> + atomic_inc(>refcount);
> + return 0;
> +}
What's the point of having a non-void return value that's always 0?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X
On 2018-08-31 3:10 p.m., Christian König wrote:
> Add BOs to the idle state again and correctly clear the flag when
> new BOs are added.
>
> Signed-off-by: Christian König
Typo in the shortlog: bulk_moveavle -> bulk_moveable
The series is
Tested-by: Michel Dänzer
T
tion(, , list);
So the problem was that the first list_cut_position call could result in
list2 pointing to la-la-land? Good catch!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 2018-08-31 4:46 p.m., Thomas Hellstrom wrote:
> On 08/31/2018 04:38 PM, Michel Dänzer wrote:
>> [ Adding the amd-gfx list ]
>>
>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:
>>> On 08/31/2018 02:30 PM, Emil Velikov wrote:
>>>> On 31 August 2
ndalone vmwgfx is using dynamic major allocation.
I wonder why I haven't heard of any of these issues with the standalone
version of amdgpu shipped in packaged AMD releases. Does that also use a
different major number? If yes, maybe it's just that nobody has tried
Xwayland clients with
From: Michel Dänzer
The crtc->gamma_lut values aren't initialized yet at this point, and
the property values are pushed again from drmmode_setup_colormap
anyway.
Fixes intermittent flicker due to random gamma LUT values during server
startup.
Signed-off-by: Michel Dänzer
---
change of that commit in
this patch. Probably better to wait until all the bugs have been fixed,
then re-apply the "move PD/PT bos on LRU again" patch.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Me
*buf_handle = NULL;
> *offset_in_bo = 0;
> + r = -EINVAL;
I think -ENOENT would be better, to differentiate this error from
passing invalid pointer / size parameters.
With that,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
ay, with this patch, the attached warning dumps appear in dmesg
about 1000 times per second at the GDM login prompt, can't even attempt
to run piglit. Something else is needed, I'm afraid.
In case it's relevant, note that my development machine has a secondary
Turks card install
From: Michel Dänzer
drm_wait_pending_flip can get called from drm_handle_event, in which
case xorg_list_for_each_entry_safe can end up processing the same entry
in both. To avoid this, just process the first list entry until the list
is empty.
Signed-off-by: Michel Dänzer
---
src
From: Michel Dänzer
We left entries without a handler hook in the list, so the list could
keep taking longer to process and use up more memory.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amdgpu_drm_queue.c b
From: Michel Dänzer
No need to process any events in that case.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amdgpu_drm_queue.c b/src/amdgpu_drm_queue.c
index ba841d1ef..61732b11c 100644
--- a/src/amdgpu_drm_queue.c
+++ b
From: Michel Dänzer
It means to stop using the shared pixmap backing.
(Ported from radeon commit 1799680f7bd84e0618f34f4c7486799521ddaf83)
Signed-off-by: Michel Dänzer
---
src/amdgpu_bo_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amdgpu_bo_helper.c b/src
From: Michel Dänzer
(Ported from radeon commit de88ea2755611bdcb18d91d8234d2ab5be8ff2e9)
Signed-off-by: Michel Dänzer
---
src/amdgpu_glamor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/amdgpu_glamor.c b/src/amdgpu_glamor.c
index 13d68fe36..699861f73 100644
On 2018-08-29 10:57 a.m., Christian König wrote:
> Am 29.08.2018 um 09:52 schrieb Michel Dänzer:
>> On 2018-08-28 7:03 p.m., Michel Dänzer wrote:
>>> On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>>>> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>>>>&g
On 2018-08-29 10:57 a.m., Christian König wrote:
> Am 29.08.2018 um 09:52 schrieb Michel Dänzer:
>> On 2018-08-28 7:03 p.m., Michel Dänzer wrote:
>>> On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>>>> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>>>>&g
On 2018-08-28 7:03 p.m., Michel Dänzer wrote:
> On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>>> The new bulk moving functionality is ready, the overhead of moving PD/PT
>>> bos to
>>> LRU is fixed. So move t
d/amdgpu/amdgpu_ucode.c
> @@ -277,6 +277,7 @@ amdgpu_ucode_get_load_type(struct amdgpu_device *adev,
> int load_type)
> case CHIP_PITCAIRN:
> case CHIP_VERDE:
> case CHIP_OLAND:
> + case CHIP_HAINAN:
> return AMDGPU_FW_LOAD_DIRECT;
> #endif
> #ifdef
On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>
> Hi Ray,
>
>
> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>> The new bulk moving functionality is ready, the overhead of moving PD/PT bos
>> to
>> LRU is fixed. So move them on LRU again.
>>
>>
; -{
> - switch (bo->tbo.mem.mem_type) {
> - case TTM_PL_TT: return amdgpu_gtt_mgr_has_gart_addr(>tbo.mem);
> - case TTM_PL_VRAM: return true;
> - default: return false;
> - }
> -}
> -
> /**
> * amdgpu_bo_in_cpu_visible_vram -
From: Michel Dänzer
Doing it earlier hits a WARN_ON_ONCE in amdgpu_bo_gpu_offset.
Fixes: "drm/amdgpu: remove gart.table_addr"
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 5 -
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 5 -
drivers/gpu/drm/amd/amdgp
change, I'm getting various badness when running piglit using
radeonsi on Bonaire, see the attached dmesg excerpt.
Reverting just this change on top of current amd-staging-drm-next avoids
the problem.
Looks like some list manipulation isn't sufficiently protected against
concurrent execution?
From: Michel Dänzer
Although normally it only warns about it, under some circumstances,
aclocal can error out if this directory doesn't exist.
Reported-by: John Lumby
(Cherry picked from radeon commit 7b01c10137aba24c8f61dd9b2a19ea257ad24371)
Signed-off-by: Michel Dänzer
---
.gitignore
From: Michel Dänzer
Older versions of autoconf only supported the former.
(Cherry picked from radeon commit cba8fe4d64819aaa8ba516aa68dbe6d2aa153046)
Signed-off-by: Michel Dänzer
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
fy_message_to_smu(adev, PPSMC_MSG_UVDPowerON);
This comment still seems inconsistent with the code.
Apart from that, this series is
Tested-by: Michel Dänzer
Thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
From: Michel Dänzer
It means to stop using the shared pixmap backing.
Fixes crash when changing PRIME slave output configuration.
Signed-off-by: Michel Dänzer
---
src/radeon_bo_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/radeon_bo_helper.c b/src/radeon_bo_helper.c
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/radeon_glamor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/radeon_glamor.c b/src/radeon_glamor.c
index c733d192d..bffc89ec6 100644
--- a/src/radeon_glamor.c
+++ b/src/radeon_glamor.c
@@ -402,11 +402,13
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/radeon.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/radeon.h b/src/radeon.h
index 1a1edb1ba..b1d5f5af4 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -772,11 +772,15 @@ static inline Bool
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/radeon_exa.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/radeon_exa.c b/src/radeon_exa.c
index 93c2f056c..268155ed7 100644
--- a/src/radeon_exa.c
+++ b/src/radeon_exa.c
@@ -296,11 +296,12 @@ Bool
From: Michel Dänzer
Although normally it only warns about it, under some circumstances,
aclocal can error out if this directory doesn't exist.
Signed-off-by: Michel Dänzer
---
.gitignore| 5 -
m4/.gitignore | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
create mode
From: Michel Dänzer
Older versions of autoconf only supported the former.
Signed-off-by: Michel Dänzer
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 444862f3b..b6da673ea 100644
--- a/configure.ac
+++ b/configure.ac
On 2018-08-23 2:59 p.m., Zhu, Rex wrote:
>> From: Michel Dänzer
>> On 2018-08-23 11:24 a.m., Rex Zhu wrote:
>>> Forgot to add vce pg support via smu for Kaveri/Mullins.
>>>
>>> Regresstion issue caused by
>>> 'commit 561a5c83
issue when loading amdkfd manually later),
see the attached kernel.log excerpt. This is also a regression in the
4.19 drm tree changes. It might be a separate issue, but TBH I don't
feel like another day or two bisecting right now. :)
Anyway, this series is
Tested-by: Michel Dä
rON);
> - kv_dpm_powergate_uvd(adev, false);
> + if (pi->caps_uvd_pg) /* power off the UVD block */
> + amdgpu_kv_notify_message_to_smu(adev, PPSMC_MSG_UVDPowerON);
The comment should say "power on", shouldn't it?
--
Earthling Michel Dänzer |
esktop.org/show_bug.cgi?id=107595
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Aug 21 10:20:37 thor kernel: [4.429726] [drm] amdgpu kernel modesetting enabled.
Aug 21 10:20:37 thor kernel: [
default "0x"
> + help
> + Modify this option to disable any IP block of amdgpu.
As I said before, IMO this doesn't belong upstream, as it's a workaround
for a downstream issue.
Also, this isn't generally usable on a system with multiple GPUs
supported by a
e 4.19
release. The relevant fixes were marked for backporting to stable, so
they should appear in future 4.18.y releases as well.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
e
there, or the driver is built into the kernel, but the firmware isn't
built into the kernel.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gf
support for display engine
>
> config DEBUG_KERNEL_DC
> bool "Enable kgdb break in DC"
>
Thanks Leo, Alex, Arnd et al for taking care of this! Apologies for the
trouble caused by my change, and for not helping much with the solution
(I
From: Michel Dänzer
We were always using the handle of the client provided FB, which
prevented RandR transforms from working, and could result in a black
screen.
Fixes: 740f0850f1e4 "Store FB for each CRTC in drmmode_flipdata_rec"
(Ported from amd
From: Michel Dänzer
Not needed anymore with the more robust mechanisms for preventing nested
drmHandleEvent calls introduced in the previous changes.
(Ported from amdgpu commit 85cd8eef0cbed7b409b07f58d76dacd34aa3ddea)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.h | 8
src
From: Michel Dänzer
And make radeon_drm_queue_handler not directly accessible outside of
radeon_drm_queue.c.
(Ported from amdgpu commit 0148283984c77f7a6e97026edc3093497547e0a4)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 4
src/radeon_dri2.c | 14 --
src
From: Michel Dänzer
Replacing the drmmode_crtc_wait_pending_event macro.
(Ported from amdgpu commit 6029794e8a35417faf825491a89b85f713c77fc1)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 18 --
src/drmmode_display.h | 4
src/radeon_drm_queue.c | 41
From: Michel Dänzer
Instead of processing DRM events directly from drmHandleEvent's
callbacks, there are three phases:
1. drmHandleEvent is called, and signalled events are re-queued to
_signalled lists from its callbacks.
2. Signalled page flip completion events are processed.
3. Signalled
From: Michel Dänzer
Replacing the drmmode_crtc_wait_pending_event macro.
(Ported from amdgpu commit 6029794e8a35417faf825491a89b85f713c77fc1)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 21 -
src/radeon_drm_queue.c | 13 +
src/radeon_drm_queue.h
On 2018-08-10 09:06 AM, Johannes Hirte wrote:
> On 2018 Jul 27, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> We were only storing the FB provided by the client, but on CRTCs with
>> TearFree enabled, we use a separate FB. This could cause
>> drmmode_flip_hand
From: Michel Dänzer
We were always using the handle of the client provided FB, which
prevented RandR transforms from working, and could result in a black
screen.
Fixes: 9b6782c821e0 "Store FB for each CRTC in drmmode_flipdata_rec"
Signed-off-by: Michel Dänzer
---
src/drmmode_dis
On 2018-08-15 03:07 AM, Zhang, Jerry (Junwei) wrote:
> On 08/14/2018 05:58 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Arithmetic using void* pointers isn't defined by the C standard, only as
>> a GCC extension. Avoids compiler warnings:
>>
>>
From: Michel Dänzer
Arithmetic using void* pointers isn't defined by the C standard, only as
a GCC extension. Avoids compiler warnings:
../../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../../amdgpu/amdgpu_bo.c:554:48: warning: pointer of type ‘void *’ used in
arithmetic
From: Michel Dänzer
The compiler points out that an int doesn't work as intended if
dev->bo_handles.max_key > INT_MAX:
../../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../../amdgpu/amdgpu_bo.c:550:16: warning: comparison of integer expressions of
different sign
From: Michel Dänzer
Arithmetic using void* pointers isn't defined by the C standard, only as
a GCC extension. Avoids compiler warnings:
../../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../../amdgpu/amdgpu_bo.c:554:48: warning: pointer of type ‘void *’ used in
arithmetic
CONFIG_DRM_AMD_DC_DCN1_0 to be accidentally disabled on X86 again. If it
is reinstated, it should be strictly derived from other options, not
changeable by the user.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X d
From: Michel Dänzer
This is to avoid submitting more flips while we are waiting for pending
ones to complete.
Signed-off-by: Michel Dänzer
---
v2:
* Rebased on top of new patch 2.5
src/amdgpu_drm_queue.c | 41 +++--
src/amdgpu_drm_queue.h | 1 +
src
From: Michel Dänzer
Instead of processing DRM events directly from drmHandleEvent's
callbacks, there are three phases:
1. drmHandleEvent is called, and signalled events are re-queued to
_signalled lists from its callbacks.
2. Signalled page flip completion events are processed.
3. Signalled
From: Michel Dänzer
Instead of the Xorg version. This should allow glamor backported from
xserver >= 1.20 to work with older Xorg versions.
Signed-off-by: Michel Dänzer
---
src/amdgpu_glamor.c | 8
src/amdgpu_kms.c| 20
2 files changed, 16 insertions(+),
From: Michel Dänzer
The allocated size can be (at least?) as large as megabytes, and
there's no need for it to be physically contiguous.
May avoid spurious failures to initialize / suspend the corresponding
block while there's memory pressure.
Bugzilla: https://bugs.freedesktop.org/107432
On 2018-08-03 01:34 PM, Christian König wrote:
> This way we can always find a BO structure by its handle.
>
> Signed-off-by: Christian König
In the shortlog, should be "handle table" instead of "lockup table"?
With that fixed, the series is
Reviewed-by: Mich
From: Michel Dänzer
Not doing this resulted in falling back to software for DRI3 client
presentation operations with ShadowPrimary.
(Ported from amdgpu commit 2989d40ef74d9966e8e8df2ef7727b2cc48d4960)
Signed-off-by: Michel Dänzer
---
src/radeon_dri3.c | 1 +
1 file changed, 1 insertion
From: Michel Dänzer
We were only storing the FB provided by the client, but on CRTCs with
TearFree enabled, we use a separate FB. This could cause
drmmode_flip_handler to fail to clear drmmode_crtc->flip_pending, which
could result in a hang when waiting for the pending flip to complete. We
w
From: Michel Dänzer
Inspired by the modesetting driver.
(Ported from radeon commit db28d35ce9fd07a2a4703f3df0633d4c8291ff9b)
Signed-off-by: Michel Dänzer
---
src/amdgpu_glamor.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/src
ble *table, uint32_t
> key)
> +{
> + return table->values[key];
> +}
Typo: Should be "lookup", not "lockup".
Maybe these should check that key < table->max_key, to prevent memory
outside of the table from getting corrupted by buggy caller
*shared_handle = bo->handle;
> return 0;
This is a bit unfortunate, amdgpu_bo_handle_type_kms_noimport only just
landed this week for the 2.4.93 release, now it'll already be useless
noise... A bit more coordination would have been nice. :)
Anyway, with the typo in pat
if (!dc_is_dp_signal(link->connector_signal))
> + return false;
> default:
> break;
> }
>
Could this be problematic with VGA connectors? AFAIR e.g. KVM switches
can cause trouble with retrievin
On 2018-07-30 08:12 PM, Alex Deucher wrote:
> On Fri, Jul 27, 2018 at 12:04 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> We were only storing the FB provided by the client, but on CRTCs with
>> TearFree enabled, we use a separate FB. This could cause
>
CPU
speculatively executing the following code assuming idx <
ARRAY_SIZE(data.states), and extracting information from the incorrectly
speculated code via side channels.
I'm not sure if that's actually possible in this case, but better safe
than sorry?
--
Earthling M
From: Michel Dänzer
We were only storing the FB provided by the client, but on CRTCs with
TearFree enabled, we use a separate FB. This could cause
drmmode_flip_handler to fail to clear drmmode_crtc->flip_pending, which
could result in a hang when waiting for the pending flip to complete. We
w
From: Michel Dänzer
Inspired by the modesetting driver.
Fixes screen pixmap corruption with Xorg < 1.20, and as a bonus,
simplifies the code slightly.
v2:
* Now doesn't break with xserver 1.20
Bugzilla: https://bugs.freedesktop.org/107385
Signed-off-by: Michel Dänzer
---
src/radeon_glamo
On 2018-07-27 03:39 PM, Christian König wrote:
> Otherwise we silently don't use a BO list when the handle is invalid.
>
> Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software e
On 2018-07-27 11:33 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Inspired by the modesetting driver.
>
> Fixes screen pixmap corruption with Xorg < 1.20, and as a bonus,
> simplifies the code slightly.
Unfortunately, turns out this patch as is breaks compilation
From: Michel Dänzer
Inspired by the modesetting driver.
Fixes screen pixmap corruption with Xorg < 1.20, and as a bonus,
simplifies the code slightly.
Bugzilla: https://bugs.freedesktop.org/107385
Signed-off-by: Michel Dänzer
---
src/radeon_glamor.c | 28
1 f
TM patches need to be sent to the dri-devel list as well for review.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.
From: Michel Dänzer
Not doing this resulted in falling back to software for DRI3 client
presentation operations with ShadowPrimary.
Signed-off-by: Michel Dänzer
---
src/amdgpu_dri3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amdgpu_dri3.c b/src/amdgpu_dri3.c
index 87e3d85c1
On 2018-07-24 07:20 PM, Paul Menzel wrote:
> On 07/20/18 18:33, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> We were testing the register offset, instead of the value stored in the
>> register, therefore always timing out the loop.
>>
>> This reduce
From: Michel Dänzer
And make amdgpu_drm_queue_handler not directly accessible outside of
amdgpu_drm_queue.c.
Signed-off-by: Michel Dänzer
---
src/amdgpu_dri2.c | 14 --
src/amdgpu_drm_queue.c | 11 +--
src/amdgpu_drm_queue.h | 5 +
src/amdgpu_kms.c | 2
From: Michel Dänzer
This is a more robust way to prevent hangs due to nested calls to
drmHandleEvent.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 124 +
src/amdgpu_drm_queue.h | 1 +
src/drmmode_display.c | 18 --
src
From: Michel Dänzer
Replacing the drmmode_crtc_wait_pending_event macro.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 13 +
src/amdgpu_drm_queue.h | 1 +
src/drmmode_display.c | 22 --
3 files changed, 18 insertions(+), 18 deletions(-)
diff
From: Michel Dänzer
Instead of strncpy with the string length. Avoids new warnings with GCC
8:
../../src/drmmode_display.c: In function ‘drmmode_output_create_resources’:
../../src/drmmode_display.c:2240:2: warning: ‘strncpy’ output truncated before
terminating nul copying 8 bytes from
601 - 700 of 1906 matches
Mail list logo
