RE: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update()

[Wu, Hersen]

[AMD Official Use Only - General]

+ Charlie Wang

-Original Message-
From: Alex Deucher 
Sent: Tuesday, August 29, 2023 11:44 AM
To: Jani Nikula 
Cc: Hung, Alex ; dri-de...@lists.freedesktop.org; 
amd-gfx@lists.freedesktop.org; Li, Sun peng (Leo) ; 
intel-...@lists.freedesktop.org; Siqueira, Rodrigo ; 
Wheeler, Daniel ; Wu, Hersen ; 
Chien, WenChieh (Jay) ; Deucher, Alexander 

Subject: Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using 
drm_edid_override_connector_update()

On Tue, Aug 29, 2023 at 6:48 AM Jani Nikula  wrote:
>
> On Wed, 23 Aug 2023, Jani Nikula  wrote:
> > On Tue, 22 Aug 2023, Alex Hung  wrote:
> >> On 2023-08-22 06:01, Jani Nikula wrote:
> >>> Over the past years I've been trying to unify the override and
> >>> firmware EDID handling as well as EDID property updates. It won't
> >>> work if drivers do their own random things.
> >> Let's check how to replace these references by appropriate ones or
> >> fork the function as reverting these patches causes regressions.
> >
> > I think the fundamental problem you have is conflating connector
> > forcing with EDID override. They're orthogonal. The .force callback
> > has no business basing the decisions on connector->edid_override.
> > Force is force, override is override.
> >
> > The driver isn't even supposed to know or care if the EDID
> > originates from the firmware loader or override EDID debugfs.
> > drm_get_edid() will handle that for you transparently. It'll return
> > the EDID, and you shouldn't look at connector->edid_blob_ptr either.
> > Using that will make future work in drm_edid.c harder.
> >
> > You can't fix that with minor tweaks. I think you'll be better off
> > starting from scratch.
> >
> > Also, connector->edid_override is debugfs. You actually can change
> > the behaviour. If your userspace, whatever it is, has been written
> > to assume connector forcing if EDID override is set, you *do* have
> > to fix that, and set both.
>
> Any updates on fixing this, or shall we proceed with the reverts?

What is the goal of the reverts?  I don't disagree that we may be using the 
interfaces wrong, but reverting them will regess functionality in the driver.

Alex

RE: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update()

[Wu, Hersen]

[AMD Official Use Only - General]

+ Charlie

-Original Message-
From: Jani Nikula 
Sent: Tuesday, August 29, 2023 6:49 AM
To: Hung, Alex ; dri-de...@lists.freedesktop.org; 
amd-gfx@lists.freedesktop.org
Cc: Li, Sun peng (Leo) ; David Airlie ; 
intel-...@lists.freedesktop.org; Siqueira, Rodrigo ; 
Wheeler, Daniel ; Wu, Hersen ; 
Daniel Vetter ; Chien, WenChieh (Jay) 
; Deucher, Alexander ; 
Wentland, Harry 
Subject: Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using 
drm_edid_override_connector_update()

On Wed, 23 Aug 2023, Jani Nikula  wrote:
> On Tue, 22 Aug 2023, Alex Hung  wrote:
>> On 2023-08-22 06:01, Jani Nikula wrote:
>>> Over the past years I've been trying to unify the override and
>>> firmware EDID handling as well as EDID property updates. It won't
>>> work if drivers do their own random things.
>> Let's check how to replace these references by appropriate ones or
>> fork the function as reverting these patches causes regressions.
>
> I think the fundamental problem you have is conflating connector
> forcing with EDID override. They're orthogonal. The .force callback
> has no business basing the decisions on connector->edid_override.
> Force is force, override is override.
>
> The driver isn't even supposed to know or care if the EDID originates
> from the firmware loader or override EDID debugfs. drm_get_edid() will
> handle that for you transparently. It'll return the EDID, and you
> shouldn't look at connector->edid_blob_ptr either. Using that will
> make future work in drm_edid.c harder.
>
> You can't fix that with minor tweaks. I think you'll be better off
> starting from scratch.
>
> Also, connector->edid_override is debugfs. You actually can change the
> behaviour. If your userspace, whatever it is, has been written to
> assume connector forcing if EDID override is set, you *do* have to fix
> that, and set both.

Any updates on fixing this, or shall we proceed with the reverts?

BR,
Jani.



>
> BR,
> Jani.
>
>
>>
>> Cheers,
>> Alex
>>
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>> Cc: Alex Deucher 
>>> Cc: Alex Hung 
>>> Cc: Chao-kai Wang 
>>> Cc: Daniel Wheeler 
>>> Cc: Harry Wentland 
>>> Cc: Hersen Wu 
>>> Cc: Leo Li 
>>> Cc: Rodrigo Siqueira 
>>> Cc: Wenchieh Chien 
>>> Cc: David Airlie 
>>> Cc: Daniel Vetter 
>>>
>>> Jani Nikula (4):
>>>Revert "drm/amd/display: drop unused count variable in
>>>  create_eml_sink()"
>>>Revert "drm/amd/display: assign edid_blob_ptr with edid from debugfs"
>>>Revert "drm/amd/display: mark amdgpu_dm_connector_funcs_force static"
>>>Revert "drm/amd/display: implement force function in
>>>  amdgpu_dm_connector_funcs"
>>>
>>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 44 +++
>>>   1 file changed, 5 insertions(+), 39 deletions(-)
>>>

--
Jani Nikula, Intel Open Source Graphics Center

RE: [PATCH] drm/amd/display: fix flickering caused by S/G mode

[Wu, Hersen]

[AMD Official Use Only - General]

Hi,

The change applies to all AMD GPU ASIC.
Please communicate with issue reporter to see if the issue could be reproduced 
older ASIC, like Mendocino, CZN.

Thanks!
Hersen


-Original Message-
From: Mahfooz, Hamza  
Sent: Monday, April 17, 2023 11:26 AM
To: Koenig, Christian ; amd-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org; Wentland, Harry ; Li, Sun 
peng (Leo) ; Siqueira, Rodrigo ; 
Deucher, Alexander ; Pan, Xinhui 
; David Airlie ; Daniel Vetter 
; Pillai, Aurabindo ; Zhuo, Qingqing 
(Lillian) ; Hans de Goede ; Wu, 
Hersen ; Wang, Chao-kai (Stylon) ; 
Tuikov, Luben ; dri-de...@lists.freedesktop.org; 
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode


On 4/17/23 11:03, Christian König wrote:
> Am 17.04.23 um 16:51 schrieb Hamza Mahfooz:
>>
>> On 4/17/23 01:59, Christian König wrote:
>>> Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:
>>>> Currently, we allow the framebuffer for a given plane to move 
>>>> between memory domains, however when that happens it causes the 
>>>> screen to flicker, it is even possible for the framebuffer to 
>>>> change memory domains on every plane update (causing a continuous flicker 
>>>> effect).
>>>> So,
>>>> to fix this, don't perform an immediate flip in the aforementioned 
>>>> case.
>>>
>>> That sounds strongly like you just forget to wait for the move to 
>>> finish!
>>>
>>> What is the order of things done here? E.g. who calls 
>>> amdgpu_bo_pin() and who waits for fences for finish signaling? Is 
>>> that maybe just in the wrong order?
>>
>> The pinning logic is in dm_plane_helper_prepare_fb(). Also, it seems 
>> like we wait for the fences in amdgpu_dm_atomic_commit_tail(), using 
>> drm_atomic_helper_wait_for_fences(). The ordering should be fine as 
>> well, since prepare_fb() is always called before atomic_commit_tail().
> 
> Ok, then why is there any flickering?
> 
> BTW reserving a fence slot is completely unnecessary. That looks like 
> you copy the code from somewhere else without checking what it 
> actually does.

It seemed like it was necessary to read `tbo.resource` since the documentation 
for `struct ttm_buffer_object` makes mention of a "bo::resv::reserved" lock.

