Hi Dave, Daniel,
Fixes for 5.1:
- Fix for pcie dpm
- Powerplay fixes for vega20
- Fix vbios display on reboot if driver display state is retained
- Gfx9 resume robustness fix
The following changes since commit 0ab925d3690614aa44cd29fb84cdcef03eab97dc:
drm/amd/display: Only allow VRR when vrefr
On Wed, Apr 3, 2019 at 2:02 PM Alex Deucher wrote:
>
> On Wed, Apr 3, 2019 at 2:58 AM Braiam wrote:
> >
> > Hi,
> >
> > I have a Sapphire Technology Hawaii XT (R9 290X) using amdgpu driver
> > with kernel 5.1.0-rc3.
> > The issue happens with current 4.19.0 debian testing, 4.20-trunk,
> > 5.0.0-t
From: Martin Leung
[Why]
AUX takes longer to reply when using active DP-DVI dongle on some asics
resulting in up to 2000+ us edid read (timeout).
[How]
1. Adjust AUX poll to match spec
2. Extend the SW timeout. This does not affect normal
operation since we exit the loop as soon as AUX acks.
Si
From: Anthony Koo
[Why]
If link is already enabled at a different rate (for example 5.4 Gbps)
then calling VBIOS command table to switch to a new rate
(for example 2.7 Gbps) will not take effect.
This can lead to link training failure to occur.
[How]
If the requested link rate is different than
From: Dmytro Laktyushkin
Simply return true/false, don't iterate up the tree.
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Nikola Cornij
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/dr
From: Leo Li
[Why]
When entering S3, amdgpu first calls DRM to cache the current atomic
state, then commit the 'all-disabled' state. This sets dc->current_state
to point at the private atomic object's dm_atomic_state->context, as
any regular atomic commit would.
Afterwards, amdgpu_dm calls dc_s
From: Leo Li
[Why]
dcn*_disable_plane() doesn't unlock the pipe anymore, making the extra
lock unnecessary.
In addition - during full plane updates - all necessary pipes should be
locked/unlocked together when modifying hubp to avoid tearing in
pipesplit setups.
[How]
Remove redundant locks,
From: Nicholas Kazlauskas
[Why]
When deciding to add properties or expose formats on DRM planes we
should be querying the caps for the DC plane it's supposed to represent.
[How]
Pass plane caps down into plane initialization, refactoring overlay
plane initialization to have the overlay plane be
From: Murton Liu
[Why]
Checking against a TF that is unused causes us to default to black
[How]
Check against PQ instead
Signed-off-by: Murton Liu
Reviewed-by: Aric Cyr
Acked-by: Leo Li
Acked-by: Tony Cheng
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
1 file change
From: Josip Pavic
[Why]
Image brightness compensation for solid color full screen images is
expected to be optimal for ABM 2.2 at level 3. The min reduction that is
currently being enforced prevents this from being achieved.
[How]
Remove the min reduction for ABM 2.2 at level 3
Signed-off-by: J
From: Eric Yang
[Why]
New seamless boot sequence introduced a bug where front end is disabled
without blanking otg.
[How]
Adjust the condition of blanking otg to match seamless boot.
Signed-off-by: Eric Yang
Reviewed-by: Anthony Koo
Acked-by: Leo Li
Acked-by: Tony Cheng
---
drivers/gpu/drm
From: Nikola Cornij
[why]
Currently link bandwidth is calculated in two places, using the same
formula. They should be unified into calling one function.
[how]
Replace all implementations of link bandwidth calculation with a call
to a function.
Signed-off-by: Nikola Cornij
Reviewed-by: Nikola
From: Nicholas Kazlauskas
[Why]
We need DC's color space to match the color encoding and color space
specified by userspace to correctly render YUV surfaces.
[How]
Convert the DRM color encoding and color range properties to the
appropriate DC colorspace option and update the color space when
pe
From: Wenjing Liu
[why]
The existing calculation uses a wrong formula to
calculate bandwidth from timing.
[how]
Expose the existing proper function that calculates the bandwidth,
so dc_link can use it to calculate timing bandwidth correctly.
Signed-off-by: Wenjing Liu
Reviewed-by: Jun Lei
Ack
From: SivapiriyanKumarasamy
[Why]
We are incorrectly using dp_hdmi_max_pixel_clk because the units are not clear.
[How]
Rename to dp_hdmi_max_pixel_clk_in_khz, and change mode timing validation to use
the value correctly.
Signed-off-by: SivapiriyanKumarasamy
Reviewed-by: Aric Cyr
Acked-by: Le
From: Anthony Koo
[Why]
In some cases we want DC init to take in some config options
[How]
Init dc_config before rest of DC init
Signed-off-by: Anthony Koo
Reviewed-by: Aric Cyr
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
From: Wenjing Liu
[why]
when preferred link cap is set, we should always use
preferred in all validation.
we should not use preferred for some validation but use
verified for others.
[how]
create getter function that gets verified link cap.
if preferred is set, return preferred link settings ins
From: SivapiriyanKumarasamy
[Why]
In HDR configurations, the cursor - in SDR - needs to have it's white
level boosted.
[How]
Program the cursor boost in update_dchubp_dpp like the other cursor
attributes.
Signed-off-by: SivapiriyanKumarasamy
Reviewed-by: Anthony Koo
Acked-by: Leo Li
Acked-by
From: Su Sung Chung
[Why]
Before it was returning false in the case of failure even though return type
should be enum dc_status
[How]
Return DC_FAIL_UNSUPPORTED_1 instead
Signed-off-by: Su Sung Chung
Reviewed-by: Eric Yang
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_res
From: Nicholas Kazlauskas
[Why]
The input color space for the plane was previously ignored even if it
was set.
If a limited range YUV format was given to DC then the
wrong color transformation matrix was being used since DC assumed that
it was full range instead.
[How]
Respect the given color_s
From: Aric Cyr
Signed-off-by: Aric Cyr
Reviewed-by: Aric Cyr
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
b/drivers/gpu/drm/amd/display/dc/dc.h
index 54b0759..4cb9269 100644
--
From: Dmytro Laktyushkin
clk_mgr is called dccg in dc_state, this change fixes that
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Eric Bernstein
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc_resource.c
From: Leo Li
Summary of changed
* Add DM support for YUV planes
* Fix potential S3 resume bug
Anthony Koo (2):
drm/amd/display: init dc_config before rest of DC init
drm/amd/display: disable link before changing link settings
Aric Cyr (1):
drm/amd/display: 3.2.25
Dmytro Laktyushkin (2):
On 2019-04-03 1:24 p.m., Koenig, Christian wrote:
> Am 01.04.19 um 20:58 schrieb Kuehling, Felix:
>> On 2019-04-01 2:03 p.m., Christian König wrote:
>>> Am 01.04.19 um 19:59 schrieb Kuehling, Felix:
On 2019-04-01 7:23 a.m., Christian König wrote:
> Am 30.03.19 um 01:41 schrieb Kuehling, Fe
On Wed, Apr 03, 2019 at 09:20:39AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 03, 2019 at 10:27:42AM -0400, Mathieu Desnoyers wrote:
> > - On Apr 3, 2019, at 9:32 AM, paulmck paul...@linux.ibm.com wrote:
> >
> > > On Tue, Apr 02, 2019 at 11:34:07AM -0400, Mathieu Desnoyers wrote:
> > >>
On Wed, Apr 3, 2019 at 2:58 AM Braiam wrote:
>
> Hi,
>
> I have a Sapphire Technology Hawaii XT (R9 290X) using amdgpu driver
> with kernel 5.1.0-rc3.
> The issue happens with current 4.19.0 debian testing, 4.20-trunk,
> 5.0.0-trunk and rc2 and 3.
>
> It usually happens when I'm reproducing video,
Reviewed-by: Kent Russell
Kent
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, April 3, 2019 1:35 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdkfd: Add picasso pci id
Picasso is a new raven variant.
Signed-off-by: Al
Picasso is a new raven variant.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index b3cdbf79f47b..2fee3063a0d6 100644
--- a/drivers/gpu
Am 01.04.19 um 20:58 schrieb Kuehling, Felix:
> On 2019-04-01 2:03 p.m., Christian König wrote:
>> Am 01.04.19 um 19:59 schrieb Kuehling, Felix:
>>> On 2019-04-01 7:23 a.m., Christian König wrote:
Am 30.03.19 um 01:41 schrieb Kuehling, Felix:
> Patches 1-3 are Reviewed-by: Felix Kuehling
Thanks , changed as suggested and pushed
Shaoyun.liu
On 2019-04-03 1:12 p.m., Christian König wrote:
> Am 03.04.19 um 17:42 schrieb Liu, Shaoyun:
>> On XGMI configuration the ib test may tooks longer to finish
>>
>> Change-Id: If3afd8eac3c342d32c387804b51fc4a4bdd35d35
>> Signed-off-by: shaoyunl
Am 03.04.19 um 17:42 schrieb Liu, Shaoyun:
On XGMI configuration the ib test may tooks longer to finish
Change-Id: If3afd8eac3c342d32c387804b51fc4a4bdd35d35
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On Wed, Apr 03, 2019 at 10:27:42AM -0400, Mathieu Desnoyers wrote:
> - On Apr 3, 2019, at 9:32 AM, paulmck paul...@linux.ibm.com wrote:
>
> > On Tue, Apr 02, 2019 at 11:34:07AM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 2, 2019, at 11:23 AM, paulmck paul...@linux.ibm.com wrote:
> >>
>
On XGMI configuration the ib test may take longer to finish
Change-Id: If3afd8eac3c342d32c387804b51fc4a4bdd35d35
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/dri
On Wed, Apr 3, 2019 at 11:42 AM Liu, Shaoyun wrote:
>
> On XGMI configuration the ib test may tooks longer to finish
>
> Change-Id: If3afd8eac3c342d32c387804b51fc4a4bdd35d35
> Signed-off-by: shaoyunl
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 de
On XGMI configuration the ib test may tooks longer to finish
Change-Id: If3afd8eac3c342d32c387804b51fc4a4bdd35d35
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/dr
- On Apr 3, 2019, at 9:32 AM, paulmck paul...@linux.ibm.com wrote:
> On Tue, Apr 02, 2019 at 11:34:07AM -0400, Mathieu Desnoyers wrote:
>> - On Apr 2, 2019, at 11:23 AM, paulmck paul...@linux.ibm.com wrote:
>>
>> > On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote:
>> >> -
On Tue, Apr 02, 2019 at 11:34:07AM -0400, Mathieu Desnoyers wrote:
> - On Apr 2, 2019, at 11:23 AM, paulmck paul...@linux.ibm.com wrote:
>
> > On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 2, 2019, at 10:28 AM, paulmck paul...@linux.ibm.com wrote:
> >>
>
On Tue, Apr 02, 2019 at 02:40:54PM -0400, Joel Fernandes wrote:
> On Tue, Apr 02, 2019 at 08:23:34AM -0700, Paul E. McKenney wrote:
> > On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote:
> > > - On Apr 2, 2019, at 10:28 AM, paulmck paul...@linux.ibm.com wrote:
> > >
> > > > Hel
On 4/2/19 10:26 PM, tiancyin wrote:
> [Why]
> the member sdr_white_level of struct dc_cursor_attributes was not
> initialized, then the random value result that
> dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal
> value is 0x3c00), this cause the black cursor issue.
>
> [h
Am 03.04.19 um 08:33 schrieb wentalou:
amdgpu_bo_restore_shadow would assign zero to r if succeeded.
r would remain zero if there is only one node in shadow_list.
current code would always return failure when r <= 0.
restart the timeout for each wait was a rather problematic bug as well.
The valu
Am 02.04.19 um 20:12 schrieb Liu, Shaoyun:
On XGMI configuration the ib test may tooks longer to finish
Change-Id: If3afd8eac3c342d32c387804b51fc4a4bdd35d35
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/d
On 2019-04-02 8:13 p.m., Marek Olšák wrote:
> As you probably noticed, I don't use gitlab for my own patches yet.
It's not optional for xf86-video-amdgpu.
Per
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/30#note_125584
, I ended up not using this patch, instead onl
Mhm, that sounds like another bug to me which we need to investigate.
Probably a race during freeing of shadow allocations.
Christian.
Am 03.04.19 um 08:35 schrieb Lou, Wentao:
> Hi Christian,
>
> Sometimes shadow->parent would be NULL in my testbed, but not reproduce
> today...
> Just sent out
43 matches
Mail list logo