Hi Michel,
Could randrproto >= 1.6.0 also be optional? randrproto 1.6 is pretty new so
most old xserver doesn't compile with it. When compile latest ddx with
various OS we support, it will fail.
Maybe we can define RR_PROPERTY_NON_DESKTOP in ddx if not yet.
Regards,
Qiang
Hi
I'm happy to test this out, just wondering what userspace I should pair it
with
Cheers
Mike
On Thu, 12 Jul 2018 at 22:25 Felix Kuehling wrote:
> Raven refers to Ryzen APUs with integrated GFXv9 GPU.
> This patch series completes Raven support for KFD:
>
> * fix up memory banks info from
From: Yong Zhao
Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
From: Yong Zhao
Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
From: Yong Zhao
Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
From: Yong Zhao
On Raven there is only one SDMA engine instead of previously assumed two,
so we need to adapt our code to this new scenario.
Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 12
From: Yong Zhao
If there are several memory banks that has the same properties in CRAT,
we aggregate them into one memory bank. This cleans up memory banks on
APUs (e.g. Raven) where the CRAT reports each memory channel as a
separate bank. This only confuses user mode, which only deals with
Raven refers to Ryzen APUs with integrated GFXv9 GPU.
This patch series completes Raven support for KFD:
* fix up memory banks info from CRAT
* support different number of SDMA engines
* workaround IOMMUv2 PPR issues
* add device info
Yong Zhao (6):
drm/amdkfd: Consolidate duplicate memory
From: Yong Zhao
On Raven Invalid PPRs can be reported because multiple PPRs can be
still queued when memory is freed. Apply a rate limit to avoid
flooding the log in this case.
Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
return a uint32_t rather than an int to properly reflect
what the function does.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 2 +-
drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 2 +-
drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c | 2 +-
Split out the shared smumgr code for vega10 and 12
so we don't have duplicate code for both.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 44 ++---
.../gpu/drm/amd/powerplay/hwmgr/vega12_thermal.c | 8 +-
drivers/gpu/drm/amd/powerplay/smumgr/Makefile
Commented out.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c | 29 --
1 file changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c
index
From: Harry Wentland
[Why]
Any Linux kernel code should pass checkpatch.pl with no errors and
little, if any, warning.
[How]
Fixing some spacing errors and warnings.
Change-Id: I44d2da7be3a02a9644cbdfb3382566e562e7ea24
Signed-off-by: Harry Wentland
Reviewed-by: Tony Cheng
Acked-by: Leo Li
From: Krunoslav Kovac
[Why]
Cursor boosting can only be done on DCN+
Check for nullptr since DCE doesn't implement it.
Change-Id: Ifd191103f58214038355c41ccd89fc9cf4a95b3e
Signed-off-by: Krunoslav Kovac
Reviewed-by: Sivapiriyan Kumarasamy
Acked-by: Leo Li
---
From: Harry Wentland
Change-Id: I59cb2ad47b74e8aa48bc71bd532e02a1723a308e
Signed-off-by: Harry Wentland
Reviewed-by: Steven Chiu
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
From: Jun Lei
[why]
Some DTN tests still failing @ 2% Need to reduce.
[how]
add instrumentation code to driver so we can get more information from failed
runs.
Change-Id: I6c4ead8e28100cbe951a06dcde85dd6dbd5aa321
Signed-off-by: Jun Lei
Reviewed-by: Tony Cheng
Acked-by: Leo Li
---
From: Nikola Cornij
This allows DM to do any necessary updates before MST discovery starts.
Change-Id: I106b56b0ffe1c0e00a27c81fcee3776c69e17575
Signed-off-by: Nikola Cornij
Reviewed-by: Nikola Cornij
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 5 +
From: Tony Cheng
[Why]
We sometime require remapping of FB address space to UMA
[How]
Move address tracking up a layer before we apply address translation
Change-Id: I60a979662c07c3be8f798a517ba9d30322b2cc8a
Signed-off-by: Tony Cheng
Reviewed-by: Charlene Liu
Acked-by: Leo Li
---
From: Gloria Li
[Why]
Testing team wants a way to tell if HDR is on or not
[How]
Program the overscan color to visually indicate the HDR state of the top-most
plane
Change-Id: I5bd04d68586461f2da81be99f5e92a6cdfa17d8b
Signed-off-by: Gloria Li
Reviewed-by: Aric Cyr
Acked-by: Leo Li
---
From: Krunoslav Kovac
[Why]
Vesa DPMS tool sends different HDR meta in OS flips without changing output
parameters. We don't properly update HDR info frame:
- we label HDR meta update as fast update
- when updating HW info frame, we only do it if full update
[How]
It should still be fast
From: Krunoslav Kovac
[Why]
Cursor boosting is done via CNVC_CUR register which is DPP, not HUBP
Previous commit was implementing it in HUBP functions,
and also breaking diags tests.
[How]
1. Undo original commit as well as Eric's diags test fix, almost completely
2. Move programming to DPP and
From: Vitaly Prosyak
Hard-coded luts are needed since complex algorithms are used for
color and tone mapping. Add the headers for future use.
Change-Id: Ida4288a0ded7dc21182b23d108aa1df38681d6f0
Signed-off-by: Vitaly Prosyak
Reviewed-by: Tony Cheng
Acked-by: Leo Li
---
From: "Leo (Sunpeng) Li"
Summary of change:
* HDR debugging features
* Small bug fixes and minor cleanups
Gloria Li (1):
drm/amd/display: add HDR visual confirm
Harry Wentland (2):
drm/amd/display: dal 3.1.56
drm/amd/display: Fix some checkpatch.pl errors and warnings in
dc_link_dp.c
Nayan Deshmukh writes:
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 3dc1a4f07e3f..b2dbd1c1ba69 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -162,26 +162,32 @@
Nayan Deshmukh writes:
> Signed-off-by: Nayan Deshmukh
> ---
Acked-by: Eric Anholt
signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Thu, Jul 12, 2018, 3:31 AM Michel Dänzer wrote:
> On 2018-07-12 02:47 AM, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > ---
> > amdgpu/amdgpu.h| 7 ++-
> > amdgpu/amdgpu_bo.c | 4
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/amdgpu/amdgpu.h
This change is to support MESA performace optimization.
Modify CS IOCTL to allow its input as command buffer and an array of
buffer handles to create a temporay bo list and then destroy it
when IOCTL completes.
This saves on calling for BO_LIST create and destry IOCTLs in MESA
and by this improves
Hi All,
When the gtt memory is used up, application continues to use gtt , then
the gtt will overflow,
the gtt available will be negative(cat /sys/kernel/debug/dri/1/amdgpu_gtt_mm),
and more system memory is used as GTT, is it normal?
My kernel is newest v4.18 master, I add "cma=0
[+Pan Xinhui]
On 2018-07-12 03:16 AM, Michel Dänzer wrote:
> On 2018-07-12 02:43 AM, Felix Kuehling wrote:
>> Kent just caught a similar backtrace in one of our KFD pre-submission
>> tests (see below)
> Yeah, looks the same.
>
>
>> Neither KFD nor AMDGPU are implied in the backtrace. Is this a
>>
On Thu, Jul 12, 2018 at 8:33 AM, Christian König
wrote:
> We are initializing the entity before the scheduler is actually
> initialized.
>
> This can lead to all kind of problem, but especially NULL pointer deref
> because of Nayan's scheduler work.
>
> Signed-off-by: Christian König
Acked-by:
On 2018-07-12 10:29 AM, Francis, David wrote:
> Upon closer inspection, this does not match any FDO bug. The FDO bug I
> thought this was related to was fixed by Michel Danzer, and this fixes an
> entirely separate issue.
>
If I remember right we have a regression change for this. We should
use kaddr directly rather than secondary variable.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 3 +--
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.h | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git
use the structure member directly.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
Rather than calculating it everytime we rebuild the toc
buffer, calculate it once initially and then just copy
the cached results to the vram buffer.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 92 +-
Rather than using the index variable stored in vram. If
the device fails to come back online after a resume cycle,
reads from vram will return all 1s which will cause a
segfault. Based on a patch from Thomas Martitz .
This avoids the segfault, but we still need to sort out
why the GPU does not
From: Michel Dänzer
This shouldn't happen, but if it does, we'll get a backtrace of the
caller, and update the pin_size values as needed.
v2:
* Check bo->pin_count instead of placement flags (Christian König)
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 32
From: Michel Dänzer
Instead of CPU invisible VRAM. Preparation for the following, no
functional change intended.
v2:
* Also change amdgpu_vram_mgr_bo_invisible_size to
amdgpu_vram_mgr_bo_visible_size, allowing further simplification
(Christian König)
Cc: sta...@vger.kernel.org
From: Michel Dänzer
Concurrent execution of the non-atomic arithmetic could result in
completely bogus values.
v2:
* Rebased on v2 of the previous patch
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/106872
Reviewed-by: Christian König # v1
Signed-off-by: Michel Dänzer
---
Upon closer inspection, this does not match any FDO bug. The FDO bug I thought
this was related to was fixed by Michel Danzer, and this fixes an entirely
separate issue.
From: Michel Dänzer
Sent: July 12, 2018 10:18:34 AM
To: Wentland, Harry; Francis, David;
The driver is expecting clock frequency in kHz, while SMU returns
the values in 10kHz, which causes the bandwidth validation to fail
4.18 has the faulty clock assignment in pp_to_dc_clock_levels_with_latency
only, which is only used by Vega. Make sure we multiply these values
by 10 here, as we do
This does get called from both dce120 and dce112, but it will also any
fix any problems for dce112 as well. Looks fine to me.
Reviewed-by: Nicholas Kazlauskas
Nicholas Kazlauskas
On 07/12/2018 10:09 AM, Harry Wentland wrote:
The driver is expecting clock frequency in kHz, while SMU returns
On 2018-07-12 04:09 PM, Harry Wentland wrote:
> The driver is expecting clock frequency in kHz, while SMU returns
> the values in 10kHz, which causes the bandwidth validation to fail
>
> 4.18 has the faulty clock assignment in pp_to_dc_clock_levels_with_latency
> only, which is only used by Vega.
On 2018-07-12 04:13 PM, Harry Wentland wrote:
> On 2018-07-12 10:07 AM, David Francis wrote:
>> [Why]
>> When a dce100 asic was suspended, the clocks were not set to 0.
>> Upon resume, the new clock was compared to the existing clock,
>> they were found to be the same, and so the clock was not
On 2018-07-12 10:07 AM, David Francis wrote:
> [Why]
> When a dce100 asic was suspended, the clocks were not set to 0.
> Upon resume, the new clock was compared to the existing clock,
> they were found to be the same, and so the clock was not set.
> This resulted in a pernicious blackscreen.
>
>
The driver is expecting clock frequency in kHz, while SMU returns
the values in 10kHz, which causes the bandwidth validation to fail
4.18 has the faulty clock assignment in pp_to_dc_clock_levels_with_latency
only, which is only used by Vega. Make sure we multiply these values
by 10 here, as we do
[Why]
When a dce100 asic was suspended, the clocks were not set to 0.
Upon resume, the new clock was compared to the existing clock,
they were found to be the same, and so the clock was not set.
This resulted in a pernicious blackscreen.
[How]
In atomic commit, check to see if there are any
On 2018-07-12 09:58 AM, Alex Deucher wrote:
> On Thu, Jul 12, 2018 at 9:46 AM, Harry Wentland
> wrote:
>> Fixing Nicholas's email.
>>
>> On 2018-07-12 09:36 AM, Harry Wentland wrote:
>>> The driver is expecting clock frequency in kHz, while SMU returns
>>> the values in 10kHz, which causes the
On Thu, Jul 12, 2018 at 9:46 AM, Harry Wentland wrote:
> Fixing Nicholas's email.
>
> On 2018-07-12 09:36 AM, Harry Wentland wrote:
>> The driver is expecting clock frequency in kHz, while SMU returns
>> the values in 10kHz, which causes the bandwidth validation to fail
>>
>> 4.18 has the faulty
Hi Jim,
Replies in between.
Regards,
Luís
On Thu, Jul 12, 2018 at 3:16 AM, jimqu wrote:
>
>
> On 2018年07月12日 05:27, Luís Mendes wrote:
>
> Hi Jim,
>
> I followed your suggestion and was able to bisect the kernel patches.
> The offending patch is: drm/amdgpu: defer test IBs on the rings at
Fixing Nicholas's email.
On 2018-07-12 09:36 AM, Harry Wentland wrote:
> The driver is expecting clock frequency in kHz, while SMU returns
> the values in 10kHz, which causes the bandwidth validation to fail
>
> 4.18 has the faulty clock assignment in pp_to_dc_clock_levels_with_latency
> only,
The driver is expecting clock frequency in kHz, while SMU returns
the values in 10kHz, which causes the bandwidth validation to fail
4.18 has the faulty clock assignment in pp_to_dc_clock_levels_with_latency
only, which is only used by Vega. Make sure we multiply these values
by 10 here, as we do
We are initializing the entity before the scheduler is actually
initialized.
This can lead to all kind of problem, but especially NULL pointer deref
because of Nayan's scheduler work.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 36
Hi Christian,
Sure, how can I help to fix that?
Regards,
Luís
On Thu, Jul 12, 2018 at 8:13 AM, Christian König
wrote:
> Hi Luis,
>
> well was "drm/amdgpu: defer test IBs on the rings at boot (V3)" does is
> delaying the IB test a bit and running it async to the rest of the bootup.
>
> So what
On 2018年07月12日 15:56, Christian König wrote:
Am 12.07.2018 um 06:21 schrieb zhoucm1:
With more thinking for you performance reason, Can we go further more
not to create temp bo list at all? directly add them into
parser->validated list?
You still need something which is added to the
Am 12.07.2018 um 06:21 schrieb zhoucm1:
With more thinking for you performance reason, Can we go further more
not to create temp bo list at all? directly add them into
parser->validated list?
You still need something which is added to the parser->validated list,
so creating the array of BOs
Patches which don't already have my rb are Acked-by: Christian König
.
Regards,
Christian.
Am 12.07.2018 um 04:32 schrieb Felix Kuehling:
This series fixes some KFD issues, adds robustness enhancements and
finally a few cleanups.
Patches 1-4 are important fixes.
Patches 5-8 add handling of
On 2018-07-12 09:38 AM, Christian König wrote:
> Am 11.07.2018 um 18:23 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> Instead of CPU invisible VRAM. Preparation for the following, no
>> functional change intended.
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Michel Dänzer
>>
>> [...]
Am 11.07.2018 um 18:23 schrieb Michel Dänzer:
From: Michel Dänzer
This shouldn't happen, but if it does, we'll get a backtrace of the
caller, and update the pin_size values as needed.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 37 +-
Am 11.07.2018 um 18:23 schrieb Michel Dänzer:
From: Michel Dänzer
Concurrent execution of the non-atomic arithmetic could result in
completely bogus values.
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/106872
Signed-off-by: Michel Dänzer
Reviewed-by: Christian König
Am 11.07.2018 um 18:23 schrieb Michel Dänzer:
From: Michel Dänzer
Instead of CPU invisible VRAM. Preparation for the following, no
functional change intended.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
On 2018-07-12 02:47 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> amdgpu/amdgpu.h| 7 ++-
> amdgpu/amdgpu_bo.c | 4
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index 36f91058..be83b457 100644
> ---
Only a few more style nit picks:
Patches #1 and #2 need a commit message. A one liner why we do this
should be fine.
On Patch #3 you have a couple of places like this:
- r = drm_sched_entity_init(>sched, >mman.entity,
- rq, NULL);
+ r =
On 2018-07-12 02:43 AM, Felix Kuehling wrote:
> Kent just caught a similar backtrace in one of our KFD pre-submission
> tests (see below)
Yeah, looks the same.
> Neither KFD nor AMDGPU are implied in the backtrace. Is this a
> regression in the kernel itself? amd-kfd-staging is currently based
Hi Luis,
well was "drm/amdgpu: defer test IBs on the rings at boot (V3)" does is
delaying the IB test a bit and running it async to the rest of the bootup.
So what most likely happens is that some hardware feature (like power or
clock gating) which doesn't works correctly on your system
Am 11.07.2018 um 22:57 schrieb Andrey Grodzovsky:
This change is to support MESA performace optimization.
Modify CS IOCTL to allow its input as command buffer and an array of
buffer handles to create a temporay bo list and then destroy it
when IOCTL completes.
This saves on calling for BO_LIST
On Thu, Jul 12, 2018 at 12:07 PM Nayan Deshmukh
wrote:
>
> replace run queue by a list of run queues and remove the
> sched arg as that is part of run queue itself
>
> Signed-off-by: Nayan Deshmukh
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++--
>
replace run queue by a list of run queues and remove the
sched arg as that is part of run queue itself
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 ++--
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 3 +++
include/drm/gpu_scheduler.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 6 --
include/drm/gpu_scheduler.h | 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index
This patch series is prepration for implementing better load balancing
in the GPU scheduler. Patch #3 is the major change which modifies the
drm_sched_entity_init, the driver is now expected to provide a list of
potential run queue on which the jobs from this entity can be scheduled.
In future
On Wed, Jul 11, 2018 at 5:53 PM, Andrey Grodzovsky
wrote:
> Stop using 'magic numbers' when registering interrupt sources.
>
> v2:
> Clean redundant comments.
> Switch to kernel style comments.
>
> v3:
> Add CP_ECC_ERROR define
>
> Signed-off-by: Andrey Grodzovsky
> Acked-by: Christian König
>
71 matches
Mail list logo