> 
> Regards,
> Christian.
> 
>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>>
>>>> Cc: sta...@vger.kernel.org
>>>> Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more 
>>>> flexible
>>>> (v2)")
>>>> Signed-off-by: Hamza Mahfooz 
>>>> ---
>>>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41
>>>> ++-
>>>>   1 file changed, 39 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> index da3045fdcb6d..9a4e7408384a 100644
>>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> @@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct 
>>>> drm_atomic_state *state)
>>>>   amdgpu_dm_plane_handle_cursor_update(plane,
>>>> old_plane_state);
>>>>   }
>>>> +static inline uint32_t get_mem_type(struct amdgpu_device *adev,
>>>> +    struct drm_gem_object *obj,
>>>> +    bool check_domain) {
>>>> +    struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
>>>> +    uint32_t mem_type;
>>>> +
>>>> +    if (unlikely(amdgpu_bo_reserve(abo, true)))
>>>> +    return 0;
>>>> +
>>>> +    if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
>>>> +    goto err;
>>>> +
>>>> +    if (check_domain &&
>>>> +    amdgpu_display_supported_domains(adev, abo->flags) !=
>>>> +    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
>>>> +    goto err;
>>>> +
>>>> +    mem_type = abo->tbo.resource->mem_type;
>>>> +    amdgpu_bo_unreserve(abo);
>>>> +
>>>> +    return mem_type;
>>>> +
>>>> +err:
>>>> +    amdgpu_bo_unreserve(abo);
>>>> +    return 0;
>>>> +}
>>>> +
>>>>   static void amdgpu_dm_commit_planes(struct drm_atomic_state 
>>>> *state,

RE: [PATCH] drm/amd/display: Fix dsc mismatch of acquire and validationn of dsc engine

[Wu, Hersen]

[AMD Official Use Only - General]

Reviewed-by: Hersen Wu 

Regards!
Hersen


-Original Message-
From: Bhawanpreet Lakha  
Sent: Wednesday, December 21, 2022 1:44 PM
To: Swarnakar, Praful ; Wu, Hersen 
; Deucher, Alexander 
Cc: amd-gfx@lists.freedesktop.org; Lakha, Bhawanpreet 
; Liu, Wenjing 
Subject: [PATCH] drm/amd/display: Fix dsc mismatch of acquire and validationn 
of dsc engine

[Why]
We skip dsc_validation on pipes that are underlays, but in the acquire_dsc code 
we don't have this check.

In certain conditions (when underlay pipe index is lower) we will assign the 
dsc resource to the underlay pipe and skip the base pipe.

Now during dsc_validation we will skip the underlay pipe (this has the dsc 
resource) but try to validate the base pipe(this doesn't have a dsc
resource) due to this mismatch we hit a NULLPTR

[How]
In the acquire_dsc add a check for underlay pipe so we don't acquire a dsc 
resource for this pipe. This will match the acquire/validation conditions.

Reviewed-by: Wenjing Liu 
Signed-off-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index d0199ec045cb..f97d8ff16e71 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -1382,6 +1382,9 @@ enum dc_status dcn20_add_dsc_to_stream_resource(struct dc 
*dc,
for (i = 0; i < dc->res_pool->pipe_count; i++) {
struct pipe_ctx *pipe_ctx = _ctx->res_ctx.pipe_ctx[i];
 
+   if (pipe_ctx->top_pipe)
+   continue;
+
if (pipe_ctx->stream != dc_stream)
continue;
 
--
2.25.1

RE: [PATCH] drm/amd/display: Program color range and encoding correctly for DCN2+

[Wu, Hersen]

Reviewed-by: Hersen Wu 


-Original Message-
From: Chauhan, Ikshwaku  
Sent: Thursday, March 24, 2022 3:12 AM
To: Wentland, Harry ; amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; sta...@vger.kernel.org; Wu, 
Hersen ; Kazlauskas, Nicholas 
; VURDIGERENATARAJ, CHANDAN 

Subject: RE: [PATCH] drm/amd/display: Program color range and encoding 
correctly for DCN2+

[AMD Official Use Only]


Tested-by: ikshwaku.chau...@amd.com


Thanks, 
Ikshwaku Chauhan


-Original Message-
From: Harry Wentland  
Sent: Thursday, March 24, 2022 2:39 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; sta...@vger.kernel.org; Wu, 
Hersen ; Chauhan, Ikshwaku ; 
Kazlauskas, Nicholas ; VURDIGERENATARAJ, CHANDAN 

Subject: [PATCH] drm/amd/display: Program color range and encoding correctly 
for DCN2+

[Why]
DCN2 CNVC programming did not respect the input_color_space and was therefore 
programming the wrong CSC matrix for YUV to RGB conversion, leading to a wrong 
image. In particular blacks for limited range videos would show as dark grey.

[How]
Do what DCN1 does and use the input_color_space info in dpp_setup if it's 
available.

Signed-off-by: Harry Wentland 
Cc: sta...@vger.kernel.org
Cc: hersenxs...@amd.com
Cc: ikshwaku.chau...@amd.com
Cc: nicholas.kazlaus...@amd.com
Cc: chandan.vurdigerenata...@amd.com
---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c   | 3 +++
 drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c | 3 +++
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c   | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c
index 970b65efeac1..eaa7032f0f1a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c
@@ -212,6 +212,9 @@ static void dpp2_cnv_setup (
break;
}
 
+   /* Set default color space based on format if none is given. */
+   color_space = input_color_space ? input_color_space : color_space;
+
if (is_2bit == 1 && alpha_2bit_lut != NULL) {
REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, 
alpha_2bit_lut->lut0);
REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, 
alpha_2bit_lut->lut1); diff --git 
a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c 
b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c
index 8b6505b7dca8..f50ab961bc17 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c
@@ -153,6 +153,9 @@ static void dpp201_cnv_setup(
break;
}
 
+   /* Set default color space based on format if none is given. */
+   color_space = input_color_space ? input_color_space : color_space;
+
if (is_2bit == 1 && alpha_2bit_lut != NULL) {
REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, 
alpha_2bit_lut->lut0);
REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, 
alpha_2bit_lut->lut1); diff --git 
a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c 
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
index ab3918c0a15b..0dcc07531643 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
@@ -294,6 +294,9 @@ static void dpp3_cnv_setup (
break;
}
 
+   /* Set default color space based on format if none is given. */
+   color_space = input_color_space ? input_color_space : color_space;
+
if (is_2bit == 1 && alpha_2bit_lut != NULL) {
REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, 
alpha_2bit_lut->lut0);
REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, 
alpha_2bit_lut->lut1);
--
2.35.1

RE: [PATCH] drm/amd/display: Not to call dpcd_set_source_specific_data during resume.

[Wu, Hersen]

[AMD Official Use Only]

Hi Rajib,

For resume from s3 or si03, the change should work.

Reviewed-by: Hersen Wu 

For boot up, at the location of your change, link->dpcd_sink_ext_caps.bits.oled 
= 0.
OLED caps is read by dpcd_read_sink_ext_caps which is called within  
detect_edp_sink_caps.

For boot up, we need another change.

Thanks!
Hersen



-Original Message-
From: Mahapatra, Rajib  
Sent: Thursday, January 20, 2022 2:33 PM
To: Wentland, Harry ; Wu, Hersen ; 
Deucher, Alexander 
Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
Subject: RE: [PATCH] drm/amd/display: Not to call dpcd_set_source_specific_data 
during resume.

Hi Hersen,
I am waiting for your comments here.
I think we can take this change for resume path at this moment.
For bootup, we can have separate patch for resume optimization. 

Thanks
-Rajib

-Original Message-
From: Wentland, Harry  
Sent: Tuesday, January 11, 2022 9:47 PM
To: Mahapatra, Rajib ; Wu, Hersen 
; Deucher, Alexander 
Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
Subject: Re: [PATCH] drm/amd/display: Not to call dpcd_set_source_specific_data 
during resume.



On 2022-01-11 02:52, Mahapatra, Rajib wrote:
> dpcd_set_source_specific_data is not specific to OLED panel.  It is called 
> from boot-up path also.
> Hersen Wu introduced it in resume-path while enabling OLED panel for Linux in 
> below commit.
> 

If we set it in the boot-up path we'll probably want to set it on resume as 
well. Though I'll let Hersen comment since he knows this part much better than 
me.

Harry

> So here, I guard it by calling source specific data only for OLED panel, and 
> I can get advantage of around 100ms for non-oled panel during resume. Hersen 
> night have answer about the issue related to regression for other panels, 
> waiting for his reply about this change.
> 
> commit 96577cf82a1331732a71199522398120c649f1cf
> Author: Hersen Wu 
> Date:   Tue Jan 14 15:39:07 2020 -0500
> 
> drm/amd/display: linux enable oled panel support dc part
> 
> 
> 
> -Original Message-
> From: Wentland, Harry 
> Sent: Monday, January 10, 2022 10:03 PM
> To: Mahapatra, Rajib ; Wu, Hersen 
> ; Deucher, Alexander 
> Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
> Subject: Re: [PATCH] drm/amd/display: Not to call 
> dpcd_set_source_specific_data during resume.
> 
> On 2022-01-10 04:06, Rajib Mahapatra wrote:
>> [Why]
>> During resume path, dpcd_set_source_specific_data is taking extra 
>> time when core_link_write_dpcd fails on DP_SOURCE_OUI+0x03 and 
>> DP_SOURCE_MINIMUM_HBLANK_SUPPORTED. Here,aux->transfer fails with 
>> multiple retries and consume sigficantamount time during
>> S0i3 resume.
>>
>> [How]
>> Not to call dpcd_set_source_specific_data during resume path when 
>> there is no oled panel connected and achieve faster resume during 
>> S0i3.
>>
>> Signed-off-by: Rajib Mahapatra 
>> ---
>>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
>> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
>> index c0bdc23702c8..04086c199dbb 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
>> @@ -892,7 +892,8 @@ static bool dc_link_detect_helper(struct dc_link *link,
>>  (!link->dc->config.allow_edp_hotplug_detection)) &&
>>  link->local_sink) {
>>  // need to re-write OUI and brightness in resume case
>> -if (link->connector_signal == SIGNAL_TYPE_EDP) {
>> +if (link->connector_signal == SIGNAL_TYPE_EDP &&
>> +(link->dpcd_sink_ext_caps.bits.oled == 1)) {
> 
> Is the source specific data only used by OLED panels?
> 
> Do we know that this won't lead to regressions with any features on non-OLED 
> panels?
> 
> Harry
> 
>>  dpcd_set_source_specific_data(link);
>>  msleep(post_oui_delay);
>>  dc_link_set_default_brightness_aux(link);
> 

[PATCH] drm/amd/display: add dcn register DP_MSA_VBID_MISC for dcn1.x and dcn2.x

[Wu, Hersen]

[AMD Official Use Only]

This patch add missing AMD ASIC register for DP programming in up stream.

>From 05768b78865d9b41a1d35e9f8e34901321208f2a Mon Sep 17 00:00:00 2001
From: Hersen Wu herse...@amd.com
Date: Thu, 26 Aug 2021 12:49:08 -0400
Subject: [PATCH] drm/amd/display: add dcn register DP_MSA_VBID_MISC for dcn1.x
and dcn2.x

DP_MSA_VBID_MISC is missing in upstream. this register is needed
for DP programming.

Signed-off-by: Hersen Wu herse...@amd.com
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.h | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.h 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.h
index 0d86df97878c..35acb3342e31 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.h
@@ -73,6 +73,7 @@
   SRI(HDMI_ACR_48_1, DIG, id),\
   SRI(DP_DB_CNTL, DP, id), \
   SRI(DP_MSA_MISC, DP, id), \
+ SRI(DP_MSA_VBID_MISC, DP, id), \
   SRI(DP_MSA_COLORIMETRY, DP, id), \
   SRI(DP_MSA_TIMING_PARAM1, DP, id), \
   SRI(DP_MSA_TIMING_PARAM2, DP, id), \
--
2.17.1

RE: [PATCH v3] drm/amd/display: Reject non-zero src_y and src_x for video planes

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Hersen Wu 

-Original Message-
From: Harry Wentland  
Sent: Friday, April 23, 2021 10:12 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; sta...@vger.kernel.org; 
Kazlauskas, Nicholas ; Deucher, Alexander 
; Li, Roman ; Wu, Hersen 
; Wang, Danny 
Subject: [PATCH v3] drm/amd/display: Reject non-zero src_y and src_x for video 
planes

[Why]
This hasn't been well tested and leads to complete system hangs on DCN1 based 
systems, possibly others.

The system hang can be reproduced by gesturing the video on the YouTube Android 
app on ChromeOS into full screen.

[How]
Reject atomic commits with non-zero drm_plane_state.src_x or src_y values.

v2:
 - Add code comment describing the reason we're rejecting non-zero
   src_x and src_y
 - Drop gerrit Change-Id
 - Add stable CC
 - Based on amd-staging-drm-next

v3: removed trailing whitespace

Signed-off-by: Harry Wentland 
Cc: sta...@vger.kernel.org
Cc: nicholas.kazlaus...@amd.com
Cc: amd-gfx@lists.freedesktop.org
Cc: alexander.deuc...@amd.com
Cc: roman...@amd.com
Cc: hersenxs...@amd.com
Cc: danny.w...@amd.com
Reviewed-by: Nicholas Kazlauskas 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index be1769d29742..aeedc5a3fb36 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4089,6 +4089,23 @@ static int fill_dc_scaling_info(const struct 
drm_plane_state *state,
scaling_info->src_rect.x = state->src_x >> 16;
scaling_info->src_rect.y = state->src_y >> 16;
 
+   /*
+* For reasons we don't (yet) fully understand a non-zero
+* src_y coordinate into an NV12 buffer can cause a
+* system hang. To avoid hangs (and maybe be overly cautious)
+* let's reject both non-zero src_x and src_y.
+*
+* We currently know of only one use-case to reproduce a
+* scenario with non-zero src_x and src_y for NV12, which
+* is to gesture the YouTube Android app into full screen
+* on ChromeOS.
+*/
+   if (state->fb &&
+   state->fb->format->format == DRM_FORMAT_NV12 &&
+   (scaling_info->src_rect.x != 0 ||
+scaling_info->src_rect.y != 0))
+   return -EINVAL;
+
scaling_info->src_rect.width = state->src_w >> 16;
if (scaling_info->src_rect.width == 0)
return -EINVAL;
--
2.31.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH v2] Revert "drm/amd/display: Tune min clk values for MPO for RV"

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]


Reviewed-by: Hersen Wu 


-Original Message-
From: Vishwakarma, Pratik  
Sent: Wednesday, January 20, 2021 11:52 PM
To: Wu, Hersen ; Wentland, Harry ; 
amd-gfx@lists.freedesktop.org
Cc: Vishwakarma, Pratik 
Subject: [PATCH v2] Revert "drm/amd/display: Tune min clk values for MPO for RV"

This reverts commit 6f3fca64cfb91fedf9b34ea27b2581e88d48c9b2.
Original issue of flash line when MPO enabled on idle screen was fixed by 
raising clocks. This had negative effect of extra power being drained. With the 
upstream commit 9d03bb102028
("drm/amd/display: disable dcn10 pipe split by default") flash line issue was 
fixed and had positive effect for battery life. Hence this patch is no more 
required.

Signed-off-by: Pratik Vishwakarma 
---
 .../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c| 30 ++-
 1 file changed, 3 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
index 75b8240ed059..e133edc587d3 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
@@ -187,17 +187,6 @@ static void ramp_up_dispclk_with_dpp(
clk_mgr->base.clks.max_supported_dppclk_khz = 
new_clocks->max_supported_dppclk_khz;
 }
 
-static bool is_mpo_enabled(struct dc_state *context) -{
-   int i;
-
-   for (i = 0; i < context->stream_count; i++) {
-   if (context->stream_status[i].plane_count > 1)
-   return true;
-   }
-   return false;
-}
-
 static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,
struct dc_state *context,
bool safe_to_lower)
@@ -295,22 +284,9 @@ static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,
if (pp_smu->set_hard_min_fclk_by_freq &&
pp_smu->set_hard_min_dcfclk_by_freq &&
pp_smu->set_min_deep_sleep_dcfclk) {
-   // Only increase clocks when display is active and MPO 
is enabled
-   if (display_count && is_mpo_enabled(context)) {
-   
pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu,
-   ((new_clocks->fclk_khz / 1000) 
*  101) / 100);
-   
pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu,
-   ((new_clocks->dcfclk_khz / 
1000) * 101) / 100);
-   
pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu,
-   
(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
-   } else {
-   
pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu,
-   new_clocks->fclk_khz / 1000);
-   
pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu,
-   new_clocks->dcfclk_khz / 1000);
-   
pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu,
-   
(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
-   }
+   pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu, 
new_clocks->fclk_khz / 1000);
+   pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu, 
new_clocks->dcfclk_khz / 1000);
+   pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu, 
+(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
}
}
 }
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] Revert "drm/amd/display: Tune min clk values for MPO for RV"

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Hersen Wu 

