Instead of EVV cks-off voltages, avfs cks-off voltages can avoid
the overshoot voltages when switching sclk.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/powerplay/inc/smu7_ppsmc.h | 2 ++
drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 9 +
2 files changed, 11
Hi Hersen,
Can we change "pr_info" to "pr_debug"?
I am afraid there may be a bunch of "was not implemented" in kernel message on
old asics.
Except that,
Patch is
Reviewed-by: Rex Zhu
Best Regards
Rex
From: Wu, Hersen
Sent: Thursday, December 6, 2018 2:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Aaron Liu
Sent: Wednesday, December 5, 2018 8:26:52 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Aaron
Subject: [PATCH] drm/amdgpu: both support PCO FP5/AM4 rlc fw
For Picasso && AM4 SOCKET board, we use pi
amdgpu_ring_soft_recovery would have Call-Trace,
when s_fence->parent was NULL inside amdgpu_job_timedout.
Check fence first, as drm_sched_hw_job_reset did.
Change-Id: Ibb062e36feb4e2522a59641fe0d2d76b9773cda7
Signed-off-by: Wentao Lou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
1 file
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Aaron Liu
> Sent: Thursday, December 06, 2018 9:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Aaron
> Subject: [PATCH] drm/amdgpu: both support PCO FP5/AM4 rlc fw
>
> For Picasso && A
For Picasso && AM4 SOCKET board, we use picasso_rlc_am4.bin
For Picasso && FP5 SOCKET board, we use picasso_rlc.bin
Judgment method:
PCO AM4: revision >= 0xC8 && revision <= 0xCF
or revision >= 0xD8 && revision <= 0xDF
otherwise is PCO FP5
Change-Id: I359f0a3d1bc7d4d49c871cb3fb82797c7b91
Patches 1-3 are Reviewed-by: Felix Kuehling
I applied all 10 patches and tested them with kfdtest on Fiji and
Vega10. It seems to not break anything obvious.
I think I found a problem in patch 9 and have a question about patch 8
regarding the context in which interrupt processing functions would
On 2018-12-05 4:15 a.m., Christian König wrote:
> This finally enables processing of ring 1 & 2.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 68 --
> 1 file changed, 63 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/
Depending on the interrupt ring, the IRQ dispatch and processing
functions will run in interrupt context or in a worker thread.
Is there a way for the processing functions to find out which context
it's running in? That may influence decisions whether to process
interrupts in the same thread or sc
Applied. thanks!
Alex
On Wed, Dec 5, 2018 at 2:02 PM Lyude Paul wrote:
>
> Reviewed-by: Lyude Paul
>
> Thanks!
>
> On Wed, 2018-12-05 at 15:43 +0800, Wen Yang wrote:
> > kfree(NULL) is safe, so removes NULL check before freeing the mem.
> > This patch also fix the ifnullfree.cocci warnings.
> >
On 2018-12-05 3:44 p.m., Grodzovsky, Andrey wrote:
>
>
> On 12/05/2018 03:42 PM, Kazlauskas, Nicholas wrote:
>> On 2018-12-05 3:26 p.m., Grodzovsky, Andrey wrote:
>>>
>>> On 12/05/2018 02:59 PM, Nicholas Kazlauskas wrote:
[Why]
Legacy cursor plane updates from drm helpers go through the
On 12/05/2018 03:42 PM, Kazlauskas, Nicholas wrote:
> On 2018-12-05 3:26 p.m., Grodzovsky, Andrey wrote:
>>
>> On 12/05/2018 02:59 PM, Nicholas Kazlauskas wrote:
>>> [Why]
>>> Legacy cursor plane updates from drm helpers go through the full
>>> atomic codepath. A high volume of cursor updates thr
On 2018-12-05 3:26 p.m., Grodzovsky, Andrey wrote:
>
>
> On 12/05/2018 02:59 PM, Nicholas Kazlauskas wrote:
>> [Why]
>> Legacy cursor plane updates from drm helpers go through the full
>> atomic codepath. A high volume of cursor updates through this slow
>> code path can cause subsequent page-fli
On 12/05/2018 02:59 PM, Nicholas Kazlauskas wrote:
> [Why]
> Legacy cursor plane updates from drm helpers go through the full
> atomic codepath. A high volume of cursor updates through this slow
> code path can cause subsequent page-flips to skip vblank intervals
> since each individual update is
[Why]
Legacy cursor plane updates from drm helpers go through the full
atomic codepath. A high volume of cursor updates through this slow
code path can cause subsequent page-flips to skip vblank intervals
since each individual update is slow.
This problem is particularly noticeable for the compton
Hi Dave,
Fixes for 4.20:
- Fix banding regression on 6 bpc panels
- Vega20 fix for six 4k displays
- Fix LRU handling in ttm_buffer_object_transfer
- Use proper MC firmware for newer polaris variants
- Vega20 powerplay fixes
- VCN suspend/resume fix for PCO
- Misc other fixes
The following change
Reviewed-by: Lyude Paul
Thanks!
On Wed, 2018-12-05 at 15:43 +0800, Wen Yang wrote:
> kfree(NULL) is safe, so removes NULL check before freeing the mem.
> This patch also fix the ifnullfree.cocci warnings.
>
> Signed-off-by: Wen Yang
> CC: Alex Deucher
> CC: christian.koe...@amd.com
> CC: "Dav
On 12/4/18 10:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20181204:
>
on i386:
ld: drivers/gpu/drm/amd/display/dc/dce/dce_i2c_sw.o: in function
`wait_for_scl_high_sw':
dce_i2c_sw.c:(.text+0x2f3): undefined reference to `__bad_udelay'
ld: drivers/gpu/drm/amd/display/dc/dce/dce_i2
Looks reasonable to me.
Acked-by: Alex Deucher
From: Wu, Hersen
Sent: Wednesday, December 5, 2018 1:03:57 PM
To: amd-gfx@lists.freedesktop.org; Zhu, Rex; Deucher, Alexander
Subject: RE: [PATCH] drm/amd/powerplay: rv dal-pplib interface refactor
powerplay part
H
Hello, Alex, Rex,
Would you please help review the change?
Thanks,
Hersen
[WHY] clarify dal input parameters to pplib interface, remove un-used
parameters. dal knows exactly which parameters needed and their effects at
pplib and smu sides.
current dal sequence for dcn1_update_clock to ppl
[Why]
When the flip-rate is below the minimum supported variable refresh rate
range for the monitor the front porch wait will timeout and be
frequently misaligned resulting in stuttering and/or flickering.
The FreeSync module can still maintain a smooth and flicker free
image when the monitor has
Series is:
Acked-by: Alex Deucher
From: amd-gfx on behalf of Xiangliang
Yu
Sent: Wednesday, December 5, 2018 1:46:31 AM
To: amd-gfx@lists.freedesktop.org
Cc: Min, Frank; Yu, Xiangliang
Subject: [PATCH 3/3] drm/amdgpu/psp: Destroy psp ring when doing gpu reset
On Wed, Dec 05, 2018 at 08:40:34AM +0100, Andrzej Hajda wrote:
> On 04.12.2018 20:02, Ville Syrjälä wrote:
> > On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> >> On 03.12.2018 22:48, Ville Syrjälä wrote:
> >>> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> Qu
On 2018-12-05 9:30 a.m., Li, Sun peng (Leo) wrote:
>
>
> On 2018-12-05 8:40 a.m., Nicholas Kazlauskas wrote:
>> [Why]
>> When application flip-rate is below the minimum vrr refresh rate.
>>
>> Variable refresh rate monitors extend the front porch duration until
>> flip or timeout occurs. For case
From: Leo Li
In particular, we need the mmMC_VM_XGMI_LFB_CNTL register, for
determining if xGMI is enabled on VG20. This will be used by DC to
determine the correct spread spectrum adjustment for display and audio
clocks.
Signed-off-by: Leo Li
Reviewed-by: Alex Deucher
---
.../include/asic_re
On Tue, Nov 20, 2018 at 06:13:42PM +0200, Ville Syrjala wrote:
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index a7c39f39793f..38c66fbc8276 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -849,7 +849,8 @@
On Wed, Dec 05, 2018 at 09:46:40AM +0100, Andrzej Hajda wrote:
> On 05.12.2018 07:32, Laurent Pinchart wrote:
> > Hi Ville,
> >
> > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> >>> On 03.12.2018 22:38, Ville Syrj
On 2018-12-05 8:40 a.m., Nicholas Kazlauskas wrote:
> [Why]
> When application flip-rate is below the minimum vrr refresh rate.
>
> Variable refresh rate monitors extend the front porch duration until
> flip or timeout occurs. For cases where the application flip-rate is
Did something get cut o
Quoting Kuehling, Felix (2018-12-03 22:55:16)
>
> On 2018-11-28 4:14 a.m., Joonas Lahtinen wrote:
> > Quoting Ho, Kenny (2018-11-27 17:41:17)
> >> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
> >> wrote:
> >>> I think a more abstract property "% of GPU (processing power)" might
> >>> be a mor
[Why]
When application flip-rate is below the minimum vrr refresh rate.
Variable refresh rate monitors extend the front porch duration until
flip or timeout occurs. For cases where the application flip-rate is
When the flip-rate is below the minimum supported variable refresh rate
range for the m
Hi David,
with a bit of luck that should do it.
Can you please run your test as well as the igt tests on this once more
and see if everything works as expected?
Thanks,
Christian.
Am 05.12.18 um 14:08 schrieb Christian König:
For a lot of use cases we need 64bit sequence numbers. Currently
From: Chunming Zhou
syncobj wait/signal operation is appending in command submission.
v2: separate to two kinds in/out_deps functions
Signed-off-by: Chunming Zhou
Cc: Daniel Rakos
Cc: Jason Ekstrand
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc: Christian König
Cc: Chris Wilson
---
drivers/gp
From: Chunming Zhou
user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
Signed-off-by: Chunming Zhou
Cc: Daniel Rakos
Cc: Jason Ekstrand
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc
Implement finding the right timeline point in drm_syncobj_find_fence.
v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 43
This completes "drm/syncobj: Drop add/remove_callback from driver
interface" and cleans up the implementation a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 91 ++-
include/drm/drm_syncobj.h | 21 --
2 files changed,
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's not a chain fence.
v3: use
For a lot of use cases we need 64bit sequence numbers. Currently drivers
overload the dma_fence structure to store the additional bits.
Stop doing that and make the sequence number in the dma_fence always
64bit.
For compatibility with hardware which can do only 32bit sequences the
comparisons in
From: Chunming Zhou
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 90f474f98b6e..316bfc1a6a75 100644
--- a/dri
From: Chunming Zhou
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add com
Use the dma_fence_chain object to create a timeline of fence objects
instead of just replacing the existing fence.
v2: rebase and cleanup
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 37 +
include/drm/drm_syncobj.h | 5 +
2 file
On 2018-12-05 12:41 p.m., Koenig, Christian wrote:
> Am 05.12.18 um 12:33 schrieb Michel Dänzer:
>> On 2018-12-05 12:24 p.m., Koenig, Christian wrote:
>>> Am 05.12.18 um 11:29 schrieb Michel Dänzer:
On 2018-12-04 6:35 p.m., Koenig, Christian wrote:
> Thanks, going to take a look tomorrow.
Am 05.12.18 um 12:33 schrieb Michel Dänzer:
> On 2018-12-05 12:24 p.m., Koenig, Christian wrote:
>> Am 05.12.18 um 11:29 schrieb Michel Dänzer:
>>> On 2018-12-04 6:35 p.m., Koenig, Christian wrote:
Thanks, going to take a look tomorrow.
>>> I also hit this with Bonaire in my development system
On 2018-12-05 12:24 p.m., Koenig, Christian wrote:
> Am 05.12.18 um 11:29 schrieb Michel Dänzer:
>> On 2018-12-04 6:35 p.m., Koenig, Christian wrote:
>>> Thanks, going to take a look tomorrow.
>> I also hit this with Bonaire in my development system. I wonder why you
>> didn't? How are you running
Am 05.12.18 um 12:03 schrieb wentalou:
amdgpu_ring_soft_recovery would have Call-Trace,
when s_job->s_fence->parent was NULL inside amdgpu_job_timedout.
Check parent first, as drm_sched_hw_job_reset did.
Change-Id: I0b674ffd96afd44bcefe37a66fb157b1dbba61a0
Signed-off-by: Wentao Lou
---
driver
Am 05.12.18 um 11:29 schrieb Michel Dänzer:
> On 2018-12-04 6:35 p.m., Koenig, Christian wrote:
>> Thanks, going to take a look tomorrow.
> I also hit this with Bonaire in my development system. I wonder why you
> didn't? How are you running piglit?
With more memory. The issue is in TTM and only h
amdgpu_ring_soft_recovery would have Call-Trace,
when s_job->s_fence->parent was NULL inside amdgpu_job_timedout.
Check parent first, as drm_sched_hw_job_reset did.
Change-Id: I0b674ffd96afd44bcefe37a66fb157b1dbba61a0
Signed-off-by: Wentao Lou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
On 2018-12-04 6:35 p.m., Koenig, Christian wrote:
> Thanks, going to take a look tomorrow.
I also hit this with Bonaire in my development system. I wonder why you
didn't? How are you running piglit?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthu
Hi Daniel,
can I get a review for this one? It is essentially just a follow up
cleanup on one of your patches and shouldn't have any functional effect.
Thanks,
Christian.
Am 04.12.18 um 12:59 schrieb Christian König:
This completes "drm/syncobj: Drop add/remove_callback from driver
interface
From: shaoyunl
[ Upstream commit ad97d9de45835b6a0f71983b0ae0cffd7306730a ]
Driver shouldn't try to access any GFX registers until RLC is idle.
During the test, it took 12 seconds for RLC to clear the BUSY bit
in RLC_GPM_STAT register which is un-acceptable for driver.
As per RLC engineer, it wo
From: shaoyunl
[ Upstream commit ad97d9de45835b6a0f71983b0ae0cffd7306730a ]
Driver shouldn't try to access any GFX registers until RLC is idle.
During the test, it took 12 seconds for RLC to clear the BUSY bit
in RLC_GPM_STAT register which is un-acceptable for driver.
As per RLC engineer, it wo
That should add back pressure on the client.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
index 4a753e40a837..b65515e6dff9 100644
printk_ratelimit() is much better suited to limit the number of reported
VM faults.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 37 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 5
drivers/gpu/drm/amd/amdgpu/cik_ih.c | 18 +
Let's start to support multiple rings.
v2: decode IV is needed as well
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 13 +++---
drivers/gpu/drm/amd/amdgpu/cik_ih.c | 29 +++--
drivers/gpu/drm/amd/amdgpu
This finally enables processing of ring 1 & 2.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 68 --
1 file changed, 63 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
b/drivers/gpu/drm/amd/amdgpu/vega10_ih.
This allows us to filter out VM faults in the GMC code.
v2: don't filter out all faults
v3: fix copy&paste typo, send all IV to the KFD, don't change message level
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 38 +++--
1 file changed, 17 inser
The GMC/VM subsystem is causing the faults, so move the handling here as
well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 4 --
drivers/gpu/drm/amd/amdgpu/cik_ih.c | 13
drivers/gpu/drm/amd/amdgpu/cz_ih.c
Calculate all the addresses and pointers in amdgpu_ih.c
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 34 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 23 +---
drivers/gpu/drm/amd/amdgpu/cik_ih.c | 9 +++
drivers/gpu/drm/am
To distinct on which IH ring an IV was found.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 11 +++
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
The entries are ignored for now, but it at least stops crashing the
hardware when somebody tries to push something to the other IH rings.
v2: limit ring size, add TODO comment
v3: only program rings if they are actually allocated
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amd
Previously we only added the ring buffer memory, now add the handling as
well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 33 +
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h | 4 ++-
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git
Hi Andrzej,
On Wednesday, 5 December 2018 10:46:40 EET Andrzej Hajda wrote:
> On 05.12.2018 07:32, Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> >>> On 03.12.2018 22:38, Ville Syrjälä
kfree(NULL) is safe, so removes NULL check before freeing the mem.
This patch also fix the ifnullfree.cocci warnings.
Signed-off-by: Wen Yang
CC: Alex Deucher
CC: christian.koe...@amd.com
CC: "David (ChunMing) Zhou"
CC: David Airlie (maintainer:DRM DRIVERS)
CC: Lyude Paul
CC: Rex Zhu
CC: Jim
On 05.12.2018 07:32, Laurent Pinchart wrote:
> Hi Ville,
>
> On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
>> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
>>> On 03.12.2018 22:38, Ville Syrjälä wrote:
On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wro
63 matches
Mail list logo