le_table *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 c
*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 i
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
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
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
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: Michel Dä
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.
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
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. Sign
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
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 an
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
arith
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
sizeof(void *));
>
Good catch! Looks like you can add
Bugzilla: https://bugs.freedesktop.org/107552
as well as
Reviewed-by: Michel Dänzer
before pushing.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X dev
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
arith
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:
>>
&g
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-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
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. Sign
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
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
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
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
t available
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
___
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
+ 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 mul
ps://bugs.freedesktop.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 t
EPowerON);
> - 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
with amdgpu (no 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
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 561a5c83e
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
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
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
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
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
_notify_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
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
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
---
.giti
if (!bo)
>
Since this 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 protec
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
> -{
> - switch (bo->tbo.mem.mem_type) {
> - case TTM_PL_TT: return amdgpu_gtt_mgr_has_gart_addr(&bo->tbo.mem);
> - case TTM_PL_VRAM: return true;
> - default: return false;
> - }
> -}
> -
> /**
> * amdgpu_bo_in_cpu_visible
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.
>>
>>
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 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 them
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:
>>>>> Th
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:
>>>>> Th
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
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
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
emoved, not #if 0'd.
Anyway, 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 machi
*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 |
e including the code 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
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
rm, so standalone 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 tr
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
rst->lru.prev;
> + list_cut_position(&before, &entries, 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
Li
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
o_handle bo)
> +{
> + atomic_inc(&bo->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 |
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_inc(
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/
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
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
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) {
^~~
../../s
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
sk info for a PASID.
> *
> - * @dev: drm device pointer
> + * @adev: drm device pointer
> * @pasid: PASID identifier for VM
> * @task_info: task_info to fill.
> */
>
Queued in the amdgpu tree (with fixed spelling of "w
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
ere 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)) {
...
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
_
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 without
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-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 you ab
internally 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
I can look 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
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
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, resulti
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
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
M_MAX_BO_PRIORITY; ++i) {
> @@ -297,8 +302,12 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
> *bulk)
> if (!pos->first)
> continue;
>
> + reservation_object_assert_held(pos->first->resv);
> + rese
ipulation 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.
--
es 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
lling 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
gl
size += num_entries * sizeof(struct amdgpu_bo_list_entry);
> list = kvmalloc(size, GFP_KERNEL);
>
--
Earthling Michel Dänzer | https://redhat.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
s 1-cycle delay in cp firmware\n");
Looks like the leading spaces after the backslash are included in the
string. Something like this should be better:
DRM_WARN_ONCE("Warning: check cp_fw_version and update "
"GRBM requires 1-cycle delay in cp firmware
> *dmub = NULL;
> + kfree(dmub);
> }
>
Maybe
kfree(*dmub);
was intended instead?
Actually, this function and others in this file seem completely unused?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast |
an one which is already caught earlier.
--
Earthling Michel Dänzer | https://redhat.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
which is somewhat more robust:
>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569
>
> I'm not sure it's more robust, but yeah that a useful tool too.
>
> The reason I'm skeptical about the robustness is that we'll miss
> testing if this misses
be only triggered manually instead of automatically on every push.
That would again break Marge Bot.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
S or GRUB?
The driver needs to work with the IOMMU enabled. If nothing else, ROCm
only works with IOMMU I think.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
_allowed=0" still happens even with
>> applying this patch.
>
> I think we can just drop the kmalloc altogether. How about this patch?
Memory allocated by kvz/malloc needs to be freed with kvfree.
--
Earthling Michel Dänzer | https://www.amd.com
Libre soft
>>
>>
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> am
iewed-by: Christian
> König
Every revert needs to explain in the commit log why the commit is being
reverted.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_
nches which didn't have other corresponding changes, so they ended
up breaking stuff instead of fixing anything.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
On 2019-09-03 10:16 p.m., Daniel Vetter wrote:
> On Tue, Sep 3, 2019 at 10:01 PM Sasha Levin wrote:
>> On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote:
>>> On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
>>>> On 2019-09-03 6:23 p.m., Sasha Le
again sorry for the brouhaha, I just honestly didn't
realize before how tricky this case was for the scripts.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
__
tags
referencing persistent commit hashes regardless of when fix-ups happen,
whereas with the former this isn't possible before the original change
makes it to Linus or at least Dave.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast
601 - 700 of 2109 matches
Mail list logo