-Original Message-
From: Vishwakarma, Pratik  
Sent: Monday, January 18, 2021 6:04 AM
To: Wu, Hersen ; amd-gfx@lists.freedesktop.org
Cc: Vishwakarma, Pratik 
Subject: [PATCH] Revert "drm/amd/display: Tune min clk values for MPO for RV"

This reverts commit 6f3fca64cfb91fedf9b34ea27b2581e88d48c9b2.
Flash line issue when MPO enabled on idle screen was fixed by commit 
9d03bb102028 ("drm/amd/display: disable dcn10 pipe split by default")

This patch is no more required

Signed-off-by: Pratik Vishwakarma 
---
 .../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c| 30 ++-
 1 file changed, 3 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
index 75b8240ed059..e133edc587d3 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
@@ -187,17 +187,6 @@ static void ramp_up_dispclk_with_dpp(
clk_mgr->base.clks.max_supported_dppclk_khz = 
new_clocks->max_supported_dppclk_khz;
 }
 
-static bool is_mpo_enabled(struct dc_state *context) -{
-   int i;
-
-   for (i = 0; i < context->stream_count; i++) {
-   if (context->stream_status[i].plane_count > 1)
-   return true;
-   }
-   return false;
-}
-
 static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,
struct dc_state *context,
bool safe_to_lower)
@@ -295,22 +284,9 @@ static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,
if (pp_smu->set_hard_min_fclk_by_freq &&
pp_smu->set_hard_min_dcfclk_by_freq &&
pp_smu->set_min_deep_sleep_dcfclk) {
-   // Only increase clocks when display is active and MPO 
is enabled
-   if (display_count && is_mpo_enabled(context)) {
-   
pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu,
-   ((new_clocks->fclk_khz / 1000) 
*  101) / 100);
-   
pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu,
-   ((new_clocks->dcfclk_khz / 
1000) * 101) / 100);
-   
pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu,
-   
(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
-   } else {
-   
pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu,
-   new_clocks->fclk_khz / 1000);
-   
pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu,
-   new_clocks->dcfclk_khz / 1000);
-   
pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu,
-   
(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
-   }
+   pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu, 
new_clocks->fclk_khz / 1000);
+   pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu, 
new_clocks->dcfclk_khz / 1000);
+   pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu, 
+(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
}
}
 }
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/display: disable dcn10 pipe split by default

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

[Why] the initial purpose of dcn10 pipe split is to support
some high bandwidth mode which requires dispclk greater
than max dispclk. By initial bring up power measurement
data, it showed power consumption is less with pipe split
for dcn block. This could be reason for enable pipe split
by default. By battery life measurement of some Chromebooks,
result shows battery life is longer with pipe split disabled.

[How] disable pipe split by default. Pipe split could be
still enabled when required dispclk is greater than max dispclk.

Signed-off-by: hersen wu 
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
index bdc37831535e..17eafe209946 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
@@ -608,8 +608,8 @@ static const struct dc_debug_options debug_defaults_drv = {
  .disable_pplib_clock_request = false,
  .disable_pplib_wm_range = false,
  .pplib_wm_report_mode = WM_REPORT_DEFAULT,
- .pipe_split_policy = MPC_SPLIT_DYNAMIC,
- .force_single_disp_pipe_split = true,
+ .pipe_split_policy = MPC_SPLIT_AVOID,
+ .force_single_disp_pipe_split = false,
  .disable_dcc = DCC_ENABLE,
  .voltage_align_fclk = true,
  .disable_stereo_support = true,
--
2.17.1


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/display: Tune fclk for 4K OLED display

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Hersen Wu 


-Original Message-
From: Vishwakarma, Pratik  
Sent: Monday, November 9, 2020 12:39 AM
To: Wu, Hersen ; amd-gfx@lists.freedesktop.org
Cc: Vishwakarma, Pratik 
Subject: [PATCH] drm/amd/display: Tune fclk for 4K OLED display

[Why]
On 4K SKU, in DC mode, there is a visible slowness observed on system compared 
to AC mode.

[How]
Tuning min fclk up by 2% resolved this issue.

Signed-off-by: Pratik Vishwakarma 
---
 .../gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c   | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
index 832a43053420..ead009628c48 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
@@ -210,6 +210,7 @@ static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,
bool send_request_to_increase = false;
bool send_request_to_lower = false;
int display_count;
+   int i, clock_factor = 0;
 
bool enter_display_off = false;
 
@@ -217,6 +218,12 @@ static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,
 
pp_smu = _mgr->pp_smu->rv_funcs;
 
+   for (i = 0; i < context->stream_count; i++) {
+   if (context->streams[i]->timing.h_total > 3840
+   || context->streams[i]->timing.v_total > 2160)
+   clock_factor = 2;
+   }
+
display_count = clk_mgr_helper_get_active_display_cnt(dc, context);
 
if (display_count == 0)
@@ -302,7 +309,7 @@ static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,

(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
} else {

pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu,
-   new_clocks->fclk_khz / 1000);
+   ((new_clocks->fclk_khz / 1000) 
* (100 + clock_factor)) / 100);

pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu,
new_clocks->dcfclk_khz / 1000);

pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu,
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/display: Reject overlay plane configurations in multi-display scenarios

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]


Reviewed-by: Hersen Wu 



-Original Message-
From: Nicholas Kazlauskas  
Sent: Wednesday, August 19, 2020 1:56 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Wu, Hersen 

Subject: [PATCH] drm/amd/display: Reject overlay plane configurations in 
multi-display scenarios

[Why]
These aren't stable on some platform configurations when driving multiple 
displays, especially on higher resolution.

In particular the delay in asserting p-state and validating from
x86 outweights any power or performance benefit from the hardware composition.

Under some configurations this will manifest itself as extreme stutter or 
unresponsiveness especially when combined with cursor movement.

[How]
Disable these for now. Exposing overlays to userspace doesn't guarantee that 
they'll be able to use them in any and all configurations and it's part of the 
DRM contract to have userspace gracefully handle validation failures when they 
occur.

Valdiation occurs as part of DC and this in particular affects RV, so disable 
this in dcn10_global_validation.

Cc: Hersen Wu 
Signed-off-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
index 07571f84e0f8..1abd81e17f09 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
@@ -1213,6 +1213,7 @@ static enum dc_status dcn10_validate_global(struct dc 
*dc, struct dc_state *cont
bool video_large = false;
bool desktop_large = false;
bool dcc_disabled = false;
+   bool mpo_enabled = false;
 
for (i = 0; i < context->stream_count; i++) {
if (context->stream_status[i].plane_count == 0) @@ -1221,6 
+1222,9 @@ static enum dc_status dcn10_validate_global(struct dc *dc, struct 
dc_state *cont
if (context->stream_status[i].plane_count > 2)
return DC_FAIL_UNSUPPORTED_1;
 
+   if (context->stream_status[i].plane_count > 1)
+   mpo_enabled = true;
+
for (j = 0; j < context->stream_status[i].plane_count; j++) {
struct dc_plane_state *plane =
context->stream_status[i].plane_states[j];
@@ -1244,6 +1248,10 @@ static enum dc_status dcn10_validate_global(struct dc 
*dc, struct dc_state *cont
}
}
 
+   /* Disable MPO in multi-display configurations. */
+   if (context->stream_count > 1 && mpo_enabled)
+   return DC_FAIL_UNSUPPORTED_1;
+
/*
 * Workaround: On DCN10 there is UMC issue that causes underflow when
 * playing 4k video on 4k desktop with video downscaled and single 
channel
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/dc: Read from DP_SINK_COUNT_ESI for DPDC r1.2 or higher

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]



-Original Message-
From: Pillai, Aurabindo  
Sent: Tuesday, August 4, 2020 9:56 AM
To: Lin, Wayne ; amd-gfx@lists.freedesktop.org
Cc: Wu, Hersen ; Kazlauskas, Nicholas 
; Siqueira, Rodrigo ; 
Zuo, Jerry 
Subject: Re: [PATCH] drm/amd/dc: Read from DP_SINK_COUNT_ESI for DPDC r1.2 or 
higher

On Tue, 2020-08-04 at 11:42 +0800, Wayne Lin wrote:
> [Why]
> According to DP spec, DPRX with DPCD r1.2 or higher shall have the 
> same Link/Sink Device Status field registers at DPCD Addresses 00200h 
> through 00205h to the corresponding DPRX Event Status Indicator 
> registers at DPCD Addresses 02002h through 0200Fh. We now only read 
> from 02002h when DPCD revision number is r1.4 or higher while handling 
> short HPD. Need to correct that.
> 
> [How]
> Set to read from 02002h when DPCD is r1.2 or higher
> 
> Signed-off-by: Wayne Lin <
> wayne@amd.com
> >
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 2bfa4e35c2cf..9fb1543b4c73 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -1834,9 +1834,9 @@ static enum dc_status read_hpd_rx_irq_data(
>* fail, so we now explicitly read 6 bytes which is
>* the req from the above mentioned test cases.
>*
> -  * For DP 1.4 we need to read those from 2002h range.
> +  * For DPCD r1.2 or higher, we need to read those from 2002h
> range.
>*/
> - if (link->dpcd_caps.dpcd_rev.raw < DPCD_REV_14)
> + if (link->dpcd_caps.dpcd_rev.raw < DPCD_REV_12)
>   retval = core_link_read_dpcd(
>   link,
>   DP_SINK_COUNT,

Reviewed-by: Aurabindo Pillai 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 5/7] drm/amd/display: Reset plane for anything that's not a FAST update

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Hersen Wu 

-Original Message-
From: Nicholas Kazlauskas  
Sent: Thursday, July 30, 2020 4:37 PM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Lakha, Bhawanpreet 
; Wu, Hersen 
Subject: [PATCH 5/7] drm/amd/display: Reset plane for anything that's not a 
FAST update

[Why]
MEDIUM or FULL updates can require global validation or affect bandwidth. By 
treating these all simply as surface updates we aren't actually passing this 
through DC global validation.

[How]
There's currently no way to pass surface updates through DC global validation, 
nor do I think it's a good idea to change the interface to accept these.

DC global validation itself is currently stateless, and we can move our update 
type checking to be stateless as well by duplicating DC surface checks in DM 
based on DRM properties.

We wanted to rely on DC automatically determining this since DC knows best, but 
DM is ultimately what fills in everything into DC plane state so it does need 
to know as well.

There are basically only three paths that we exercise in DM today:

1) Cursor (async update)
2) Pageflip (fast update)
3) Full pipe programming (medium/full updates)

Which means that anything that's more than a pageflip really needs to go down 
path #3.

So this change duplicates all the surface update checks based on DRM state 
instead inside of should_reset_plane().

Next step is dropping dm_determine_update_type_for_commit and we no longer 
require the old DC state at all for global validation.

Optimization can come later so we don't reset DC planes at all for MEDIUM 
udpates and avoid validation, but we might require some extra checks in DM to 
achieve this.

Cc: Bhawanpreet Lakha 
Cc: Hersen Wu 
Signed-off-by: Nicholas Kazlauskas 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 25 +++
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0d5f45742bb5..2cbb29199e61 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8336,6 +8336,31 @@ static bool should_reset_plane(struct drm_atomic_state 
*state,
if (old_other_state->crtc != new_other_state->crtc)
return true;
 
+   /* Src/dst size and scaling updates. */
+   if (old_other_state->src_w != new_other_state->src_w ||
+   old_other_state->src_h != new_other_state->src_h ||
+   old_other_state->crtc_w != new_other_state->crtc_w ||
+   old_other_state->crtc_h != new_other_state->crtc_h)
+   return true;
+
+   /* Rotation / mirroring updates. */
+   if (old_other_state->rotation != new_other_state->rotation)
+   return true;
+
+   /* Blending updates. */
+   if (old_other_state->pixel_blend_mode !=
+   new_other_state->pixel_blend_mode)
+   return true;
+
+   /* Alpha updates. */
+   if (old_other_state->alpha != new_other_state->alpha)
+   return true;
+
+   /* Colorspace changes. */
+   if (old_other_state->color_range != 
new_other_state->color_range ||
+   old_other_state->color_encoding != 
new_other_state->color_encoding)
+   return true;
+
/* Framebuffer checks fall at the end. */
if (!old_other_state->fb || !new_other_state->fb)
continue;
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 2/7] drm/amd/display: Reset plane when tiling flags change

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Hersen Wu 

-Original Message-
From: Nicholas Kazlauskas  
Sent: Thursday, July 30, 2020 4:37 PM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Lakha, Bhawanpreet 
; Siqueira, Rodrigo ; Wu, 
Hersen 
Subject: [PATCH 2/7] drm/amd/display: Reset plane when tiling flags change

[Why]
Enabling or disable DCC or switching between tiled and linear formats can 
require bandwidth updates.

They're currently skipping all DC validation by being treated as purely surface 
updates.

[How]
Treat tiling_flag changes (which encode DCC state) as a condition for resetting 
the plane.

Cc: Bhawanpreet Lakha 
Cc: Rodrigo Siqueira 
Cc: Hersen Wu 
Signed-off-by: Nicholas Kazlauskas 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 7cc5ab90ce13..bf1881bd492c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8332,6 +8332,8 @@ static bool should_reset_plane(struct drm_atomic_state 
*state,
 * TODO: Come up with a more elegant solution for this.
 */
for_each_oldnew_plane_in_state(state, other, old_other_state, 
new_other_state, i) {
+   struct dm_plane_state *old_dm_plane_state, *new_dm_plane_state;
+
if (other->type == DRM_PLANE_TYPE_CURSOR)
continue;
 
@@ -8342,9 +8344,20 @@ static bool should_reset_plane(struct drm_atomic_state 
*state,
if (old_other_state->crtc != new_other_state->crtc)
return true;
 
-   /* TODO: Remove this once we can handle fast format changes. */
-   if (old_other_state->fb && new_other_state->fb &&
-   old_other_state->fb->format != new_other_state->fb->format)
+   /* Framebuffer checks fall at the end. */
+   if (!old_other_state->fb || !new_other_state->fb)
+   continue;
+
+   /* Pixel format changes can require bandwidth updates. */
+   if (old_other_state->fb->format != new_other_state->fb->format)
+   return true;
+
+   old_dm_plane_state = to_dm_plane_state(old_other_state);
+   new_dm_plane_state = to_dm_plane_state(new_other_state);
+
+   /* Tiling and DCC changes also require bandwidth updates. */
+   if (old_dm_plane_state->tiling_flags !=
+   new_dm_plane_state->tiling_flags)
return true;
}
 
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: Get num_chans from VBIOS table

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Hersen Wu 



From: Bhawanpreet Lakha 
Sent: June 12, 2020 7:50 PM
To: amd-gfx@lists.freedesktop.org ; Deucher, 
Alexander ; Kazlauskas, Nicholas 
; Wu, Hersen 
Cc: Lee, Alvin ; Lakha, Bhawanpreet 

Subject: [PATCH] drm/amd/display: Get num_chans from VBIOS table

From: Alvin Lee 

Get the values from VBIOS table

Signed-off-by: Alvin Lee 
Signed-off-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/bios/bios_parser2.c| 98 +++
 .../gpu/drm/amd/display/dc/dc_bios_types.h|  1 +
 .../drm/amd/display/dc/dcn30/dcn30_resource.c |  7 +-
 .../display/include/grph_object_ctrl_defs.h   |  5 +
 4 files changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 9311fec1643c..b8684131151d 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1378,6 +1378,63 @@ static struct atom_encoder_caps_record 
*get_encoder_cap_record(
 return NULL;
 }

+static enum bp_result get_vram_info_v23(
+   struct bios_parser *bp,
+   struct dc_vram_info *info)
+{
+   struct atom_vram_info_header_v2_3 *info_v23;
+   enum bp_result result = BP_RESULT_OK;
+
+   info_v23 = GET_IMAGE(struct atom_vram_info_header_v2_3,
+   DATA_TABLES(vram_info));
+
+   if (info_v23 == NULL)
+   return BP_RESULT_BADBIOSTABLE;
+
+   info->num_chans = info_v23->vram_module[0].channel_num;
+   info->dram_channel_width_bytes = (1 << 
info_v23->vram_module[0].channel_width) / 8;
+
+   return result;
+}
+
+static enum bp_result get_vram_info_v24(
+   struct bios_parser *bp,
+   struct dc_vram_info *info)
+{
+   struct atom_vram_info_header_v2_4 *info_v24;
+   enum bp_result result = BP_RESULT_OK;
+
+   info_v24 = GET_IMAGE(struct atom_vram_info_header_v2_4,
+   DATA_TABLES(vram_info));
+
+   if (info_v24 == NULL)
+   return BP_RESULT_BADBIOSTABLE;
+
+   info->num_chans = info_v24->vram_module[0].channel_num;
+   info->dram_channel_width_bytes = (1 << 
info_v24->vram_module[0].channel_width) / 8;
+
+   return result;
+}
+
+static enum bp_result get_vram_info_v25(
+   struct bios_parser *bp,
+   struct dc_vram_info *info)
+{
+   struct atom_vram_info_header_v2_5 *info_v25;
+   enum bp_result result = BP_RESULT_OK;
+
+   info_v25 = GET_IMAGE(struct atom_vram_info_header_v2_5,
+   DATA_TABLES(vram_info));
+
+   if (info_v25 == NULL)
+   return BP_RESULT_BADBIOSTABLE;
+
+   info->num_chans = info_v25->vram_module[0].channel_num;
+   info->dram_channel_width_bytes = (1 << 
info_v25->vram_module[0].channel_width) / 8;
+
+   return result;
+}
+
 /*
  * get_integrated_info_v11
  *
@@ -1669,6 +1726,46 @@ static enum bp_result construct_integrated_info(
 return result;
 }

+static enum bp_result bios_parser_get_vram_info(
+   struct dc_bios *dcb,
+   struct dc_vram_info *info)
+{
+   struct bios_parser *bp = BP_FROM_DCB(dcb);
+   enum bp_result result = BP_RESULT_BADBIOSTABLE;
+   struct atom_common_table_header *header;
+   struct atom_data_revision revision;
+
+   if (info && DATA_TABLES(vram_info)) {
+   header = GET_IMAGE(struct atom_common_table_header,
+   DATA_TABLES(vram_info));
+
+   get_atom_data_table_revision(header, );
+
+   switch (revision.major) {
+   case 2:
+   switch (revision.minor) {
+   case 3:
+   result = get_vram_info_v23(bp, info);
+   break;
+   case 4:
+   result = get_vram_info_v24(bp, info);
+   break;
+   case 5:
+   result = get_vram_info_v25(bp, info);
+   break;
+   default:
+   break;
+   }
+   break;
+
+   default:
+   return result;
+   }
+
+   }
+   return result;
+}
+
 static struct integrated_info *bios_parser_create_integrated_info(
 struct dc_bios *dcb)
 {
@@ -2112,6 +2209,7 @@ static bool bios_parser2_construct(

 bp->base.integrated_info = 
bios_parser_create_integrated_info(>base);
 bp->base.fw_info_valid = bios_parser_get_firmware_info(>base, 
>base.fw_info) == BP_RESULT_OK;
+   bios_parser_get_vram_info(>base, >base.vram_info);

 

RE: [PATCH] drm/amd/display: Revalidate bandwidth before commiting DC updates

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

As workaround, the patch looks good.
Reviewed-by: Hersen Wu 

-Original Message-
From: Nicholas Kazlauskas  
Sent: Tuesday, June 2, 2020 8:54 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Wu, Hersen 
; Wentland, Harry ; Li, Sun peng 
(Leo) 
Subject: [PATCH] drm/amd/display: Revalidate bandwidth before commiting DC 
updates

[Why]
Whenever we switch between tiled formats without also switching pixel formats 
or doing anything else that recreates the DC plane state we can run into 
underflow or hangs since we're not updating the DML parameters before 
committing to the hardware.

[How]
If the update type is FULL then call validate_bandwidth again to update the DML 
parmeters before committing the state.

This is basically just a workaround and protective measure against update types 
being added DC where we could run into this issue in the future.

We can only fully validate the state in advance before applying it to the 
hardware if we recreate all the plane and stream states since we can't modify 
what's currently in use.

The next step is to update DM to ensure that we're creating the plane and 
stream states for whatever could potentially be a full update in DC to 
pre-emptively recreate the state for DC global validation.

The workaround can stay until this has been fixed in DM.

Cc: Hersen Wu 
Cc: Harry Wentland 
Cc: Leo Li 
Signed-off-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 04c3d9f7e323..00a4f679759f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2523,6 +2523,12 @@ void dc_commit_updates_for_stream(struct dc *dc,
 
copy_stream_update_to_stream(dc, context, stream, stream_update);
 
+   if (!dc->res_pool->funcs->validate_bandwidth(dc, context, false)) {
+   DC_ERROR("Mode validation failed for stream update!\n");
+   dc_release_state(context);
+   return;
+   }
+
commit_planes_for_stream(
dc,
srf_updates,
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

Hi Evan, Kenneth,

Would you please help review this patch again?

Thanks!
Hersen


-Original Message-
From: Alex Deucher  
Sent: Monday, March 2, 2020 9:27 AM
To: Wu, Hersen 
Cc: Quan, Evan ; amd-gfx@lists.freedesktop.org; Feng, 
Kenneth 
Subject: Re: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock 
settings to smu resume from s3

On Fri, Feb 28, 2020 at 3:59 PM Wu, Hersen  wrote:
>
> Follow Evan's review, add smu->mutex.
>
>
> This interface is for dGPU Navi1x. Linux dc-pplib interface depends  
> on window driver dc implementation.
>
>  For Navi1x, clock settings of dcn watermarks are fixed. the settings  
> should be passed to smu during boot up and resume from s3.
>  boot up: dc calculate dcn watermark clock settings within dc_create,  
> dcn20_resource_construct, then call pplib functions below to pass  the 
> settings to smu:
>  smu_set_watermarks_for_clock_ranges
>  smu_set_watermarks_table
>  navi10_set_watermarks_table
>  smu_write_watermarks_table
>
>  For Renoir, clock settings of dcn watermark are also fixed values.
>  dc has implemented different flow for window driver:
>  dc_hardware_init / dc_set_power_state  dcn10_init_hw  
> notify_wm_ranges  set_wm_ranges
>
>  For Linux
>  smu_set_watermarks_for_clock_ranges
>  renoir_set_watermarks_table
>  smu_write_watermarks_table
>
>  dc_hardware_init -> amdgpu_dm_init
>  dc_set_power_state --> dm_resume
>
>  therefore, linux dc-pplib interface of navi10/12/14 is different  
> from that of Renoir.
>
> Signed-off-by: Hersen Wu 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 
> +++
>  1 file changed, 68 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 931cbd7b372e..1ee1d6ff2782 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1435,6 +1435,72 @@ static void s3_handle_mst(struct drm_device *dev, bool 
> suspend)
>   drm_kms_helper_hotplug_event(dev);
>  }
>
> +static int amdgpu_dm_smu_write_watermarks_table(struct amdgpu_device 
> +*adev) {  struct smu_context *smu = >smu;  int ret = 0;
> +
> + if (!is_support_sw_smu(adev))
> + return 0;
> +
> + /* This interface is for dGPU Navi1x.Linux dc-pplib interface 
> + depends
> + * on window driver dc implementation.
> + * For Navi1x, clock settings of dcn watermarks are fixed. the 
> + settings
> + * should be passed to smu during boot up and resume from s3.
> + * boot up: dc calculate dcn watermark clock settings within 
> + dc_create,
> + * dcn20_resource_construct
> + * then call pplib functions below to pass the settings to smu:
> + * smu_set_watermarks_for_clock_ranges
> + * smu_set_watermarks_table
> + * navi10_set_watermarks_table
> + * smu_write_watermarks_table
> + *
> + * For Renoir, clock settings of dcn watermark are also fixed values.
> + * dc has implemented different flow for window driver:
> + * dc_hardware_init / dc_set_power_state
> + * dcn10_init_hw
> + * notify_wm_ranges
> + * set_wm_ranges
> + * -- Linux
> + * smu_set_watermarks_for_clock_ranges
> + * renoir_set_watermarks_table
> + * smu_write_watermarks_table
> + *
> + * For Linux,
> + * dc_hardware_init -> amdgpu_dm_init
> + * dc_set_power_state --> dm_resume
> + *
> + * therefore, this function apply to navi10/12/14 but not Renoir
> + * *
> + */
> + switch(adev->asic_type) {
> + case CHIP_NAVI10:
> + case CHIP_NAVI14:
> + case CHIP_NAVI12:
> + break;
> + default:
> + return 0;
> + }
> +
> + mutex_lock(>mutex);
> +
> + /* pass data to smu controller */
> + if ((smu->watermarks_bitmap & WATERMARKS_EXIST) && 
> + !(smu->watermarks_bitmap & WATERMARKS_LOADED)) { ret = 
> + smu_write_watermarks_table(smu);
> +
> + if (ret) {
> + DRM_ERROR("Failed to update WMTABLE!\n"); return ret;

You need to unlock the mutex here in the failure case.

Alex

> + }
> + smu->watermarks_bitmap |= WATERMARKS_LOADED;
> + }
> +
> + mutex_unlock(>mutex);
> +
> + return 0;
> +}
> +
>  /**
>   * dm_hw_init() - Initialize DC device
>   * @handle: The base driver device containing the amdgpu_dm device.
> @@ -1713,6 +1779,8 @@ static int dm_resume(void *handle)
>
>   amdgpu_dm_irq_resume_late(adev);
>
> + amdgpu_dm_smu_write_watermarks_table(adev);
> +
>   return 0;
>  }
>
> --
> 2.17.1
>
> 
> From: Quan, Evan 
> Sent: February 27, 2020 9:58 PM
> To: Wu, Hersen ; amd-gfx@lists.freedesktop.org 
&g

Re: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

[Wu, Hersen]

Follow Evan's review, add smu->mutex.


This interface is for dGPU Navi1x. Linux dc-pplib interface depends
 on window driver dc implementation.

 For Navi1x, clock settings of dcn watermarks are fixed. the settings
 should be passed to smu during boot up and resume from s3.
 boot up: dc calculate dcn watermark clock settings within dc_create,
 dcn20_resource_construct, then call pplib functions below to pass
 the settings to smu:
 smu_set_watermarks_for_clock_ranges
 smu_set_watermarks_table
 navi10_set_watermarks_table
 smu_write_watermarks_table

 For Renoir, clock settings of dcn watermark are also fixed values.
 dc has implemented different flow for window driver:
 dc_hardware_init / dc_set_power_state
 dcn10_init_hw
 notify_wm_ranges
 set_wm_ranges

 For Linux
 smu_set_watermarks_for_clock_ranges
 renoir_set_watermarks_table
 smu_write_watermarks_table

 dc_hardware_init -> amdgpu_dm_init
 dc_set_power_state --> dm_resume

 therefore, linux dc-pplib interface of navi10/12/14 is different
 from that of Renoir.

Signed-off-by: Hersen Wu 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 +++
 1 file changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 931cbd7b372e..1ee1d6ff2782 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1435,6 +1435,72 @@ static void s3_handle_mst(struct drm_device *dev, bool 
suspend)
  drm_kms_helper_hotplug_event(dev);
 }

+static int amdgpu_dm_smu_write_watermarks_table(struct amdgpu_device *adev)
+{
+ struct smu_context *smu = >smu;
+ int ret = 0;
+
+ if (!is_support_sw_smu(adev))
+ return 0;
+
+ /* This interface is for dGPU Navi1x.Linux dc-pplib interface depends
+ * on window driver dc implementation.
+ * For Navi1x, clock settings of dcn watermarks are fixed. the settings
+ * should be passed to smu during boot up and resume from s3.
+ * boot up: dc calculate dcn watermark clock settings within dc_create,
+ * dcn20_resource_construct
+ * then call pplib functions below to pass the settings to smu:
+ * smu_set_watermarks_for_clock_ranges
+ * smu_set_watermarks_table
+ * navi10_set_watermarks_table
+ * smu_write_watermarks_table
+ *
+ * For Renoir, clock settings of dcn watermark are also fixed values.
+ * dc has implemented different flow for window driver:
+ * dc_hardware_init / dc_set_power_state
+ * dcn10_init_hw
+ * notify_wm_ranges
+ * set_wm_ranges
+ * -- Linux
+ * smu_set_watermarks_for_clock_ranges
+ * renoir_set_watermarks_table
+ * smu_write_watermarks_table
+ *
+ * For Linux,
+ * dc_hardware_init -> amdgpu_dm_init
+ * dc_set_power_state --> dm_resume
+ *
+ * therefore, this function apply to navi10/12/14 but not Renoir
+ * *
+ */
+ switch(adev->asic_type) {
+ case CHIP_NAVI10:
+ case CHIP_NAVI14:
+ case CHIP_NAVI12:
+ break;
+ default:
+ return 0;
+ }
+
+ mutex_lock(>mutex);
+
+ /* pass data to smu controller */
+ if ((smu->watermarks_bitmap & WATERMARKS_EXIST) &&
+ !(smu->watermarks_bitmap & WATERMARKS_LOADED)) {
+ ret = smu_write_watermarks_table(smu);
+
+ if (ret) {
+ DRM_ERROR("Failed to update WMTABLE!\n");
+ return ret;
+ }
+ smu->watermarks_bitmap |= WATERMARKS_LOADED;
+ }
+
+ mutex_unlock(>mutex);
+
+ return 0;
+}
+
 /**
  * dm_hw_init() - Initialize DC device
  * @handle: The base driver device containing the amdgpu_dm device.
@@ -1713,6 +1779,8 @@ static int dm_resume(void *handle)

  amdgpu_dm_irq_resume_late(adev);

+ amdgpu_dm_smu_write_watermarks_table(adev);
+
  return 0;
 }

--
2.17.1

________
From: Quan, Evan 
Sent: February 27, 2020 9:58 PM
To: Wu, Hersen ; amd-gfx@lists.freedesktop.org 

Cc: Feng, Kenneth ; Wu, Hersen 
Subject: RE: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock 
settings to smu resume from s3

Thanks. But could you help to confirm whether this is correctly protected by 
"mutex_lock(>mutex)"?

-Original Message-
From: Hersen Wu 
Sent: Thursday, February 27, 2020 11:54 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Feng, Kenneth ; Wu, 
Hersen 
Subject: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock 
settings to smu resume from s3

 This interface is for dGPU Navi1x. Linux dc-pplib interface depends  on window 
driver dc implementation.

 For Navi1x, clock settings of dcn watermarks are fixed. the settings  should 
be passed to smu during boot up and resume from s3.
 boot up: dc calculate dcn watermark clock settings within dc_create,  
dcn20_resource_construct, then call pplib functions below to pass  the settings 
to smu:
 smu_set_watermarks_for_clock_ranges
 smu_set_watermarks_table
 navi10_set_watermarks_table
 smu_write_watermarks_table

 For Renoir, clock settings of dcn watermark are also fixed values.
 dc has implemented different flow for window driver:
 dc_hardware_init / dc_

RE: [PATCH] drm/amd/powerplay: Add SMU WMTABLE Validity Check for Renoir

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]

The patch looks good.

Reviewed-by: Hersen Wu 

-Original Message-
From: Liu, Zhan  
Sent: Friday, December 13, 2019 11:50 AM
To: amd-gfx@lists.freedesktop.org; Wu, Hersen ; Deucher, 
Alexander ; Wang, Kevin(Yang) ; 
Quan, Evan ; Yin, Tianci (Rico) 
Cc: Liu, Zhan 
Subject: [PATCH] drm/amd/powerplay: Add SMU WMTABLE Validity Check for Renoir

[Why]
SMU watermark table (WMTABLE) validity check is missing on Renoir. This 
validity check is very useful for checking whether WMTABLE is updated 
successfully.

[How]
Add SMU watermark validity check.

Signed-off-by: Zhan Liu 
---
 drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c 
b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
index 89a54f8e08d3..81520b0fca68 100644
--- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
@@ -777,9 +777,17 @@ static int renoir_set_watermarks_table(
}
 
/* pass data to smu controller */
-   ret = smu_write_watermarks_table(smu);
+   if ((smu->watermarks_bitmap & WATERMARKS_EXIST) &&
+   !(smu->watermarks_bitmap & WATERMARKS_LOADED)) {
+   ret = smu_write_watermarks_table(smu);
+   if (ret) {
+   pr_err("Failed to update WMTABLE!");
+   return ret;
+   }
+   smu->watermarks_bitmap |= WATERMARKS_LOADED;
+   }
 
-   return ret;
+   return 0;
 }
 
 static int renoir_get_power_profile_mode(struct smu_context *smu,
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH v2] drm/amd/display: Loading NV10/14 Bounding Box Data Directly from Code

[Wu, Hersen]

[AMD Official Use Only - Internal Distribution Only]


Reviewed-by: hersen wu < hersenxs...@amd.com>

-Original Message-
From: Liu, Zhan  
Sent: Tuesday, December 3, 2019 12:49 PM
To: amd-gfx@lists.freedesktop.org; Wu, Hersen ; 
Kazlauskas, Nicholas 
Cc: Liu, Zhan 
Subject: [PATCH v2] drm/amd/display: Loading NV10/14 Bounding Box Data Directly 
from Code

[Why]
NV10/14 has released. Its time to get NV10/14 bounding box directly from code.

[How]
Retrieve NV10/14 bounding box data directly from code.
Retrieve NV12 bounding box data from firmware.

Signed-off-by: Zhan Liu 
---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index 2ccfd84a7da4..2a158ff5f0a5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -83,8 +83,6 @@
 
 #include "amdgpu_socbb.h"
 
-/* NV12 SOC BB is currently in FW, mark SW bounding box invalid. */ -#define 
SOC_BOUNDING_BOX_VALID false  #define DC_LOGGER_INIT(logger)
 
 struct _vcs_dpi_ip_params_st dcn2_0_ip = { @@ -3271,12 +3269,13 @@ static bool 
init_soc_bounding_box(struct dc *dc,
 
DC_LOGGER_INIT(dc->ctx->logger);
 
-   if (!bb && !SOC_BOUNDING_BOX_VALID) {
+   /* TODO: upstream NV12 bounding box when its launched */
+   if (!bb && ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev)) {
DC_LOG_ERROR("%s: not valid soc bounding box/n", __func__);
return false;
}
 
-   if (bb && !SOC_BOUNDING_BOX_VALID) {
+   if (bb && ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev)) {
int i;
 
dcn2_0_nv12_soc.sr_exit_time_us =
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14

[Wu, Hersen]

Reviewed-by: Hersen Wu 



-Original Message-
From: Liu, Zhan  
Sent: Friday, November 1, 2019 9:35 PM
To: Wu, Hersen ; amd-gfx@lists.freedesktop.org; 
Kazlauskas, Nicholas ; Lakha, Bhawanpreet 
; Li, Roman ; Siqueira, Rodrigo 
; Wentland, Harry ; Zuo, 
Jerry 
Cc: Yeh, Eagle ; Lazare, Jordan 
Subject: RE: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check for 
Navi14

Thank you Hersen. Please check the updated patch:

From: Liu, Zhan 
Sent: Friday, November 1, 2019 9:18 PM
To: amd-gfx@lists.freedesktop.org; Kazlauskas, Nicholas 
; Lakha, Bhawanpreet ; 
Li, Roman ; Liu, Zhan ; Siqueira, Rodrigo 
; Wentland, Harry ; Wu, 
Hersen ; Zuo, Jerry 
Cc: Yeh, Eagle ; Lazare, Jordan 
Subject: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14

From: Zhan liu 
Date: Fri, 1 Nov 2019 21:10:17 -0400
Subject: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14

[Why]
Navi10 has 6 PHY, but Navi14 only has 5 PHY, that is because there is no 
ENGINE_ID_DIGD in Navi14. Without this patch, many HDMI related issues (e.g. 
HDMI S3 resume failure, HDMI pink screen on boot) will be observed.

[How]
If eng_id is larger than ENGINE_ID_DIGD, then add eng_id by 1.

Signed-off-by: Zhan liu 
---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 3 +++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index 924c2e303588..cf886483e380 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -1152,6 +1152,11 @@ struct stream_encoder *dcn20_stream_encoder_create(
if (!enc1)
return NULL;

+   if (ASIC_REV_IS_NAVI14_M(ctx->asic_id.hw_internal_rev)) {
+   if (eng_id >= ENGINE_ID_DIGD)
+   eng_id++;
+   }
+
dcn20_stream_encoder_construct(enc1, ctx, ctx->dc_bios, eng_id,
_enc_regs[eng_id],
_shift, _mask);
--
2.21.0

> -Original Message-----
> From: Wu, Hersen 
> Sent: 2019/November/01, Friday 9:23 PM
> To: Liu, Zhan ; amd-gfx@lists.freedesktop.org; 
> Kazlauskas, Nicholas ; Lakha, Bhawanpreet 
> ; Li, Roman ; Siqueira, 
> Rodrigo ; Wentland, Harry 
> ; Zuo, Jerry 
> Cc: Yeh, Eagle ; Lazare, Jordan 
> 
> Subject: RE: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition 
> check for Navi14
> 
> Hi Zhan,
> 
> The function is shared by NV10,12,14.
> 
> Please add ASIC ID check  for the DIG D skip.
> 
> Thanks!
> Hersen
> 
> 
> -Original Message-
> From: Liu, Zhan 
> Sent: Friday, November 1, 2019 9:18 PM
> To: amd-gfx@lists.freedesktop.org; Kazlauskas, Nicholas 
> ; Lakha, Bhawanpreet 
> ; Li, Roman ; Liu, Zhan 
> ; Siqueira, Rodrigo ; 
> Wentland, Harry ; Wu, Hersen 
> ; Zuo, Jerry 
> Cc: Yeh, Eagle ; Lazare, Jordan 
> 
> Subject: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check 
> for Navi14
> 
> From: Zhan liu 
> Date: Fri, 1 Nov 2019 21:10:17 -0400
> Subject: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check 
> for Navi14
> 
> [Why]
> Navi10 has 6 PHY, but Navi14 only has 5 PHY, that is because there is 
> no ENGINE_ID_DIGD in Navi14. Without this patch, many HDMI related 
> issues (e.g. HDMI S3 resume failure, HDMI pink screen on boot) will be 
> observed.
> 
> [How]
> If eng_id is larger than ENGINE_ID_DIGD, then add eng_id by 1.
> 
> Signed-off-by: Zhan liu 
> ---
>  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> index 924c2e303588..cf886483e380 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> @@ -1152,6 +1152,9 @@ struct stream_encoder 
> *dcn20_stream_encoder_create(
> if (!enc1)
> return NULL;
> 
> +   if (eng_id >= ENGINE_ID_DIGD)
> +   eng_id++;
> +
> dcn20_stream_encoder_construct(enc1, ctx, ctx->dc_bios, eng_id,
> _enc_regs[eng_id],
> _shift, _mask);
> --
> 2.21.0
> 
> ___
> 
> amd-gfx mailing list
> 
> amd-gfx@lists.freedesktop.org
> 
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14

[Wu, Hersen]

Hi Zhan,

The function is shared by NV10,12,14.

Please add ASIC ID check  for the DIG D skip. 

Thanks!
Hersen


-Original Message-
From: Liu, Zhan  
Sent: Friday, November 1, 2019 9:18 PM
To: amd-gfx@lists.freedesktop.org; Kazlauskas, Nicholas 
; Lakha, Bhawanpreet ; 
Li, Roman ; Liu, Zhan ; Siqueira, Rodrigo 
; Wentland, Harry ; Wu, 
Hersen ; Zuo, Jerry 
Cc: Yeh, Eagle ; Lazare, Jordan 
Subject: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14

From: Zhan liu 
Date: Fri, 1 Nov 2019 21:10:17 -0400
Subject: [PATCH] drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14

[Why]
Navi10 has 6 PHY, but Navi14 only has 5 PHY, that is because there is no 
ENGINE_ID_DIGD in Navi14. Without this patch, many HDMI related issues (e.g. 
HDMI S3 resume failure, HDMI pink screen on boot) will be observed.

[How]
If eng_id is larger than ENGINE_ID_DIGD, then add eng_id by 1.

Signed-off-by: Zhan liu 
---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index 924c2e303588..cf886483e380 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -1152,6 +1152,9 @@ struct stream_encoder *dcn20_stream_encoder_create(
if (!enc1)
return NULL;

+   if (eng_id >= ENGINE_ID_DIGD)
+   eng_id++;
+
dcn20_stream_encoder_construct(enc1, ctx, ctx->dc_bios, eng_id,
_enc_regs[eng_id],
_shift, _mask);
--
2.21.0

___

amd-gfx mailing list

amd-gfx@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 1/2] SWDEV-183622 4k@60hz dp monitor always flicking

[Wu, Hersen]

Hi, Kenneth, Ray,

Would you please help review this change?

Thanks,
Hersen


-Original Message-
From: hersen wu  
Sent: Monday, April 15, 2019 10:18 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander 

Cc: Wu, Hersen 
Subject: [PATCH 1/2] SWDEV-183622 4k@60hz dp monitor always flicking

[WHY] clock unit mis-match between caller DC and SMU interface.
  dc pass lock in mhz. the same unit as smu. no covert is needed.

[HOW] remove covert_10k_to_mhz in smu interface
  this fixes corruption issue with 4k @60 display and stutter
  mode enable

Signed-off-by: hersen wu 
---
 .../gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c   | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index f32e3d0aaea6..078613348e78 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -204,18 +204,13 @@ static int smu10_set_clock_limit(struct pp_hwmgr *hwmgr, 
const void *input)
return 0;
 }
 
-static inline uint32_t convert_10k_to_mhz(uint32_t clock) -{
-   return (clock + 99) / 100;
-}
-
 static int smu10_set_min_deep_sleep_dcefclk(struct pp_hwmgr *hwmgr, uint32_t 
clock)  {
struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr *)(hwmgr->backend);
 
if (smu10_data->need_min_deep_sleep_dcefclk &&
-   smu10_data->deep_sleep_dcefclk != convert_10k_to_mhz(clock)) {
-   smu10_data->deep_sleep_dcefclk = convert_10k_to_mhz(clock);
+   smu10_data->deep_sleep_dcefclk != clock) {
+   smu10_data->deep_sleep_dcefclk = clock;
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetMinDeepSleepDcefclk,
smu10_data->deep_sleep_dcefclk);
@@ -228,8 +223,8 @@ static int smu10_set_hard_min_dcefclk_by_freq(struct 
pp_hwmgr *hwmgr, uint32_t c
struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr *)(hwmgr->backend);
 
if (smu10_data->dcf_actual_hard_min_freq &&
-   smu10_data->dcf_actual_hard_min_freq != 
convert_10k_to_mhz(clock)) {
-   smu10_data->dcf_actual_hard_min_freq = 
convert_10k_to_mhz(clock);
+   smu10_data->dcf_actual_hard_min_freq != clock) {
+   smu10_data->dcf_actual_hard_min_freq = clock;
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetHardMinDcefclkByFreq,
smu10_data->dcf_actual_hard_min_freq);
@@ -242,8 +237,8 @@ static int smu10_set_hard_min_fclk_by_freq(struct pp_hwmgr 
*hwmgr, uint32_t cloc
struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr *)(hwmgr->backend);
 
if (smu10_data->f_actual_hard_min_freq &&
-   smu10_data->f_actual_hard_min_freq != 
convert_10k_to_mhz(clock)) {
-   smu10_data->f_actual_hard_min_freq = convert_10k_to_mhz(clock);
+   smu10_data->f_actual_hard_min_freq != clock) {
+   smu10_data->f_actual_hard_min_freq = clock;
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetHardMinFclkByFreq,
smu10_data->f_actual_hard_min_freq);
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/display: Use context parameters to enable FBC

[Wu, Hersen]

+ Roman

-Original Message-
From: S, Shirish  
Sent: Monday, February 4, 2019 4:20 AM
To: Li, Sun peng (Leo) ; Wu, Hersen ; 
Wentland, Harry 
Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
Subject: [PATCH] drm/amd/display: Use context parameters to enable FBC

[What]
FBC fails to get enabled when switched between LINEAR(console/VT) and 
non-LINEAR(GUI) based rendering due to default value of tiling info stored in 
the current_state which is used for deciding whether or not to turn FBC on or 
off.

[How]
Use context structure's tiling information which is coherant with the screen 
updates.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index db0ef41..fd7cd5b 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -2535,7 +2535,7 @@ static void dce110_apply_ctx_for_surface(
}
 
if (dc->fbc_compressor)
-   enable_fbc(dc, dc->current_state);
+   enable_fbc(dc, context);
 }
 
 static void dce110_power_down_fe(struct dc *dc, struct pipe_ctx *pipe_ctx)
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/display: eDP fast bootup does not work for pre-raven asic

[Wu, Hersen]

Hi, Alex,

You are right!

Thanks,
Hersen


From: Deucher, Alexander 
Sent: Tuesday, January 15, 2019 12:18 PM
To: Wu, Hersen ; Alex Deucher 
Cc: Li, Sun peng (Leo) ; amd-gfx@lists.freedesktop.org; 
Wentland, Harry 
Subject: Re: [PATCH] drm/amd/display: eDP fast bootup does not work for 
pre-raven asic


So 95f05a3a2e6895ecfd8b4f64b5d6c6 is still valid even with your patch and we 
should keep it?  Thanks



Alex


From: Wu, Hersen
Sent: Tuesday, January 15, 2019 12:04:30 PM
To: Alex Deucher
Cc: Deucher, Alexander; Li, Sun peng (Leo); 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; Wentland, 
Harry
Subject: RE: [PATCH] drm/amd/display: eDP fast bootup does not work for 
pre-raven asic

My change will NOT revert 95f05a3a2e6895ecfd8b4f64b5d6c6.

Thanks
Hersen



-Original Message-
From: Alex Deucher mailto:alexdeuc...@gmail.com>>
Sent: Tuesday, January 15, 2019 12:01 PM
To: Wu, Hersen mailto:hersenxs...@amd.com>>
Cc: Deucher, Alexander 
mailto:alexander.deuc...@amd.com>>; Li, Sun peng 
(Leo) mailto:sunpeng...@amd.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; Wentland, 
Harry mailto:harry.wentl...@amd.com>>
Subject: Re: [PATCH] drm/amd/display: eDP fast bootup does not work for 
pre-raven asic

I'm not sure I understand.  If we were to apply your proposed patch, could we 
revert 95f05a3a2e6895ecfd8b4f64b5d6c6 ?

Thanks,

Alex

On Tue, Jan 15, 2019 at 11:57 AM Wu, Hersen 
mailto:hersenxs...@amd.com>> wrote:
>
> Hi, Alex,
>
>
>
> Hersen's change is for older version of eDP fast boot up ( 
> bios_get_vga_enabled_displays  is called).
>
> Chrome tree source still use bios_get_vga_enabled_displays for fast boot up.
>
>
>
>
>
> Harry's change is new implementation of eDP fast boot up.
>
>
>
> Hersen's change will not revert Harry's change.
>
>
>
> Thanks,
>
> Hersen
>
>
>
>
>
> From: Deucher, Alexander 
> mailto:alexander.deuc...@amd.com>>
> Sent: Tuesday, January 15, 2019 10:43 AM
> To: Li, Sun peng (Leo) mailto:sunpeng...@amd.com>>;
> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
> Cc: Wentland, Harry mailto:harry.wentl...@amd.com>>; 
> Wu, Hersen
> mailto:hersenxs...@amd.com>>
> Subject: Re: [PATCH] drm/amd/display: eDP fast bootup does not work
> for pre-raven asic
>
>
>
> Can this patch be reverted with this change?
>
>
>
> commit 95f05a3a2e6895ecfd8b4f64b5d6c6cf0b6a3f4a
> Author: Alex Deucher 
> mailto:alexander.deuc...@amd.com>>
> Date:   Thu Aug 16 15:35:21 2018 -0500
>
> drm/amdgpu/display: disable eDP fast boot optimization on DCE8
>
> Seems to cause blank screens.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106940
> Reviewed-by: Harry Wentland 
> mailto:harry.wentl...@amd.com>>
> Signed-off-by: Alex Deucher 
> mailto:alexander.deuc...@amd.com>>
>
> Other than that, it looks good to me.
>
> Reviewed-by: Alex Deucher 
> mailto:alexander.deuc...@amd.com>>
>
> ____
>
> From: amd-gfx 
> mailto:amd-gfx-boun...@lists.freedesktop.org>>
>  on behalf of
> sunpeng...@amd.com<mailto:sunpeng...@amd.com> 
> mailto:sunpeng...@amd.com>>
> Sent: Monday, January 14, 2019 5:36:15 PM
> To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
> Cc: Wentland, Harry; Wu, Hersen
> Subject: [PATCH] drm/amd/display: eDP fast bootup does not work for
> pre-raven asic
>
>
>
> From: hersen wu mailto:hersenxs...@amd.com>>
>
> [Why] bios will light up eDP before sw driver loaded. sw driver will
> check if eDP lighted up by bios by reading BIOS_SCRATCH_3. If yes, sw
> driver will not power down eDP power, phy to save time.
> definition of BIOS_SCRATCH_3 are missed for pre-raven asic. this cuase
> eDP fast boot up not work. for some eDP panel, even AMD dp tx send
> NoVideoStream_flag =1 and dpcd 0x600=2, eDP rx may not handle
> properly. this may cause short period flash on screen.
>
> [How] add definition of BIOS_SCRATCH_3 for all asic
>
> CC: Harry Wentland mailto:harry.wentl...@amd.com>>
> Signed-off-by: hersen wu mailto:hersenxs...@amd.com>>
> Reviewed-by: Charlene Liu mailto:charlene@amd.com>>
> Acked-by: Yongqiang Sun mailto:yongqiang@amd.com>>
> Acked-by: Leo Li mailto:sunpeng...@amd.com>>
> ---
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c | 3 +--
> drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c  | 2 ++
> drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c  | 2 ++
> drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c  | 2 ++
> dri

RE: [PATCH] drm/amd/display: eDP fast bootup does not work for pre-raven asic

[Wu, Hersen]

My change will NOT revert 95f05a3a2e6895ecfd8b4f64b5d6c6.

Thanks
Hersen



-Original Message-
From: Alex Deucher  
Sent: Tuesday, January 15, 2019 12:01 PM
To: Wu, Hersen 
Cc: Deucher, Alexander ; Li, Sun peng (Leo) 
; amd-gfx@lists.freedesktop.org; Wentland, Harry 

Subject: Re: [PATCH] drm/amd/display: eDP fast bootup does not work for 
pre-raven asic

I'm not sure I understand.  If we were to apply your proposed patch, could we 
revert 95f05a3a2e6895ecfd8b4f64b5d6c6 ?

Thanks,

Alex

On Tue, Jan 15, 2019 at 11:57 AM Wu, Hersen  wrote:
>
> Hi, Alex,
>
>
>
> Hersen’s change is for older version of eDP fast boot up ( 
> bios_get_vga_enabled_displays  is called).
>
> Chrome tree source still use bios_get_vga_enabled_displays for fast boot up.
>
>
>
>
>
> Harry’s change is new implementation of eDP fast boot up.
>
>
>
> Hersen’s change will not revert Harry’s change.
>
>
>
> Thanks,
>
> Hersen
>
>
>
>
>
> From: Deucher, Alexander 
> Sent: Tuesday, January 15, 2019 10:43 AM
> To: Li, Sun peng (Leo) ; 
> amd-gfx@lists.freedesktop.org
> Cc: Wentland, Harry ; Wu, Hersen 
> 
> Subject: Re: [PATCH] drm/amd/display: eDP fast bootup does not work 
> for pre-raven asic
>
>
>
> Can this patch be reverted with this change?
>
>
>
> commit 95f05a3a2e6895ecfd8b4f64b5d6c6cf0b6a3f4a
> Author: Alex Deucher 
> Date:   Thu Aug 16 15:35:21 2018 -0500
>
> drm/amdgpu/display: disable eDP fast boot optimization on DCE8
>
> Seems to cause blank screens.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106940
> Reviewed-by: Harry Wentland 
> Signed-off-by: Alex Deucher 
>
> Other than that, it looks good to me.
>
> Reviewed-by: Alex Deucher 
>
> ________
>
> From: amd-gfx  on behalf of 
> sunpeng...@amd.com 
> Sent: Monday, January 14, 2019 5:36:15 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Wentland, Harry; Wu, Hersen
> Subject: [PATCH] drm/amd/display: eDP fast bootup does not work for 
> pre-raven asic
>
>
>
> From: hersen wu 
>
> [Why] bios will light up eDP before sw driver loaded. sw driver will 
> check if eDP lighted up by bios by reading BIOS_SCRATCH_3. If yes, sw 
> driver will not power down eDP power, phy to save time.
> definition of BIOS_SCRATCH_3 are missed for pre-raven asic. this cuase 
> eDP fast boot up not work. for some eDP panel, even AMD dp tx send 
> NoVideoStream_flag =1 and dpcd 0x600=2, eDP rx may not handle 
> properly. this may cause short period flash on screen.
>
> [How] add definition of BIOS_SCRATCH_3 for all asic
>
> CC: Harry Wentland 
> Signed-off-by: hersen wu 
> Reviewed-by: Charlene Liu 
> Acked-by: Yongqiang Sun 
> Acked-by: Leo Li 
> ---
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c | 3 +--  
> drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c  | 2 ++  
> drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c  | 2 ++  
> drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c  | 2 ++  
> drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c  | 1 +
>  drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c| 2 ++
>  6 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
> index fdda8aa..d8275ceb 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
> @@ -83,8 +83,7 @@ uint32_t bios_get_vga_enabled_displays(  {
>  uint32_t active_disp = 1;
>
> -   if (bios->regs->BIOS_SCRATCH_3) /*follow up with other asic, todo*/
> -   active_disp = REG_READ(BIOS_SCRATCH_3) & 0X;
> +   active_disp = REG_READ(BIOS_SCRATCH_3) & 0X;
>  return active_disp;
>  }
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> index c3f616a..23044e6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> @@ -76,6 +76,7 @@
>
>  #ifndef mmBIOS_SCRATCH_2
>  #define mmBIOS_SCRATCH_2 0x05CB
> +   #define mmBIOS_SCRATCH_3 0x05CC
>  #define mmBIOS_SCRATCH_6 0x05CF  #endif
>
> @@ -365,6 +366,7 @@ static const struct dce_abm_mask abm_mask = {  
> #define DCFE_MEM_PWR_CTRL_REG_BASE 0x1b03
>
>  static const struct bios_registers bios_regs = {
> +   .BIOS_SCRATCH_3 = mmBIOS_SCRATCH_3,
>  .BIOS_SCRATCH_6 = mmBIOS_SCRATCH_6  };
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> b

RE: [PATCH] drm/amd/display: eDP fast bootup does not work for pre-raven asic

[Wu, Hersen]

Hi, Alex,

Hersen's change is for older version of eDP fast boot up ( 
bios_get_vga_enabled_displays  is called).
Chrome tree source still use bios_get_vga_enabled_displays for fast boot up.


Harry's change is new implementation of eDP fast boot up.

Hersen's change will not revert Harry's change.

Thanks,
Hersen


From: Deucher, Alexander 
Sent: Tuesday, January 15, 2019 10:43 AM
To: Li, Sun peng (Leo) ; amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; Wu, Hersen 
Subject: Re: [PATCH] drm/amd/display: eDP fast bootup does not work for 
pre-raven asic


Can this patch be reverted with this change?


commit 95f05a3a2e6895ecfd8b4f64b5d6c6cf0b6a3f4a
Author: Alex Deucher 
mailto:alexander.deuc...@amd.com>>
Date:   Thu Aug 16 15:35:21 2018 -0500

drm/amdgpu/display: disable eDP fast boot optimization on DCE8

Seems to cause blank screens.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106940
Reviewed-by: Harry Wentland 
mailto:harry.wentl...@amd.com>>
Signed-off-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>
Other than that, it looks good to me.

Reviewed-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of sunpeng...@amd.com<mailto:sunpeng...@amd.com> 
mailto:sunpeng...@amd.com>>
Sent: Monday, January 14, 2019 5:36:15 PM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Wentland, Harry; Wu, Hersen
Subject: [PATCH] drm/amd/display: eDP fast bootup does not work for pre-raven 
asic

From: hersen wu mailto:hersenxs...@amd.com>>

[Why] bios will light up eDP before sw driver loaded. sw driver will
check if eDP lighted up by bios by reading BIOS_SCRATCH_3. If yes,
sw driver will not power down eDP power, phy to save time.
definition of BIOS_SCRATCH_3 are missed for pre-raven asic. this
cuase eDP fast boot up not work. for some eDP panel, even AMD dp tx
send NoVideoStream_flag =1 and dpcd 0x600=2, eDP rx may not handle
properly. this may cause short period flash on screen.

[How] add definition of BIOS_SCRATCH_3 for all asic

CC: Harry Wentland mailto:harry.wentl...@amd.com>>
Signed-off-by: hersen wu mailto:hersenxs...@amd.com>>
Reviewed-by: Charlene Liu mailto:charlene@amd.com>>
Acked-by: Yongqiang Sun mailto:yongqiang@amd.com>>
Acked-by: Leo Li mailto:sunpeng...@amd.com>>
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c | 3 +--
 drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c  | 2 ++
 drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c  | 2 ++
 drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c  | 2 ++
 drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c  | 1 +
 drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c| 2 ++
 6 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
index fdda8aa..d8275ceb 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
@@ -83,8 +83,7 @@ uint32_t bios_get_vga_enabled_displays(
 {
 uint32_t active_disp = 1;

-   if (bios->regs->BIOS_SCRATCH_3) /*follow up with other asic, todo*/
-   active_disp = REG_READ(BIOS_SCRATCH_3) & 0X;
+   active_disp = REG_READ(BIOS_SCRATCH_3) & 0X;
 return active_disp;
 }

diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
index c3f616a..23044e6 100644
--- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
@@ -76,6 +76,7 @@

 #ifndef mmBIOS_SCRATCH_2
 #define mmBIOS_SCRATCH_2 0x05CB
+   #define mmBIOS_SCRATCH_3 0x05CC
 #define mmBIOS_SCRATCH_6 0x05CF
 #endif

@@ -365,6 +366,7 @@ static const struct dce_abm_mask abm_mask = {
 #define DCFE_MEM_PWR_CTRL_REG_BASE 0x1b03

 static const struct bios_registers bios_regs = {
+   .BIOS_SCRATCH_3 = mmBIOS_SCRATCH_3,
 .BIOS_SCRATCH_6 = mmBIOS_SCRATCH_6
 };

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index 7d46eb7..7549ada 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -84,6 +84,7 @@

 #ifndef mmBIOS_SCRATCH_2
 #define mmBIOS_SCRATCH_2 0x05CB
+   #define mmBIOS_SCRATCH_3 0x05CC
 #define mmBIOS_SCRATCH_6 0x05CF
 #endif

@@ -369,6 +370,7 @@ static const struct dce110_clk_src_mask cs_mask = {
 };

 static const struct bios_registers bios_regs = {
+   .BIOS_SCRATCH_3 = mmBIOS_SCRATCH_3,
 .BIOS_SCRATCH_6 = mmBIOS_SCRATCH_6
 };

diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_re

Re: [PATCH] drm/amd/powerplay: rv dal-pplib interface refactor powerplay part

[Wu, Hersen]

pp_hwmgr *hwmgr, uint32_t 
clock)
+{
+struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr *)(hwmgr->backend);
+
+if (smu10_data->f_actual_hard_min_freq &&
+smu10_data->f_actual_hard_min_freq != convert_10k_to_mhz(clock)) {
+smu10_data->f_actual_hard_min_freq = convert_10k_to_mhz(clock);
+smum_send_msg_to_smc_with_parameter(hwmgr,
+PPSMC_MSG_SetHardMinFclkByFreq,
+smu10_data->f_actual_hard_min_freq);
+}
+return 0;
+}
+
 static int smu10_set_active_display_count(struct pp_hwmgr *hwmgr, uint32_t 
count)
 {
 struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr *)(hwmgr->backend);
@@ -1206,7 +1234,7 @@ static const struct pp_hwmgr_func smu10_hwmgr_funcs = {
 .get_max_high_clocks = smu10_get_max_high_clocks,
 .read_sensor = smu10_read_sensor,
 .set_active_display_count = smu10_set_active_display_count,
-.set_deep_sleep_dcefclk = smu10_set_deep_sleep_dcefclk,
+.set_min_deep_sleep_dcefclk = smu10_set_min_deep_sleep_dcefclk,
 .dynamic_state_management_enable = smu10_enable_dpm_tasks,
 .power_off_asic = smu10_power_off_asic,
 .asic_setup = smu10_setup_asic_task,
@@ -1217,6 +1245,8 @@ static const struct pp_hwmgr_func smu10_hwmgr_funcs = {
 .display_clock_voltage_request = smu10_display_clock_voltage_request,
 .powergate_gfx = smu10_gfx_off_control,
 .powergate_sdma = smu10_powergate_sdma,
+.set_hard_min_dcefclk_by_freq = smu10_set_hard_min_dcefclk_by_freq,
+.set_hard_min_fclk_by_freq = smu10_set_hard_min_fclk_by_freq,
 };

 int smu10_init_function_pointers(struct pp_hwmgr *hwmgr)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/hardwaremanager.h 
b/drivers/gpu/drm/amd/powerplay/inc/hardwaremanager.h
index 54fd012..f4dab97 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/hardwaremanager.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/hardwaremanager.h
@@ -463,5 +463,8 @@ extern int phm_display_clock_voltage_request(struct 
pp_hwmgr *hwmgr,

 extern int phm_get_max_high_clocks(struct pp_hwmgr *hwmgr, struct 
amd_pp_simple_clock_info *clocks);
 extern int phm_disable_smc_firmware_ctf(struct pp_hwmgr *hwmgr);
+
+extern int phm_set_active_display_count(struct pp_hwmgr *hwmgr, uint32_t 
count);
+
 #endif /* _HARDWARE_MANAGER_H_ */

diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
index fb0f96f..0d298a0 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
@@ -309,7 +309,7 @@ struct pp_hwmgr_func {
 int (*avfs_control)(struct pp_hwmgr *hwmgr, bool enable);
 int (*disable_smc_firmware_ctf)(struct pp_hwmgr *hwmgr);
 int (*set_active_display_count)(struct pp_hwmgr *hwmgr, uint32_t count);
-int (*set_deep_sleep_dcefclk)(struct pp_hwmgr *hwmgr, uint32_t clock);
+int (*set_min_deep_sleep_dcefclk)(struct pp_hwmgr *hwmgr, uint32_t clock);
 int (*start_thermal_controller)(struct pp_hwmgr *hwmgr, struct 
PP_TemperatureRange *range);
 int (*notify_cac_buffer_info)(struct pp_hwmgr *hwmgr,
 uint32_t virtual_addr_low,
@@ -332,6 +332,8 @@ struct pp_hwmgr_func {
 int (*smus_notify_pwe)(struct pp_hwmgr *hwmgr);
 int (*powergate_sdma)(struct pp_hwmgr *hwmgr, bool bgate);
     int (*enable_mgpu_fan_boost)(struct pp_hwmgr *hwmgr);
+int (*set_hard_min_dcefclk_by_freq)(struct pp_hwmgr *hwmgr, uint32_t 
clock);
+int (*set_hard_min_fclk_by_freq)(struct pp_hwmgr *hwmgr, uint32_t clock);
 };

 struct pp_table_func {



From: Zhu, Rex
Sent: December 6, 2018 12:08:02 AM
To: Wu, Hersen; amd-gfx@lists.freedesktop.org; Deucher, Alexander
Subject: Re: [PATCH] drm/amd/powerplay: rv dal-pplib interface refactor 
powerplay part


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:03 AM
To: amd-gfx@lists.freedesktop.org; Zhu, Rex; Deucher, Alexander
Subject: RE: [PATCH] drm/amd/powerplay: rv dal-pplib interface refactor 
powerplay part

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 pplib:

1.smu10_display_clock_voltage_request for dcefclk 
2.smu10_display_clock_voltage_request for fclk 
3.phm_store_dal_configuration_data {
  set_min_deep_sleep_dcfclk
  set_active_display_count
  store_cc6_data --- this data never be referenced

new sequence will be:

1. set_display_count  --- need add new pplib interface 2. 
set_min_deep_sleep_dcfclk -- new pplib interface 3. set_hard_min_dcfclk_by_freq 
4. set_hard_min_fclk_by_freq

after th

RE: [PATCH] drm/amd/powerplay: rv dal-pplib interface refactor powerplay part

[Wu, Hersen]

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 pplib:

1.smu10_display_clock_voltage_request for dcefclk 
2.smu10_display_clock_voltage_request for fclk 
3.phm_store_dal_configuration_data {
  set_min_deep_sleep_dcfclk
  set_active_display_count
  store_cc6_data --- this data never be referenced

new sequence will be:

1. set_display_count  --- need add new pplib interface 2. 
set_min_deep_sleep_dcfclk -- new pplib interface 3. set_hard_min_dcfclk_by_freq 
4. set_hard_min_fclk_by_freq

after this code refactor, smu10_display_clock_voltage_request,
phm_store_dal_configuration_data will not be needed for rv.

[HOW] step 1: add new functions at pplib interface
  step 2: add new functions at amdgpu dm and dc

Signed-off-by: hersen wu 
---
 drivers/gpu/drm/amd/include/kgd_pp_interface.h |  4 ++
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 76 ++
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  | 45 -  
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c  | 36 +-
 .../gpu/drm/amd/powerplay/inc/hardwaremanager.h|  3 +
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  4 +-
 6 files changed, 162 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h 
b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
index 980e696..1479ea1 100644
--- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
@@ -276,6 +276,10 @@ struct amd_pm_funcs {
struct amd_pp_simple_clock_info *clocks);
int (*notify_smu_enable_pwe)(void *handle);
int (*enable_mgpu_fan_boost)(void *handle);
+   int (*set_active_display_count)(void *handle, uint32_t count);
+   int (*set_hard_min_dcefclk_by_freq)(void *handle, uint32_t clock);
+   int (*set_hard_min_fclk_by_freq)(void *handle, uint32_t clock);
+   int (*set_min_deep_sleep_dcefclk)(void *handle, uint32_t clock);
 };
 
 #endif
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index d6aa1d4..53dde16 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -1332,6 +1332,78 @@ static int pp_enable_mgpu_fan_boost(void *handle)
return 0;
 }
 
+static int pp_set_min_deep_sleep_dcefclk(void *handle, uint32_t clock) 
+{
+   struct pp_hwmgr *hwmgr = handle;
+
+   if (!hwmgr || !hwmgr->pm_en)
+   return -EINVAL;
+
+   if (hwmgr->hwmgr_func->set_min_deep_sleep_dcefclk == NULL) {
+   pr_info("%s was not implemented.\n", __func__);
+   return -EINVAL;;
+   }
+
+   mutex_lock(>smu_lock);
+   hwmgr->hwmgr_func->set_min_deep_sleep_dcefclk(hwmgr, clock);
+   mutex_unlock(>smu_lock);
+
+   return 0;
+}
+
+static int pp_set_hard_min_dcefclk_by_freq(void *handle, uint32_t 
+clock) {
+   struct pp_hwmgr *hwmgr = handle;
+
+   if (!hwmgr || !hwmgr->pm_en)
+   return -EINVAL;
+
+   if (hwmgr->hwmgr_func->set_hard_min_dcefclk_by_freq == NULL) {
+   pr_info("%s was not implemented.\n", __func__);
+   return -EINVAL;;
+   }
+
+   mutex_lock(>smu_lock);
+   hwmgr->hwmgr_func->set_hard_min_dcefclk_by_freq(hwmgr, clock);
+   mutex_unlock(>smu_lock);
+
+   return 0;
+}
+
+static int pp_set_hard_min_fclk_by_freq(void *handle, uint32_t clock) {
+   struct pp_hwmgr *hwmgr = handle;
+
+   if (!hwmgr || !hwmgr->pm_en)
+   return -EINVAL;
+
+   if (hwmgr->hwmgr_func->set_hard_min_fclk_by_freq == NULL) {
+   pr_info("%s was not implemented.\n", __func__);
+   return -EINVAL;;
+   }
+
+   mutex_lock(>smu_lock);
+   hwmgr->hwmgr_func->set_hard_min_fclk_by_freq(hwmgr, clock);
+   mutex_unlock(>smu_lock);
+
+   return 0;
+}
+
+static int pp_set_active_display_count(void *handle, uint32_t count) {
+   struct pp_hwmgr *hwmgr = handle;
+   int ret = 0;
+
+   if (!hwmgr || !hwmgr->pm_en)
+   return -EINVAL;
+
+   mutex_lock(>smu_lock);
+   ret = phm_set_active_display_count(hwmgr, count);
+   mutex_unlock(>smu_lock);
+
+   return ret;
+}
+
 static const struct amd_pm_funcs pp_dpm_funcs = {
.load_firmware = pp_dpm_load_fw,
.wait_for_fw_loading_complete = pp_dpm_fw_loading_complete, @@ -1378,4 
+1450,8 @@ static const struct amd_pm_funcs pp_dpm_funcs = {
.get_display_mode_validation_clocks = 
pp_get_display_mode_validation_clocks,
.notify_smu_enable_pwe = pp_notify_smu_enable_pwe,
.enable_mgpu_fan_boost = pp_enable_mgpu_fan_boost,
+   .set_active_display_count = pp_set_active_display_count,
+