Re: [PATCH] drm/amd/display: Avoid sending abnormal VSIF

[Kazlauskas, Nicholas]

On 2019-10-17 5:11 a.m., Wayne Lin wrote:
> [Why]
> While setting hdmi_vic, hv_frame.vic is not initialized and might
> assign a wrong value to hdmi_vic. Cause to send out VSIF with
> abnormal value.
> 
> [How]
> Initialize hv_frame and avi_frame
> 
> Signed-off-by: Wayne Lin 

Reviewed-by: Nicholas Kazlauskas 

Thanks!

> ---
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
>   1 file changed, 3 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 10cce584719f..33a455c90e27 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3472,6 +3472,9 @@ static void 
> fill_stream_properties_from_drm_display_mode(
>   struct hdmi_vendor_infoframe hv_frame;
>   struct hdmi_avi_infoframe avi_frame;
>   
> + memset(&hv_frame, 0, sizeof(hv_frame));
> + memset(&avi_frame, 0, sizeof(avi_frame));
> +
>   timing_out->h_border_left = 0;
>   timing_out->h_border_right = 0;
>   timing_out->v_border_top = 0;
> 

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

Re: [PATCH] drm/amd/display: Modify display link stream setup sequence.

[Kazlauskas, Nicholas]

On 2019-10-17 12:28 a.m., Liu, Zhan wrote:
> From: Zhan Liu 
> 
> [Why]
> When a specific kind of connector is detected,
> DC needs to set the attribute of the stream.
> This step needs to be done before enabling link,
> or some bugs (e.g. display won't light up)
> will be observed.
> 
> [How]
> Setting the attribute of the stream first, then
> enabling stream.
> 
> Signed-off-by: Zhan Liu 

NAK:

1. It's difficult to understand what issue this change is attempting to 
solve and why it actually does it. Specifics would help here.

2. It affects a common code path for all ASICs which has been tested and 
known to be working correctly for those test cases.

3. The description is incorrect - the link enable/stream enable were 
both previously happening after the stream setup. What's changed in the 
patch is the link enable now happens before the link setup.

Both of these calls internally go through the command table to VBIOS so 
what behavior differences you're seeing may be caused by the input 
parameters to the ATOM_ENCODER_CMD_STREAM_SETUP or 
TRANSMITTER_CONTROL_ENABLE commands or the actual execution of those 
commands.

Nicholas Kazlauskas

> ---
>   drivers/gpu/drm/amd/display/dc/core/dc_link.c | 20 +--
>   1 file changed, 10 insertions(+), 10 deletions(-)
> 
> 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 fb18681b502b..713caab82837 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -2745,16 +2745,6 @@ void core_link_enable_stream(
>  dc_is_virtual_signal(pipe_ctx->stream->signal))
>  return;
> 
> -   if (!dc_is_virtual_signal(pipe_ctx->stream->signal)) {
> -   stream->link->link_enc->funcs->setup(
> -   stream->link->link_enc,
> -   pipe_ctx->stream->signal);
> -   pipe_ctx->stream_res.stream_enc->funcs->setup_stereo_sync(
> -   pipe_ctx->stream_res.stream_enc,
> -   pipe_ctx->stream_res.tg->inst,
> -   stream->timing.timing_3d_format != 
> TIMING_3D_FORMAT_NONE);
> -   }
> -
>  if (dc_is_dp_signal(pipe_ctx->stream->signal))
>  
> pipe_ctx->stream_res.stream_enc->funcs->dp_set_stream_attribute(
>  pipe_ctx->stream_res.stream_enc,
> @@ -2841,6 +2831,16 @@ void core_link_enable_stream(
>  CONTROLLER_DP_TEST_PATTERN_VIDEOMODE,
>  COLOR_DEPTH_UNDEFINED);
> 
> +   if (!dc_is_virtual_signal(pipe_ctx->stream->signal)) {
> +   stream->link->link_enc->funcs->setup(
> +   stream->link->link_enc,
> +   pipe_ctx->stream->signal);
> +   
> pipe_ctx->stream_res.stream_enc->funcs->setup_stereo_sync(
> +   pipe_ctx->stream_res.stream_enc,
> +   pipe_ctx->stream_res.tg->inst,
> +   stream->timing.timing_3d_format != 
> TIMING_3D_FORMAT_NONE);
> +   }
> +
>   #ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
>  if (pipe_ctx->stream->timing.flags.DSC) {
>  if (dc_is_dp_signal(pipe_ctx->stream->signal) ||
> --
> 2.17.1
> ___
> 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 v2] drm/amd/display: Modify display link stream setup sequence.

[Kazlauskas, Nicholas]

This is actually setting DIG mode a second time, right? I don't think this is 
what sets GC_SEND.

Please mention that this is setting the DIG_MODE to the correct value after 
having been overridden by the call to transmitter control in your patch 
description. Also correct the HACK comment to mention that this second call is 
needed to reconfigure the DIG as a workaround for the incorrect value being 
applied from transmitter control. Specifics help in source.

I don't think there is a case where we'd want HDMI changed to DVI so it's 
probably fine to leave this as is for now...

With those fixed, you can add my:

Reviewed-by: Nicholas Kazlauskas 

Thanks,

Nicholas Kazlauskas


From: amd-gfx  on behalf of Liu, Zhan 

Sent: Thursday, October 17, 2019, 3:04 PM
To: amd-gfx@lists.freedesktop.org; Liu, Zhan
Subject: [PATCH v2] drm/amd/display: Modify display link stream setup sequence.

[Why]
This patch is for fixing Navi14 pink screen issue. With this
patch, stream->link->link_enc->funcs->setup will be called
twice: this will make sure GC_SEND is set to 1. Though we
still need to look into why the issue only happens on
Linux, but not on Windows side.

[How]
Call stream->link->link_enc->funcs->setup twice.

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

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 935053664160..8683e8613ec2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2842,6 +2842,12 @@ void core_link_enable_stream(
CONTROLLER_DP_TEST_PATTERN_VIDEOMODE,
COLOR_DEPTH_UNDEFINED);

+   /* Hack on Navi14: fixes Navi14 HDMI pink screen issue */
+   if (!dc_is_virtual_signal(pipe_ctx->stream->signal))
+   stream->link->link_enc->funcs->setup(
+   stream->link->link_enc,
+   pipe_ctx->stream->signal);
+
 #ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
if (pipe_ctx->stream->timing.flags.DSC) {
if (dc_is_dp_signal(pipe_ctx->stream->signal) ||
--
2.17.0
___
amd-gfx mailing list
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx@lists.freedesktop.org
___
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] UPSTREAM: drm/amd/display: Fix Apple dongle cannot be successfully detected

[Kazlauskas, Nicholas]

On 2019-10-21 3:54 a.m., Louis Li wrote:
> [Why]
> External monitor cannot be displayed consistently, if connecting
> via this Apple dongle (A1621, USB Type-C to HDMI).
> By experiments, it is confirmed that the dongle needs 200ms at least
> to be ready for communication, after it sets HPD signal high.
> 
> [How]
> When receiving HPD IRQ, delay 500ms at the beginning of handle_hpd_irq().
> Then run the original procedure.
> With this patch applied, the problem cannot be reproduced.
> With other dongles, test results are PASS.
> Test result is PASS after system resumes from suspend.
> 
> Signed-off-by: Louis Li 
> ---
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
>   1 file changed, 5 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 0aef92b7c037..043ddac73862 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1025,6 +1025,11 @@ static void handle_hpd_irq(void *param)
>   struct drm_device *dev = connector->dev;
>   enum dc_connection_type new_connection_type = dc_connection_none;
>   
> +/* Some monitors/dongles need around 200ms to be ready for communication
> + * after they drive HPD signal high.
> + */
> +mdelay(500);
> +
This sounds more like a quirk than behavior we want for all monitors, 
but regardless this sleep isn't the correct place for this - since this 
is an high priority interrupt handler this is really just blocking 
everything for half a second.

I think it'd make more sense to queue off the work to occur half a 
second later.

Nicholas Kazlauskas

>   /* In case of failure or MST no need to update connector status or 
> notify the OS
>* since (for MST case) MST does this in it's own context.
>*/
> 

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

Re: [PATCH] drm/amd/display: Change Navi14's DWB flag to 1

[Kazlauskas, Nicholas]

On 2019-10-21 3:36 p.m., Liu, Zhan wrote:
> [PATCH] drm/amd/display: Change Navi14's DWB flag to 1
> 
> [Why]
> DWB (Display Writeback) flag needs to be enabled as 1, or system
> will throw out a few warnings when creating dcn20 resource pool.
> Also, Navi14's dwb setting needs to match Navi10's,
> which has already been set to 1.
> 
> [How]
> Change value of num_dwb from 0 to 1.
> 
> Signed-off-by: Zhan Liu 

Reviewed-by: Nicholas Kazlauskas 

> ---
>   drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 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 914e378bcda4..d4937c475e7c 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> @@ -816,7 +816,7 @@ static const struct resource_caps res_cap_nv14 = {
>  .num_audio = 6,
>  .num_stream_encoder = 5,
>  .num_pll = 5,
> -   .num_dwb = 0,
> +   .num_dwb = 1,
>  .num_ddc = 5,
>   };
> 
> --
> 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/amdgpu/display: add dc feature mask for psr enablement

[Kazlauskas, Nicholas]

On 2019-10-21 5:45 p.m., roman...@amd.com wrote:
> From: Roman Li 
> 
> [Why]
> Adding psr mask to dc features allows selectively disable/enable psr.
> Current psr implementation may not work with non-pageflipping application.
> Until resolved it should be disabled by default.
> 
> [How]
> Add dcfeaturemask for psr enablement. Disable by default.
> To enable set amdgpu.dcfeaturemask=0x8 in grub kernel command line.
> 
> Signed-off-by: Roman Li 
> ---
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
>   drivers/gpu/drm/amd/include/amd_shared.h  | 1 +
>   2 files changed, 3 insertions(+), 1 deletion(-)
> 
> 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 1cf4beb..0f08879 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2424,7 +2424,8 @@ static int amdgpu_dm_initialize_drm_device(struct 
> amdgpu_device *adev)
>   } else if (dc_link_detect(link, DETECT_REASON_BOOT)) {
>   amdgpu_dm_update_connector_after_detect(aconnector);
>   register_backlight_device(dm, link);
> - amdgpu_dm_set_psr_caps(link);
> + if (amdgpu_dc_feature_mask & DC_PSR_MASK)
> + amdgpu_dm_set_psr_caps(link);
>   }
>   
>   
> diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
> b/drivers/gpu/drm/amd/include/amd_shared.h
> index 8889aac..1daa221 100644
> --- a/drivers/gpu/drm/amd/include/amd_shared.h
> +++ b/drivers/gpu/drm/amd/include/amd_shared.h
> @@ -143,6 +143,7 @@ enum PP_FEATURE_MASK {
>   enum DC_FEATURE_MASK {
>   DC_FBC_MASK = 0x1,
>   DC_MULTI_MON_PP_MCLK_SWITCH_MASK = 0x2,
> + DC_PSR_MASK = 0x8,

Can this just be 0x4 instead? Any reason why we're skipping a flag here 
going from 0x2 to 0x8?

You can still have my:

Reviewed-by: Nicholas Kazlauskas 

but my preference would be on fixing this up to a 0x4 first in the 
commit message / DC_FEATURE_MASK.

Nicholas Kazlauskas

>   };
>   
>   enum amd_dpm_forced_level;
> 

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

Re: [PATCH] drm/amdgpu/display: add dc feature mask for psr enablement

[Kazlauskas, Nicholas]

On 2019-10-22 9:33 a.m., Li, Roman wrote:
>> Any reason why we're skipping a flag here going from 0x2 to 0x8?
> 
> 0x4 is reserved for fractional pwm  mask:
> https://patchwork.freedesktop.org/patch/336923/

Ah, missed that patch. No problem then, feel free to go ahead with this.

Nicholas Kazlauskas

> 
> Thank you Nicholas for the review.
> 
> -----Original Message-----
> From: Kazlauskas, Nicholas 
> Sent: Tuesday, October 22, 2019 8:39 AM
> To: Li, Roman ; amd-gfx@lists.freedesktop.org; Deucher, 
> Alexander 
> Cc: Wentland, Harry ; Lakha, Bhawanpreet 
> ; Li, Sun peng (Leo) 
> Subject: Re: [PATCH] drm/amdgpu/display: add dc feature mask for psr 
> enablement
> 
> On 2019-10-21 5:45 p.m., roman...@amd.com wrote:
>> From: Roman Li 
>>
>> [Why]
>> Adding psr mask to dc features allows selectively disable/enable psr.
>> Current psr implementation may not work with non-pageflipping application.
>> Until resolved it should be disabled by default.
>>
>> [How]
>> Add dcfeaturemask for psr enablement. Disable by default.
>> To enable set amdgpu.dcfeaturemask=0x8 in grub kernel command line.
>>
>> Signed-off-by: Roman Li 
>> ---
>>drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
>>drivers/gpu/drm/amd/include/amd_shared.h  | 1 +
>>2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> 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 1cf4beb..0f08879 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -2424,7 +2424,8 @@ static int amdgpu_dm_initialize_drm_device(struct 
>> amdgpu_device *adev)
>>  } else if (dc_link_detect(link, DETECT_REASON_BOOT)) {
>>  amdgpu_dm_update_connector_after_detect(aconnector);
>>  register_backlight_device(dm, link);
>> -amdgpu_dm_set_psr_caps(link);
>> +if (amdgpu_dc_feature_mask & DC_PSR_MASK)
>> +amdgpu_dm_set_psr_caps(link);
>>  }
>>
>>
>> diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
>> b/drivers/gpu/drm/amd/include/amd_shared.h
>> index 8889aac..1daa221 100644
>> --- a/drivers/gpu/drm/amd/include/amd_shared.h
>> +++ b/drivers/gpu/drm/amd/include/amd_shared.h
>> @@ -143,6 +143,7 @@ enum PP_FEATURE_MASK {
>>enum DC_FEATURE_MASK {
>>  DC_FBC_MASK = 0x1,
>>  DC_MULTI_MON_PP_MCLK_SWITCH_MASK = 0x2,
>> +DC_PSR_MASK = 0x8,
> 
> Can this just be 0x4 instead? Any reason why we're skipping a flag here going 
> from 0x2 to 0x8?
> 
> You can still have my:
> 
> Reviewed-by: Nicholas Kazlauskas 
> 
> but my preference would be on fixing this up to a 0x4 first in the commit 
> message / DC_FEATURE_MASK.
> 
> Nicholas Kazlauskas
> 
>>};
>>
>>enum amd_dpm_forced_level;
>>
> 

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

Re: [PATCH 18/37] drm/amd/display: Allow inverted gamma

[Kazlauskas, Nicholas]

On 2019-10-23 11:44 a.m., Li, Sun peng (Leo) wrote:
> 
> 
> On 2019-10-23 11:23 a.m., Michel Dänzer wrote:
>> On 2019-10-17 9:13 p.m., sunpeng...@amd.com wrote:
>>> From: Aidan Yang 
>>>
>>> [why]
>>> There's a use case for inverted gamma
>>> and it's been confirmed that negative slopes are ok.
>>>
>>> [how]
>>> Remove code for blocking non-monotonically increasing gamma
>>>
>>> Signed-off-by: Aidan Yang 
>>> Reviewed-by: Krunoslav Kovac 
>>> Acked-by: Leo Li 
>>> Acked-by: Reza Amini 
>>
>> Does this fix https://bugs.freedesktop.org/110677 ? If so, it should be
>> referenced in the commit log, and the report resolved once this lands in
>> drm-next or Linus' tree.
> 
> I don't think it would, not on reported platform at least. This change
> only modifies for DCN families, so RX580 wouldn't be affected.
> 
> Leo

Looks like the same check exists on DCE though, it could probably be 
dropped as well to fix this bug.

See:
dce110_translate_regamma_to_hw_format()

while (i != hw_points + 1) {
if (dc_fixpt_lt(rgb_plus_1->red, rgb->red))
rgb_plus_1->red = rgb->red;
if (dc_fixpt_lt(rgb_plus_1->green, rgb->green))
rgb_plus_1->green = rgb->green;
if (dc_fixpt_lt(rgb_plus_1->blue, rgb->blue))
rgb_plus_1->blue = rgb->blue;

rgb->delta_red = dc_fixpt_sub(rgb_plus_1->red, rgb->red);
rgb->delta_green = dc_fixpt_sub(rgb_plus_1->green, rgb->green);
rgb->delta_blue = dc_fixpt_sub(rgb_plus_1->blue, rgb->blue);

++rgb_plus_1;
++rgb;
++i;
}


Nicholas Kazlauskas

> 
>>
>>
> ___
> 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 v5] drm/amd/display: Add MST atomic routines

[Kazlauskas, Nicholas]

On 2019-10-24 5:06 p.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski 
> 
> - Adding encoder atomic check to find vcpi slots for a connector
> - Using DRM helper functions to calculate PBN
> - Adding connector atomic check to release vcpi slots if connector
> loses CRTC
> - Calculate  PBN and VCPI slots only once during atomic
> check and store them on crtc_state to eliminate
> redundant calculation
> - Call drm_dp_mst_atomic_check to verify validity of MST topology
> during state atomic check
> 
> v2: squashed previous 3 separate patches, removed DSC PBN calculation,
> and added PBN and VCPI slots properties to amdgpu connector
> 
> v3:
> - moved vcpi_slots and pbn properties to dm_crtc_state and dc_stream_state
> - updates stream's vcpi_slots and pbn on commit
> - separated patch from the DSC MST series
> 
> v4:
> - set vcpi_slots and pbn properties to dm_connector_state
> - copy porperties from connector state on to crtc state
> 
> v5:
> - keep the pbn and vcpi values only on connnector state
> - added a void pointer to the stream state instead on two ints,
> because dc_stream_state is OS agnostic. Pointer points to the
> current dm_connector_state.
> 
> Cc: Jun Lei 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Nicholas Kazlauskas 
> Cc: Lyude Paul 
> Signed-off-by: Mikita Lipski 

Few comments below, mostly about how you're storing the DRM state in the 
DC stream.


> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 46 ++-
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
>   .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 44 ++
>   .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 32 +
>   drivers/gpu/drm/amd/display/dc/dc_stream.h|  1 +
>   5 files changed, 84 insertions(+), 41 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 48f5b43e2698..1d8d7aaba197 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3747,6 +3747,7 @@ create_stream_for_sink(struct amdgpu_dm_connector 
> *aconnector,
>   }
>   
>   stream->dm_stream_context = aconnector;
> + stream->dm_stream_state = dm_state;
>   
>   stream->timing.flags.LTE_340MCSC_SCRAMBLE =
>   drm_connector->display_info.hdmi.scdc.scrambling.low_rates;
> @@ -4180,7 +4181,8 @@ void amdgpu_dm_connector_funcs_reset(struct 
> drm_connector *connector)
>   state->underscan_hborder = 0;
>   state->underscan_vborder = 0;
>   state->base.max_requested_bpc = 8;
> -
> + state->vcpi_slots = 0;
> + state->pbn = 0;
>   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
>   state->abm_level = amdgpu_dm_abm_level;
>   
> @@ -4209,7 +4211,8 @@ amdgpu_dm_connector_atomic_duplicate_state(struct 
> drm_connector *connector)
>   new_state->underscan_enable = state->underscan_enable;
>   new_state->underscan_hborder = state->underscan_hborder;
>   new_state->underscan_vborder = state->underscan_vborder;
> -
> + new_state->vcpi_slots = state->vcpi_slots;
> + new_state->pbn = state->pbn;
>   return &new_state->base;
>   }
>   
> @@ -4610,6 +4613,37 @@ static int dm_encoder_helper_atomic_check(struct 
> drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state 
> *conn_state)
>   {
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_connector *connector = conn_state->connector;
> + struct amdgpu_dm_connector *aconnector = 
> to_amdgpu_dm_connector(connector);
> + struct dm_connector_state *dm_new_connector_state = 
> to_dm_connector_state(conn_state);
> + const struct drm_display_mode *adjusted_mode = 
> &crtc_state->adjusted_mode;
> + struct drm_dp_mst_topology_mgr *mst_mgr;
> + struct drm_dp_mst_port *mst_port;
> + int clock, bpp = 0;
> +
> + if (!aconnector->port || !aconnector->dc_sink)
> + return 0;
> +
> + mst_port = aconnector->port;
> + mst_mgr = &aconnector->mst_port->mst_mgr;
> +
> + if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
> + return 0;
> +
> + if (!state->duplicated) {
> + bpp = (uint8_t)connector->display_info.bpc * 3;
> + clock = adjusted_mode->clock;
> + dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp);
> + }
> + dm_new_connector_state->vcpi_slots = 
> drm_dp_atomic_find_vcpi_slots(state,
> +mst_mgr,
> +mst_port,
> +
> dm_new_connector_state->pbn);
> + if (dm_new_connector_state->vcpi_slots < 0) {
> + DRM_DEBUG_A

Re: [PATCH -next] drm/amd/display: Add a conversion function for transmitter and phy_id enums

[Kazlauskas, Nicholas]

On 2019-10-30 2:04 a.m., Nathan Chancellor wrote:
> Clang warns:
> 
> ../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2520:42:
> error: implicit conversion from enumeration type 'enum transmitter' to
> different enumeration type 'enum physical_phy_id'
> [-Werror,-Wenum-conversion]
>  psr_context->smuPhyId = link->link_enc->transmitter;
>~ ^~~
> 1 error generated.
> 
> As the comment above this assignment states, this is intentional. To
> match previous warnings of this nature, add a conversion function that
> explicitly converts between the enums and warns when there is a
> mismatch.
> 
> See commit 828cfa29093f ("drm/amdgpu: Fix amdgpu ras to ta enums
> conversion") and commit d9ec5cfd5a2e ("drm/amd/display: Use switch table
> for dc_to_smu_clock_type") for previous examples of this.
> 
> Fixes: e0d08a40a63b ("drm/amd/display: Add debugfs entry for reading psr 
> state")
> Link: https://github.com/ClangBuiltLinux/linux/issues/758
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Nicholas Kazlauskas 

With the small nitpick that maybe the default case should be 
PHYLD_UNKNOWN, but well get the warning if that happens anyway.

Nicholas Kazlauskas

> ---
>   drivers/gpu/drm/amd/display/dc/core/dc_link.c | 38 ++-
>   1 file changed, 37 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 7b18087be585..38dfe460e13b 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -2447,6 +2447,41 @@ bool dc_link_get_psr_state(const struct dc_link *link, 
> uint32_t *psr_state)
>   return true;
>   }
>   
> +static inline enum physical_phy_id
> +transmitter_to_phy_id(enum transmitter transmitter_value)
> +{
> + switch (transmitter_value) {
> + case TRANSMITTER_UNIPHY_A:
> + return PHYLD_0;
> + case TRANSMITTER_UNIPHY_B:
> + return PHYLD_1;
> + case TRANSMITTER_UNIPHY_C:
> + return PHYLD_2;
> + case TRANSMITTER_UNIPHY_D:
> + return PHYLD_3;
> + case TRANSMITTER_UNIPHY_E:
> + return PHYLD_4;
> + case TRANSMITTER_UNIPHY_F:
> + return PHYLD_5;
> + case TRANSMITTER_NUTMEG_CRT:
> + return PHYLD_6;
> + case TRANSMITTER_TRAVIS_CRT:
> + return PHYLD_7;
> + case TRANSMITTER_TRAVIS_LCD:
> + return PHYLD_8;
> + case TRANSMITTER_UNIPHY_G:
> + return PHYLD_9;
> + case TRANSMITTER_COUNT:
> + return PHYLD_COUNT;
> + case TRANSMITTER_UNKNOWN:
> + return PHYLD_UNKNOWN;
> + default:
> + WARN_ONCE(1, "Unknown transmitter value %d\n",
> +   transmitter_value);
> + return PHYLD_0;
> + }
> +}
> +
>   bool dc_link_setup_psr(struct dc_link *link,
>   const struct dc_stream_state *stream, struct psr_config 
> *psr_config,
>   struct psr_context *psr_context)
> @@ -2517,7 +2552,8 @@ bool dc_link_setup_psr(struct dc_link *link,
>   /* Hardcoded for now.  Can be Pcie or Uniphy (or Unknown)*/
>   psr_context->phyType = PHY_TYPE_UNIPHY;
>   /*PhyId is associated with the transmitter id*/
> - psr_context->smuPhyId = link->link_enc->transmitter;
> + psr_context->smuPhyId =
> + transmitter_to_phy_id(link->link_enc->transmitter);
>   
>   psr_context->crtcTimingVerticalTotal = stream->timing.v_total;
>   psr_context->vsyncRateHz = div64_u64(div64_u64((stream->
> 

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

Re: [PATCH v7] drm/amd/display: Add MST atomic routines

[Kazlauskas, Nicholas]

On 2019-10-28 10:31 a.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski 
> 
> - Adding encoder atomic check to find vcpi slots for a connector
> - Using DRM helper functions to calculate PBN
> - Adding connector atomic check to release vcpi slots if connector
> loses CRTC
> - Calculate  PBN and VCPI slots only once during atomic
> check and store them on crtc_state to eliminate
> redundant calculation
> - Call drm_dp_mst_atomic_check to verify validity of MST topology
> during state atomic check
> 
> v2: squashed previous 3 separate patches, removed DSC PBN calculation,
> and added PBN and VCPI slots properties to amdgpu connector
> 
> v3:
> - moved vcpi_slots and pbn properties to dm_crtc_state and dc_stream_state
> - updates stream's vcpi_slots and pbn on commit
> - separated patch from the DSC MST series
> 
> v4:
> - set vcpi_slots and pbn properties to dm_connector_state
> - copy porperties from connector state on to crtc state
> 
> v5:
> - keep the pbn and vcpi values only on connnector state
> - added a void pointer to the stream state instead on two ints,
> because dc_stream_state is OS agnostic. Pointer points to the
> current dm_connector_state.
> 
> v6:
> - Remove new param from stream
> 
> v7:
> - Cleanup
> - Remove state pointer from stream
>   
> Cc: Jun Lei 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Nicholas Kazlauskas 
> Cc: Lyude Paul 
> Signed-off-by: Mikita Lipski 
> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 ++-
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
>   .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 51 +--
>   .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 32 
>   4 files changed, 86 insertions(+), 41 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 48f5b43e2698..28f6b93ab371 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4180,7 +4180,8 @@ void amdgpu_dm_connector_funcs_reset(struct 
> drm_connector *connector)
>   state->underscan_hborder = 0;
>   state->underscan_vborder = 0;
>   state->base.max_requested_bpc = 8;
> -
> + state->vcpi_slots = 0;
> + state->pbn = 0;
>   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
>   state->abm_level = amdgpu_dm_abm_level;
>   
> @@ -4209,7 +4210,8 @@ amdgpu_dm_connector_atomic_duplicate_state(struct 
> drm_connector *connector)
>   new_state->underscan_enable = state->underscan_enable;
>   new_state->underscan_hborder = state->underscan_hborder;
>   new_state->underscan_vborder = state->underscan_vborder;
> -
> + new_state->vcpi_slots = state->vcpi_slots;
> + new_state->pbn = state->pbn;
>   return &new_state->base;
>   }
>   
> @@ -4610,6 +4612,37 @@ static int dm_encoder_helper_atomic_check(struct 
> drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state 
> *conn_state)
>   {
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_connector *connector = conn_state->connector;
> + struct amdgpu_dm_connector *aconnector = 
> to_amdgpu_dm_connector(connector);
> + struct dm_connector_state *dm_new_connector_state = 
> to_dm_connector_state(conn_state);
> + const struct drm_display_mode *adjusted_mode = 
> &crtc_state->adjusted_mode;
> + struct drm_dp_mst_topology_mgr *mst_mgr;
> + struct drm_dp_mst_port *mst_port;
> + int clock, bpp = 0;
> +
> + if (!aconnector->port || !aconnector->dc_sink)
> + return 0;
> +
> + mst_port = aconnector->port;
> + mst_mgr = &aconnector->mst_port->mst_mgr;
> +
> + if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
> + return 0;
> +
> + if (!state->duplicated) {
> + bpp = (uint8_t)connector->display_info.bpc * 3;

Is this correct? Do we always want to calculate this based on the 
display capable bpc value instead of the one actually in use?

> + clock = adjusted_mode->clock;
> + dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp);
> + }
> + dm_new_connector_state->vcpi_slots = 
> drm_dp_atomic_find_vcpi_slots(state,
> +mst_mgr,
> +mst_port,
> +
> dm_new_connector_state->pbn);
> + if (dm_new_connector_state->vcpi_slots < 0) {
> + DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n", 
> dm_new_connector_state->vcpi_slots);
> + return dm_new_connector_state->vcpi_slots;
> + }
>   return 0;
>   }
>   
> @@ -7651,6 +7684,11 @@ static int amdgpu_dm_atomic_check(struct 

Re: [PATCH v7] drm/amd/display: Add MST atomic routines

[Kazlauskas, Nicholas]

On 2019-10-30 2:42 p.m., Lipski, Mikita wrote:
> 
> On 30.10.2019 14:19, Kazlauskas, Nicholas wrote:
>> On 2019-10-28 10:31 a.m., mikita.lip...@amd.com wrote:
>>> From: Mikita Lipski 
>>>
>>> - Adding encoder atomic check to find vcpi slots for a connector
>>> - Using DRM helper functions to calculate PBN
>>> - Adding connector atomic check to release vcpi slots if connector
>>> loses CRTC
>>> - Calculate  PBN and VCPI slots only once during atomic
>>> check and store them on crtc_state to eliminate
>>> redundant calculation
>>> - Call drm_dp_mst_atomic_check to verify validity of MST topology
>>> during state atomic check
>>>
>>> v2: squashed previous 3 separate patches, removed DSC PBN calculation,
>>> and added PBN and VCPI slots properties to amdgpu connector
>>>
>>> v3:
>>> - moved vcpi_slots and pbn properties to dm_crtc_state and dc_stream_state
>>> - updates stream's vcpi_slots and pbn on commit
>>> - separated patch from the DSC MST series
>>>
>>> v4:
>>> - set vcpi_slots and pbn properties to dm_connector_state
>>> - copy porperties from connector state on to crtc state
>>>
>>> v5:
>>> - keep the pbn and vcpi values only on connnector state
>>> - added a void pointer to the stream state instead on two ints,
>>> because dc_stream_state is OS agnostic. Pointer points to the
>>> current dm_connector_state.
>>>
>>> v6:
>>> - Remove new param from stream
>>>
>>> v7:
>>> - Cleanup
>>> - Remove state pointer from stream
>>> 
>>> Cc: Jun Lei 
>>> Cc: Jerry Zuo 
>>> Cc: Harry Wentland 
>>> Cc: Nicholas Kazlauskas 
>>> Cc: Lyude Paul 
>>> Signed-off-by: Mikita Lipski 
>>> ---
>>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 ++-
>>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
>>> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 51 +--
>>> .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 32 
>>> 4 files changed, 86 insertions(+), 41 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 48f5b43e2698..28f6b93ab371 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -4180,7 +4180,8 @@ void amdgpu_dm_connector_funcs_reset(struct 
>>> drm_connector *connector)
>>> state->underscan_hborder = 0;
>>> state->underscan_vborder = 0;
>>> state->base.max_requested_bpc = 8;
>>> -
>>> +   state->vcpi_slots = 0;
>>> +   state->pbn = 0;
>>> if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
>>> state->abm_level = amdgpu_dm_abm_level;
>>> 
>>> @@ -4209,7 +4210,8 @@ amdgpu_dm_connector_atomic_duplicate_state(struct 
>>> drm_connector *connector)
>>> new_state->underscan_enable = state->underscan_enable;
>>> new_state->underscan_hborder = state->underscan_hborder;
>>> new_state->underscan_vborder = state->underscan_vborder;
>>> -
>>> +   new_state->vcpi_slots = state->vcpi_slots;
>>> +   new_state->pbn = state->pbn;
>>> return &new_state->base;
>>> }
>>> 
>>> @@ -4610,6 +4612,37 @@ static int dm_encoder_helper_atomic_check(struct 
>>> drm_encoder *encoder,
>>>   struct drm_crtc_state 
>>> *crtc_state,
>>>   struct drm_connector_state 
>>> *conn_state)
>>> {
>>> +   struct drm_atomic_state *state = crtc_state->state;
>>> +   struct drm_connector *connector = conn_state->connector;
>>> +   struct amdgpu_dm_connector *aconnector = 
>>> to_amdgpu_dm_connector(connector);
>>> +   struct dm_connector_state *dm_new_connector_state = 
>>> to_dm_connector_state(conn_state);
>>> +   const struct drm_display_mode *adjusted_mode = 
>>> &crtc_state->adjusted_mode;
>>> +   struct drm_dp_mst_topology_mgr *mst_mgr;
>>> +   struct drm_dp_mst_port *mst_port;
>>> +   int clock, bpp = 0

Re: [PATCH 01/13] drm/amd/display: Add MST atomic routines

[Kazlauskas, Nicholas]

On 2019-10-30 3:24 p.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski 
> 
> - Adding encoder atomic check to find vcpi slots for a connector
> - Using DRM helper functions to calculate PBN
> - Adding connector atomic check to release vcpi slots if connector
> loses CRTC
> - Calculate  PBN and VCPI slots only once during atomic
> check and store them on crtc_state to eliminate
> redundant calculation
> - Call drm_dp_mst_atomic_check to verify validity of MST topology
> during state atomic check
> 
> v2: squashed previous 3 separate patches, removed DSC PBN calculation,
> and added PBN and VCPI slots properties to amdgpu connector
> 
> v3:
> - moved vcpi_slots and pbn properties to dm_crtc_state and dc_stream_state
> - updates stream's vcpi_slots and pbn on commit
> - separated patch from the DSC MST series
> 
> v4:
> - set vcpi_slots and pbn properties to dm_connector_state
> - copy porperties from connector state on to crtc state
> 
> v5:
> - keep the pbn and vcpi values only on connnector state
> - added a void pointer to the stream state instead on two ints,
> because dc_stream_state is OS agnostic. Pointer points to the
> current dm_connector_state.
> 
> v6:
> - Remove new param from stream
> 
> v7:
> - Fix error with using max capable bpc
> 
> Cc: Jun Lei 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Nicholas Kazlauskas 
> Cc: Lyude Paul 
> Signed-off-by: Mikita Lipski 

Reviewed-by: Nicholas Kazlauskas 

You might want to verify that this still works as you expect when 
changing "max bpc" on an MST display.

My understanding is that it'd still force a new modeset before encoder 
atomic check is called so you *should* have the correct bpc value during 
MST calculations.

> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 65 ++-
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
>   .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 51 ---
>   .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 32 +
>   4 files changed, 109 insertions(+), 41 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 48f5b43e2698..d75726013436 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4180,7 +4180,8 @@ void amdgpu_dm_connector_funcs_reset(struct 
> drm_connector *connector)
>   state->underscan_hborder = 0;
>   state->underscan_vborder = 0;
>   state->base.max_requested_bpc = 8;
> -
> + state->vcpi_slots = 0;
> + state->pbn = 0;
>   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
>   state->abm_level = amdgpu_dm_abm_level;
>   
> @@ -4209,7 +4210,8 @@ amdgpu_dm_connector_atomic_duplicate_state(struct 
> drm_connector *connector)
>   new_state->underscan_enable = state->underscan_enable;
>   new_state->underscan_hborder = state->underscan_hborder;
>   new_state->underscan_vborder = state->underscan_vborder;
> -
> + new_state->vcpi_slots = state->vcpi_slots;
> + new_state->pbn = state->pbn;
>   return &new_state->base;
>   }
>   
> @@ -4606,10 +4608,64 @@ static void dm_encoder_helper_disable(struct 
> drm_encoder *encoder)
>   
>   }
>   
> +static int convert_dc_color_depth_into_bpc (enum dc_color_depth 
> display_color_depth)
> +{
> + switch (display_color_depth) {
> + case COLOR_DEPTH_666:
> + return 6;
> + case COLOR_DEPTH_888:
> + return 8;
> + case COLOR_DEPTH_101010:
> + return 10;
> + case COLOR_DEPTH_121212:
> + return 12;
> + case COLOR_DEPTH_141414:
> + return 14;
> + case COLOR_DEPTH_161616:
> + return 16;
> + default:
> + break;
> + }
> + return 0;
> +}
> +
>   static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state 
> *conn_state)
>   {
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_connector *connector = conn_state->connector;
> + struct amdgpu_dm_connector *aconnector = 
> to_amdgpu_dm_connector(connector);
> + struct dm_connector_state *dm_new_connector_state = 
> to_dm_connector_state(conn_state);
> + const struct drm_display_mode *adjusted_mode = 
> &crtc_state->adjusted_mode;
> + struct drm_dp_mst_topology_mgr *mst_mgr;
> + struct drm_dp_mst_port *mst_port;
> + enum dc_color_depth color_depth;
> + int clock, bpp = 0;
> +
> + if (!aconnector->port || !aconnector->dc_sink)
> + return 0;
> +
> + mst_port = aconnector->port;
> + mst_mgr = &aconnector->mst_port->mst_mgr;
> +
> + if (!c

Re: [PATCH] drm/amd/display: remove "setting DIG_MODE twice" workaround

[Kazlauskas, Nicholas]

On 2019-11-04 11:06 a.m., Liu, Zhan wrote:
> [Why]
> The root cause of Navi14 HDMI pink screen issue has been found.
> There is no need to set DIG_MODE twice anymore.
> 
> [How]
> Remove "setting DIG_MODE" twice workaround.
> 
> Signed-off-by: Zhan Liu 

Please use git to revert the commit instead:

eg.

git revert 

Then add the reasoning to the revert commit message.

Thanks,

Nicholas Kazlauskas

> ---
>   drivers/gpu/drm/amd/display/dc/core/dc_link.c | 9 -
>   1 file changed, 9 deletions(-)
> 
> 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 cc94c1a73daa..12ba6fdf89b7 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -3027,15 +3027,6 @@ void core_link_enable_stream(
>  CONTROLLER_DP_TEST_PATTERN_VIDEOMODE,
>  COLOR_DEPTH_UNDEFINED);
> 
> -   /* This second call is needed to reconfigure the DIG
> -* as a workaround for the incorrect value being applied
> -* from transmitter control.
> -*/
> -   if (!dc_is_virtual_signal(pipe_ctx->stream->signal))
> -   stream->link->link_enc->funcs->setup(
> -   stream->link->link_enc,
> -   pipe_ctx->stream->signal);
> -
>   #ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
>  if (pipe_ctx->stream->timing.flags.DSC) {
>  if (dc_is_dp_signal(pipe_ctx->stream->signal) ||
> --
> 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: remove "setting DIG_MODE twice" workaround

[Kazlauskas, Nicholas]

On 2019-11-04 2:49 p.m., Liu, Zhan wrote:
> Thank you Nick for the advice. I just reverted the original commit.
> 
> Zhan

The revert still needs code review.

Nicholas Kazlauskas

> 
>> -Original Message-
>> From: Kazlauskas, Nicholas 
>> Sent: 2019/November/04, Monday 11:53 AM
>> To: Liu, Zhan ; amd-gfx@lists.freedesktop.org; Wu,
>> Hersen 
>> Subject: Re: [PATCH] drm/amd/display: remove "setting DIG_MODE twice"
>> workaround
>>
>> On 2019-11-04 11:06 a.m., Liu, Zhan wrote:
>>> [Why]
>>> The root cause of Navi14 HDMI pink screen issue has been found.
>>> There is no need to set DIG_MODE twice anymore.
>>>
>>> [How]
>>> Remove "setting DIG_MODE" twice workaround.
>>>
>>> Signed-off-by: Zhan Liu 
>>
>> Please use git to revert the commit instead:
>>
>> eg.
>>
>> git revert 
>>
>> Then add the reasoning to the revert commit message.
>>
>> Thanks,
>>
>> Nicholas Kazlauskas
>>
>>> ---
>>>drivers/gpu/drm/amd/display/dc/core/dc_link.c | 9 -
>>>1 file changed, 9 deletions(-)
>>>
>>> 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 cc94c1a73daa..12ba6fdf89b7 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
>>> @@ -3027,15 +3027,6 @@ void core_link_enable_stream(
>>>   
>>> CONTROLLER_DP_TEST_PATTERN_VIDEOMODE,
>>>   COLOR_DEPTH_UNDEFINED);
>>>
>>> -   /* This second call is needed to reconfigure the DIG
>>> -* as a workaround for the incorrect value being applied
>>> -* from transmitter control.
>>> -*/
>>> -   if (!dc_is_virtual_signal(pipe_ctx->stream->signal))
>>> -   stream->link->link_enc->funcs->setup(
>>> -   stream->link->link_enc,
>>> -   pipe_ctx->stream->signal);
>>> -
>>>#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
>>>   if (pipe_ctx->stream->timing.flags.DSC) {
>>>   if (dc_is_dp_signal(pipe_ctx->stream->signal) ||
>>> --
>>> 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] drm/amd/display: Send vblank and user events at vsartup for DCN

[Kazlauskas, Nicholas]

On 2019-11-05 10:34 a.m., sunpeng...@amd.com wrote:
> From: Leo Li 
> 
> [Why]
> 
> For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
> interrupt. This is different from DCE, which has it assigned to vblank
> start.
> 
> We'd like to send vblank and user events at vstartup because:
> 
> * It happens close enough to vupdate - the point of no return for HW.
> 
> * It is programmed as lines relative to vblank end - i.e. it is not in
>the variable portion when VRR is enabled. We should signal user
>events here.
> 
> * The pflip interrupt responsible for sending user events today only
>fires if the DCH HUBP component is not clock gated. In situations
>where planes are disabled - but the CRTC is enabled - user events won't
>be sent out, leading to flip done timeouts.
> 
> Consequently, this makes vupdate on DCN hardware redundant. It will be
> removed in the next change.
> 
> [How]
> 
> Add a DCN-specific crtc_high_irq handler, and hook it to the VStartup
> signal. Inside the DCN handler, we send off user events if the pflip
> handler hasn't already done so.
> 
> Signed-off-by: Leo Li 
> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 65 ++-
>   1 file changed, 64 insertions(+), 1 deletion(-)
> 
> 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 00017b91c91a..256a23a0ec28 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -485,6 +485,69 @@ static void dm_crtc_high_irq(void *interrupt_params)
>   }
>   }
> 
> +
> +/**
> + * dm_dcn_crtc_high_irq() - Handles VStartup interrupt for DCN generation 
> ASICs
> + * @interrupt params - interrupt parameters
> + *
> + * Notify DRM's vblank event handler at VSTARTUP
> + *
> + * Unlike DCE hardware, we trigger the handler at VSTARTUP. at which:
> + * * We are close enough to VUPDATE - the point of no return for hw
> + * * We are in the fixed portion of variable front porch when vrr is enabled
> + * * We are before VUPDATE, where double-buffered vrr registers are swapped
> + *
> + * It is therefore the correct place to signal vblank, send user flip events,
> + * and update VRR.
> + */
> +static void dm_dcn_crtc_high_irq(void *interrupt_params)
> +{
> + struct common_irq_params *irq_params = interrupt_params;
> + struct amdgpu_device *adev = irq_params->adev;
> + struct amdgpu_crtc *acrtc;
> + struct dm_crtc_state *acrtc_state;
> + unsigned long flags;
> +
> + acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> IRQ_TYPE_VBLANK);
> +
> + if (!acrtc)
> + return;
> +
> + acrtc_state = to_dm_crtc_state(acrtc->base.state);
> +
> + DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> + amdgpu_dm_vrr_active(acrtc_state));
> +
> + amdgpu_dm_crtc_handle_crc_irq(&acrtc->base);
> + drm_crtc_handle_vblank(&acrtc->base);

Shouldn't this be the other way around? Don't we want the CRC sent back 
to userspace to have the updated vblank counter?

This is how it worked before at least.

Other than that, this patch looks fine to me.

Nicholas Kazlauskas

> +
> + spin_lock_irqsave(&adev->ddev->event_lock, flags);
> +
> + if (acrtc_state->vrr_params.supported &&
> + acrtc_state->freesync_config.state == VRR_STATE_ACTIVE_VARIABLE) {
> + mod_freesync_handle_v_update(
> + adev->dm.freesync_module,
> + acrtc_state->stream,
> + &acrtc_state->vrr_params);
> +
> + dc_stream_adjust_vmin_vmax(
> + adev->dm.dc,
> + acrtc_state->stream,
> + &acrtc_state->vrr_params.adjust);
> + }
> +
> + if (acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED) {
> + if (acrtc->event) {
> + drm_crtc_send_vblank_event(&acrtc->base, acrtc->event);
> + acrtc->event = NULL;
> + drm_crtc_vblank_put(&acrtc->base);
> + }
> + acrtc->pflip_status = AMDGPU_FLIP_NONE;
> + }
> +
> + spin_unlock_irqrestore(&adev->ddev->event_lock, flags);
> +}
> +
>   static int dm_set_clockgating_state(void *handle,
> enum amd_clockgating_state state)
>   {
> @@ -2175,7 +2238,7 @@ static int dcn10_register_irq_handlers(struct 
> amdgpu_device *adev)
>   c_irq_params->irq_src = int_params.irq_source;
> 
>   amdgpu_dm_irq_register_interrupt(adev, &int_params,
> - dm_crtc_high_irq, c_irq_params);
> + dm_dcn_crtc_high_irq, c_irq_params);
>   }
> 
>   /* Use VUPDATE_NO_LOCK interrupt on DCN, which seems to correspond to
> --
> 2.23.0
> 

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

Re: [PATCH 2/2 v2] drm/amd/display: Disable VUpdate interrupt for DCN hardware

[Kazlauskas, Nicholas]

On 2019-11-05 10:58 a.m., sunpeng...@amd.com wrote:
> From: Leo Li 
> 
> [Why]
> 
> On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
> handler redundant.
> 
> All the vupdate handler does is handle vblank events, and update vrr
> for DCE hw (excluding VEGA, more on that later). As far as usermode is
> concerned. vstartup happens close enough to vupdate on DCN that it can
> be considered the "same". Handling vblank and updating vrr at vstartup
> effectively replaces vupdate on DCN.
> 
> Vega is a bit special. Like DCN, the VRR registers on Vega are
> double-buffered, and swapped at vupdate. But Unlike DCN, it lacks a
> vstartup interrupt. This means we can't quite remove the vupdate handler
> for it, since delayerd user events due to vrr are sent off there.
> 
> [How]
> 
> Remove registration of VUpdate interrupt handler for DCN. Disable
> vupdate interrupt if asic family DCN, enable otherwise.
> 
> Signed-off-by: Leo Li 
> ---
> 
> v2: Don't exclude vega when enabling vupdate interrupts
> 
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 +++
>   1 file changed, 4 insertions(+), 30 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 256a23a0ec28..3664af3b41a1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2241,34 +2241,6 @@ static int dcn10_register_irq_handlers(struct 
> amdgpu_device *adev)
>   dm_dcn_crtc_high_irq, c_irq_params);
>   }
> 
> - /* Use VUPDATE_NO_LOCK interrupt on DCN, which seems to correspond to
> -  * the regular VUPDATE interrupt on DCE. We want DC_IRQ_SOURCE_VUPDATEx
> -  * to trigger at end of each vblank, regardless of state of the lock,
> -  * matching DCE behaviour.
> -  */
> - for (i = DCN_1_0__SRCID__OTG0_IHC_V_UPDATE_NO_LOCK_INTERRUPT;
> -  i <= DCN_1_0__SRCID__OTG0_IHC_V_UPDATE_NO_LOCK_INTERRUPT + 
> adev->mode_info.num_crtc - 1;
> -  i++) {
> - r = amdgpu_irq_add_id(adev, SOC15_IH_CLIENTID_DCE, i, 
> &adev->vupdate_irq);
> -
> - if (r) {
> - DRM_ERROR("Failed to add vupdate irq id!\n");
> - return r;
> - }
> -
> - int_params.int_context = INTERRUPT_HIGH_IRQ_CONTEXT;
> - int_params.irq_source =
> - dc_interrupt_to_irq_source(dc, i, 0);
> -
> - c_irq_params = &adev->dm.vupdate_params[int_params.irq_source - 
> DC_IRQ_SOURCE_VUPDATE1];
> -
> - c_irq_params->adev = adev;
> - c_irq_params->irq_src = int_params.irq_source;
> -
> - amdgpu_dm_irq_register_interrupt(adev, &int_params,
> - dm_vupdate_high_irq, c_irq_params);
> - }
> -
>   /* Use GRPH_PFLIP interrupt */
>   for (i = DCN_1_0__SRCID__HUBP0_FLIP_INTERRUPT;
>   i <= DCN_1_0__SRCID__HUBP0_FLIP_INTERRUPT + 
> adev->mode_info.num_crtc - 1;
> @@ -4266,7 +4238,7 @@ static inline int dm_set_vblank(struct drm_crtc *crtc, 
> bool enable)
>   struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state);
>   int rc = 0;
> 
> - if (enable) {
> + if (enable && adev->family <= AMDGPU_FAMILY_AI) {
>   /* vblank irq on -> Only need vupdate irq in vrr mode */
>   if (amdgpu_dm_vrr_active(acrtc_state))
>   rc = dm_set_vupdate_irq(crtc, true);
> @@ -6243,6 +6215,7 @@ static void pre_update_freesync_state_on_stream(
>   static void amdgpu_dm_handle_vrr_transition(struct dm_crtc_state *old_state,
>   struct dm_crtc_state *new_state)
>   {
> + struct amdgpu_device *adev = old_state->base.crtc->dev->dev_private;
>   bool old_vrr_active = amdgpu_dm_vrr_active(old_state);
>   bool new_vrr_active = amdgpu_dm_vrr_active(new_state);
> 
> @@ -6255,7 +6228,8 @@ static void amdgpu_dm_handle_vrr_transition(struct 
> dm_crtc_state *old_state,
>* We also need vupdate irq for the actual core vblank handling
>* at end of vblank.
>*/
> - dm_set_vupdate_irq(new_state->base.crtc, true);
> + if (adev->family <= AMDGPU_FAMILY_AI)
> + dm_set_vupdate_irq(new_state->base.crtc, true);

Can we move the if into dm_set_vupdate_irq directly? We're setting it to 
false even when we don't have it with this patch.

Nicholas Kazlauskas

>   drm_crtc_vblank_get(new_state->base.crtc);
>   DRM_DEBUG_DRIVER("%s: crtc=%u VRR off->on: Get vblank ref\n",
>__func__, new_state->base.crtc->base.id);
> --
> 2.23.0
> 

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

Re: [PATCH v4] drm/amd/display: Disable VUpdate interrupt for DCN hardware

[Kazlauskas, Nicholas]

On 2019-11-05 2:07 p.m., sunpeng...@amd.com wrote:
> From: Leo Li 
> 
> [Why]
> 
> On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
> handler redundant.
> 
> All the vupdate handler does is handle vblank events, and update vrr
> for DCE hw (excluding VEGA, more on that later). As far as usermode is
> concerned. vstartup happens close enough to vupdate on DCN that it can
> be considered the "same". Handling vblank and updating vrr at vstartup
> effectively replaces vupdate on DCN.
> 
> Vega is a bit special. Like DCN, the VRR registers on Vega are
> double-buffered, and swapped at vupdate. But Unlike DCN, it lacks a
> vstartup interrupt. This means we can't quite remove the vupdate handler
> for it, since delayed user events due to vrr are sent off there.
> 
> [How]
> 
> Remove registration of vupdate interrupt handler for DCN. Disable
> vupdate interrupt if asic family DCN, enable otherwise.
> 
> Signed-off-by: Leo Li 

Reviewed-by: Nicholas Kazlauskas 

> ---
> 
> v2: Don't exclude vega when enabling vupdate interrupts
> 
> v3: Move FAMILY_AI check inside dm_set_vupdate_irq()
> 
> v4: Correct a brain fart
> 
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +++
>   1 file changed, 4 insertions(+), 28 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 256a23a0ec28..d40185dfd0c0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2241,34 +2241,6 @@ static int dcn10_register_irq_handlers(struct 
> amdgpu_device *adev)
>   dm_dcn_crtc_high_irq, c_irq_params);
>   }
> 
> - /* Use VUPDATE_NO_LOCK interrupt on DCN, which seems to correspond to
> -  * the regular VUPDATE interrupt on DCE. We want DC_IRQ_SOURCE_VUPDATEx
> -  * to trigger at end of each vblank, regardless of state of the lock,
> -  * matching DCE behaviour.
> -  */
> - for (i = DCN_1_0__SRCID__OTG0_IHC_V_UPDATE_NO_LOCK_INTERRUPT;
> -  i <= DCN_1_0__SRCID__OTG0_IHC_V_UPDATE_NO_LOCK_INTERRUPT + 
> adev->mode_info.num_crtc - 1;
> -  i++) {
> - r = amdgpu_irq_add_id(adev, SOC15_IH_CLIENTID_DCE, i, 
> &adev->vupdate_irq);
> -
> - if (r) {
> - DRM_ERROR("Failed to add vupdate irq id!\n");
> - return r;
> - }
> -
> - int_params.int_context = INTERRUPT_HIGH_IRQ_CONTEXT;
> - int_params.irq_source =
> - dc_interrupt_to_irq_source(dc, i, 0);
> -
> - c_irq_params = &adev->dm.vupdate_params[int_params.irq_source - 
> DC_IRQ_SOURCE_VUPDATE1];
> -
> - c_irq_params->adev = adev;
> - c_irq_params->irq_src = int_params.irq_source;
> -
> - amdgpu_dm_irq_register_interrupt(adev, &int_params,
> - dm_vupdate_high_irq, c_irq_params);
> - }
> -
>   /* Use GRPH_PFLIP interrupt */
>   for (i = DCN_1_0__SRCID__HUBP0_FLIP_INTERRUPT;
>   i <= DCN_1_0__SRCID__HUBP0_FLIP_INTERRUPT + 
> adev->mode_info.num_crtc - 1;
> @@ -4249,6 +4221,10 @@ static inline int dm_set_vupdate_irq(struct drm_crtc 
> *crtc, bool enable)
>   struct amdgpu_device *adev = crtc->dev->dev_private;
>   int rc;
> 
> + /* Do not set vupdate for DCN hardware */
> + if (adev->family > AMDGPU_FAMILY_AI)
> + return 0;
> +
>   irq_source = IRQ_TYPE_VUPDATE + acrtc->otg_inst;
> 
>   rc = dc_interrupt_set(adev->dm.dc, irq_source, enable) ? 0 : -EBUSY;
> --
> 2.23.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] drm/amd/display: Send vblank and user events at vsartup for DCN

[Kazlauskas, Nicholas]

On 2019-11-05 1:32 p.m., Li, Sun peng (Leo) wrote:
> 
> 
> On 2019-11-05 11:15 a.m., Kazlauskas, Nicholas wrote:
>> On 2019-11-05 10:34 a.m., sunpeng...@amd.com wrote:
>>> From: Leo Li 
>>>
>>> [Why]
>>>
>>> For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
>>> interrupt. This is different from DCE, which has it assigned to vblank
>>> start.
>>>
>>> We'd like to send vblank and user events at vstartup because:
>>>
>>> * It happens close enough to vupdate - the point of no return for HW.
>>>
>>> * It is programmed as lines relative to vblank end - i.e. it is not in
>>> the variable portion when VRR is enabled. We should signal user
>>> events here.
>>>
>>> * The pflip interrupt responsible for sending user events today only
>>> fires if the DCH HUBP component is not clock gated. In situations
>>> where planes are disabled - but the CRTC is enabled - user events won't
>>> be sent out, leading to flip done timeouts.
>>>
>>> Consequently, this makes vupdate on DCN hardware redundant. It will be
>>> removed in the next change.
>>>
>>> [How]
>>>
>>> Add a DCN-specific crtc_high_irq handler, and hook it to the VStartup
>>> signal. Inside the DCN handler, we send off user events if the pflip
>>> handler hasn't already done so.
>>>
>>> Signed-off-by: Leo Li 
>>> ---
>>>.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 65 ++-
>>>1 file changed, 64 insertions(+), 1 deletion(-)
>>>
>>> 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 00017b91c91a..256a23a0ec28 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -485,6 +485,69 @@ static void dm_crtc_high_irq(void *interrupt_params)
>>> }
>>>}
>>>
>>> +
>>> +/**
>>> + * dm_dcn_crtc_high_irq() - Handles VStartup interrupt for DCN generation 
>>> ASICs
>>> + * @interrupt params - interrupt parameters
>>> + *
>>> + * Notify DRM's vblank event handler at VSTARTUP
>>> + *
>>> + * Unlike DCE hardware, we trigger the handler at VSTARTUP. at which:
>>> + * * We are close enough to VUPDATE - the point of no return for hw
>>> + * * We are in the fixed portion of variable front porch when vrr is 
>>> enabled
>>> + * * We are before VUPDATE, where double-buffered vrr registers are swapped
>>> + *
>>> + * It is therefore the correct place to signal vblank, send user flip 
>>> events,
>>> + * and update VRR.
>>> + */
>>> +static void dm_dcn_crtc_high_irq(void *interrupt_params)
>>> +{
>>> +   struct common_irq_params *irq_params = interrupt_params;
>>> +   struct amdgpu_device *adev = irq_params->adev;
>>> +   struct amdgpu_crtc *acrtc;
>>> +   struct dm_crtc_state *acrtc_state;
>>> +   unsigned long flags;
>>> +
>>> +   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
>>> IRQ_TYPE_VBLANK);
>>> +
>>> +   if (!acrtc)
>>> +   return;
>>> +
>>> +   acrtc_state = to_dm_crtc_state(acrtc->base.state);
>>> +
>>> +   DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
>>> +   amdgpu_dm_vrr_active(acrtc_state));
>>> +
>>> +   amdgpu_dm_crtc_handle_crc_irq(&acrtc->base);
>>> +   drm_crtc_handle_vblank(&acrtc->base);
>>
>> Shouldn't this be the other way around? Don't we want the CRC sent back
>> to userspace to have the updated vblank counter?
>>
>> This is how it worked before at least.
>>
>> Other than that, this patch looks fine to me.
>>
>> Nicholas Kazlauskas
> 
> 
> Looks like we're doing a crtc_accurate_vblank_count() inside the crc handler,
> so I don't think order matters here.
> 
> Leo

Sounds fine to me then.

Reviewed-by: Nicholas Kazlauskas 

Nicholas Kazlauskas

> 
>>
>>> +
>>> +   spin_lock_irqsave(&adev->ddev->event_lock, flags);
>>> +
>>> +   if (acrtc_state->vrr_params.supported &&
>>> +   acrtc_state->freesync_config.state == VRR_STATE_ACTIVE_VARIABLE) {
>>> +   mod_freesync_handle_v_

Re: [PATCH] drm/amdgpu/display: fix warning when CONFIG_DRM_AMD_DC_DCN is not set

[Kazlauskas, Nicholas]

On 2019-11-08 11:24 a.m., Alex Deucher wrote:
> dm_dcn_crtc_high_irq() is only used when CONFIG_DRM_AMD_DC_DCN is set.
> 
> Signed-off-by: Alex Deucher 

Reviewed-by: Nicholas Kazlauskas 

Thanks!

> ---
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> 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 d2c236946909..ef40adf187f6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -485,7 +485,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
>   }
>   }
>   
> -
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
>   /**
>* dm_dcn_crtc_high_irq() - Handles VStartup interrupt for DCN generation 
> ASICs
>* @interrupt params - interrupt parameters
> @@ -547,6 +547,7 @@ static void dm_dcn_crtc_high_irq(void *interrupt_params)
>   
>   spin_unlock_irqrestore(&adev->ddev->event_lock, flags);
>   }
> +#endif
>   
>   static int dm_set_clockgating_state(void *handle,
> enum amd_clockgating_state state)
> 

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

Re: [PATCH] drm/amd/display: remove duplicated comparison expression

[Kazlauskas, Nicholas]

On 2019-11-09 10:49 a.m., Colin King wrote:

From: Colin Ian King 

There is comparison expression that is duplicated and hence one
of the expressions can be removed.  Remove it.

Addresses-Coverity: ("Same on both sides")
Fixes: 12e2b2d4c65f ("drm/amd/display: add dcc programming for dual plane")
Signed-off-by: Colin Ian King 


Reviewed-by: Nicholas Kazlauskas 

Thanks!

Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/core/dc.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 1fdba13b3d0f..1fa255e077d0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1491,7 +1491,6 @@ static enum surface_update_type 
get_plane_info_update_type(const struct dc_surfa
}
  
  	if (u->plane_info->plane_size.surface_pitch != u->surface->plane_size.surface_pitch

-   || u->plane_info->plane_size.surface_pitch != 
u->surface->plane_size.surface_pitch
|| u->plane_info->plane_size.chroma_pitch != 
u->surface->plane_size.chroma_pitch) {
update_flags->bits.plane_size_change = 1;
elevate_update_type(&update_type, UPDATE_TYPE_MED);



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

Re: [PATCH][next] drm/amd/display: fix spelling mistake "exeuction" -> "execution"

[Kazlauskas, Nicholas]

On 2019-11-09 2:49 p.m., Colin King wrote:

From: Colin Ian King 

There are spelling mistakes in a DC_ERROR message and a comment.
Fix these.

Signed-off-by: Colin Ian King 


Reviewed-by: Nicholas Kazlauskas 

Thanks!

Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c| 2 +-
  drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c 
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index 61cefe0a3790..b65b66025267 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -92,7 +92,7 @@ void dc_dmub_srv_cmd_execute(struct dc_dmub_srv *dc_dmub_srv)
  
  	status = dmub_srv_cmd_execute(dmub);

if (status != DMUB_STATUS_OK)
-   DC_ERROR("Error starting DMUB exeuction: status=%d\n", status);
+   DC_ERROR("Error starting DMUB execution: status=%d\n", status);
  }
  
  void dc_dmub_srv_wait_idle(struct dc_dmub_srv *dc_dmub_srv)

diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h 
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h
index aa8f0396616d..45e427d1952e 100644
--- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h
@@ -416,7 +416,7 @@ enum dmub_status dmub_srv_cmd_queue(struct dmub_srv *dmub,
   * dmub_srv_cmd_execute() - Executes a queued sequence to the dmub
   * @dmub: the dmub service
   *
- * Begins exeuction of queued commands on the dmub.
+ * Begins execution of queued commands on the dmub.
   *
   * Return:
   *   DMUB_STATUS_OK - success



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

Re: AMDGPU bug

[Kazlauskas, Nicholas]

On 2019-11-10 7:00 p.m., Subsentient wrote:
Hi, I've been experiencing a bug on kernels 5.2 and up that apparently 
is uncommon and/or unimportant enough to have both threads mentioning it 
die.


On a Ryzen 3 2200G, the amdgpu driver fails upon lightdm login:

https://bugzilla.redhat.com/show_bug.cgi?id=1752188

I thought I'd bring this to your attention as the others reporting this 
bug have so far been met with silence, and this has trapped me and 
others on the unsupported kernel 5.1.21.


Thanks for your time.



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



I'm not sure that the backtrace listed is particularly relevant for 
describing what issue is actually occurring, but if I had to take a 
guess based on the ASIC and kernel version I would imagine that it's 
Raven's displayable DCC support that's causing you issues.


I believe you'd need to be running mesa, xf86-video-amdgpu and running 
without a compositor in your desktop manager. Does this describe your setup?


If you can bisect that would help narrow things down further. The bisect 
commit would likely be one that's just changing the amdgpu version 
number if it's DCC (since mesa checks that before deciding to enable 
displayable DCC).


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

Re: [PATCH 2/2] drm/amd/display: Fix coding error in connector atomic check

[Kazlauskas, Nicholas]

On 2019-11-12 10:15 a.m., mikita.lip...@amd.com wrote:

From: Mikita Lipski 

[why]
For MST connector atomic check we have to check a new CRTC state
instead of an old one, when checking if CRTC is disabled to
release VCPI slots allocated.

Signed-off-by: Mikita Lipski 


Reviewed-by: Nicholas Kazlauskas 

Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 21f09b61ee88..00cb2f109853 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -299,7 +299,7 @@ static int dm_dp_mst_atomic_check(struct drm_connector 
*connector,
return 0;
  
  	if (new_conn_state->crtc) {

-   new_crtc_state = drm_atomic_get_old_crtc_state(state, 
new_conn_state->crtc);
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc);
if (!new_crtc_state ||
!drm_atomic_crtc_needs_modeset(new_crtc_state) ||
new_crtc_state->enable)



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

Re: [PATCH 1/2] drm/amd/display: Return correct error value

[Kazlauskas, Nicholas]

On 2019-11-12 10:16 a.m., mikita.lip...@amd.com wrote:

From: Mikita Lipski 

[why]
The function is expected to return instance of the timing generator
therefore we shouldn't be returning boolean in integer function,
and we shouldn't be returning zero so changing it to -1.

Signed-off-by: Mikita Lipski 


I wonder if some of these were intentional for returning 0. These lines 
were originally introduced for enabling seamless boot support with eDP 
and I think you're guaranteed to have those resources as instance 0.


Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 89b5f86cd40b..75cc58ecf647 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1866,7 +1866,7 @@ static int acquire_resource_from_hw_enabled_state(
inst = link->link_enc->funcs->get_dig_frontend(link->link_enc);
  
  	if (inst == ENGINE_ID_UNKNOWN)

-   return false;
+   return -1;
  
  	for (i = 0; i < pool->stream_enc_count; i++) {

if (pool->stream_enc[i]->id == inst) {
@@ -1878,10 +1878,10 @@ static int acquire_resource_from_hw_enabled_state(
  
  	// tg_inst not found

if (i == pool->stream_enc_count)
-   return false;
+   return -1;
  
  	if (tg_inst >= pool->timing_generator_count)

-   return false;
+   return -1;
  
  	if (!res_ctx->pipe_ctx[tg_inst].stream) {

struct pipe_ctx *pipe_ctx = &res_ctx->pipe_ctx[tg_inst];



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

Re: [PATCH] Revert "drm/amd/display: revert wait in pipelock"

[Kazlauskas, Nicholas]

On 2019-11-15 10:13 a.m., Alex Deucher wrote:

This reverts commit 617089d5837a3aa4167a9c4afb34929e0d52805d.

This causes hangs in some games.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205169
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=112266
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205169
Signed-off-by: Alex Deucher 


I think this will also just hang the system in some cases.

I know that if we're waiting for flip pending == 0 on plane enable we've 
hit cases where it's hung infinitely on dcn20.


Since this code is in pipe lock itself (where this timeout code was 
contained) this means that we'd similarly see a similar hang - but only 
in the case where we'd switching flip types.


This probably needs to have a timeout of 100ms or so like the plane enable:

if (flip_immediate && lock) {
const int TIMEOUT_FOR_FLIP_PENDING = 10;
int i;

for (i = 0; i < TIMEOUT_FOR_FLIP_PENDING; ++i) {
if (pipe->plane_res.hubp->funcs->hubp_is_flip_pending(
pipe->plane_res.hubp))
break;

udelay(1);
}

if (pipe->bottom_pipe != NULL) {
for (i = 0; i < TIMEOUT_FOR_FLIP_PENDING; ++i) {
if (pipe->bottom_pipe->plane_res.hubp->funcs
->hubp_is_flip_pending(
pipe->bottom_pipe->plane_res
.hubp))
break;

udelay(1);
}
}
}

Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
index 0046a099c9e9..9b4488ef27d1 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
@@ -1033,6 +1033,17 @@ void dcn20_pipe_control_lock(
if (pipe->plane_state != NULL)
flip_immediate = pipe->plane_state->flip_immediate;
  
+	if (flip_immediate && lock) {

+   while 
(pipe->plane_res.hubp->funcs->hubp_is_flip_pending(pipe->plane_res.hubp)) {
+   udelay(1);
+   }
+
+   if (pipe->bottom_pipe != NULL)
+   while 
(pipe->bottom_pipe->plane_res.hubp->funcs->hubp_is_flip_pending(pipe->bottom_pipe->plane_res.hubp))
 {
+   udelay(1);
+   }
+   }
+
/* In flip immediate and pipe splitting case, we need to use GSL
 * for synchronization. Only do setup on locking and on flip type 
change.
 */



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

Re: [PATCH v2] drm/amd/display: Fix Apple dongle cannot be successfully detected

[Kazlauskas, Nicholas]

On 2019-11-21 3:31 a.m., Li, Ching-shih (Louis) wrote:

Hi reviewers,

What is the review result for this patch? Customer is pushing on this change to 
merge. TKS for your attention.

BR,
Louis

-Original Message-
From: Louis Li 
Sent: Thursday, November 14, 2019 11:42 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Wentland, Harry 
; Li, Ching-shih (Louis) 
Subject: [PATCH v2] drm/amd/display: Fix Apple dongle cannot be successfully 
detected

[Why]
External monitor cannot be displayed consistently, if connecting via this Apple 
dongle (A1621, USB Type-C to HDMI).
By experiments, it is confirmed that the dongle needs 200ms at least to be 
ready for communication, after it sets HPD signal high.

[How]
When receiving HPD IRQ, delay 300ms at the beginning of handle_hpd_irq().
Then run the original procedure.
With this patch applied, the problem cannot be reproduced.
With other dongles, test results are PASS.
Test result is PASS to plug in HDMI cable while playing video, and the video is 
being playing smoothly.
Test result is PASS after system resumes from suspend.

Signed-off-by: Louis Li 


This is still a NAK from me since the logic hasn't changed from the 
first patch.


Sleeps don't belong in IRQ handlers.

Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
  1 file changed, 5 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 0aef92b7c037..5b844b6a5a59 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1025,6 +1025,11 @@ static void handle_hpd_irq(void *param)
struct drm_device *dev = connector->dev;
enum dc_connection_type new_connection_type = dc_connection_none;
  
+	/* Some monitors/dongles need around 200ms to be ready for communication

+* after those devices drive HPD signal high.
+*/
+   msleep(300);
+
/* In case of failure or MST no need to update connector status or 
notify the OS
 * since (for MST case) MST does this in it's own context.
 */
--
2.21.0



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

Re: [PATCH v2] drm/amd/display: Fix Apple dongle cannot be successfully detected

[Kazlauskas, Nicholas]

On 2019-11-21 8:40 a.m., Kazlauskas, Nicholas wrote:

On 2019-11-21 3:31 a.m., Li, Ching-shih (Louis) wrote:

Hi reviewers,

What is the review result for this patch? Customer is pushing on this 
change to merge. TKS for your attention.


BR,
Louis

-Original Message-
From: Louis Li 
Sent: Thursday, November 14, 2019 11:42 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Wentland, 
Harry ; Li, Ching-shih (Louis) 

Subject: [PATCH v2] drm/amd/display: Fix Apple dongle cannot be 
successfully detected


[Why]
External monitor cannot be displayed consistently, if connecting via 
this Apple dongle (A1621, USB Type-C to HDMI).
By experiments, it is confirmed that the dongle needs 200ms at least 
to be ready for communication, after it sets HPD signal high.


[How]
When receiving HPD IRQ, delay 300ms at the beginning of handle_hpd_irq().
Then run the original procedure.
With this patch applied, the problem cannot be reproduced.
With other dongles, test results are PASS.
Test result is PASS to plug in HDMI cable while playing video, and the 
video is being playing smoothly.

Test result is PASS after system resumes from suspend.

Signed-off-by: Louis Li 


This is still a NAK from me since the logic hasn't changed from the 
first patch.


Sleeps don't belong in IRQ handlers.

Regards,
Nicholas Kazlauskas


Actually, this lives in the low IRQ context which means that it's 
already been queued off to a work thread so it's safe to sleep.


I'm not sure we want a general 300ms sleep (even by experiment you said 
that it only needed 200ms) for all connectors.


Nicholas Kazlauskas




---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
  1 file changed, 5 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 0aef92b7c037..5b844b6a5a59 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1025,6 +1025,11 @@ static void handle_hpd_irq(void *param)
  struct drm_device *dev = connector->dev;
  enum dc_connection_type new_connection_type = dc_connection_none;
+    /* Some monitors/dongles need around 200ms to be ready for 
communication

+ * after those devices drive HPD signal high.
+ */
+    msleep(300);
+
  /* In case of failure or MST no need to update connector status 
or notify the OS

   * since (for MST case) MST does this in it's own context.
   */
--
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 default clocks if not able to fetch them

[Kazlauskas, Nicholas]

Reviewed-by: Nicholas Kazlauskas 

On 2019-11-22 1:09 p.m., Alex Deucher wrote:

Ping?

On Tue, Nov 19, 2019 at 3:56 PM Alex Deucher  wrote:


dm_pp_get_clock_levels_by_type needs to add the default clocks
to the powerplay case as well.  This was accidently dropped.

Fixes: b3ea88fef321de ("drm/amd/powerplay: add get_clock_by_type interface for 
display")
Signed-off-by: Alex Deucher 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index 229788bee544..a2e1a73f66b8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -342,7 +342,8 @@ bool dm_pp_get_clock_levels_by_type(
 if (adev->powerplay.pp_funcs && 
adev->powerplay.pp_funcs->get_clock_by_type) {
 if (adev->powerplay.pp_funcs->get_clock_by_type(pp_handle,
 dc_to_pp_clock_type(clk_type), &pp_clks)) {
-   /* Error in pplib. Provide default values. */
+   /* Error in pplib. Provide default values. */
+   get_default_clock_levels(clk_type, dc_clks);
 return true;
 }
 } else if (adev->smu.ppt_funcs && 
adev->smu.ppt_funcs->get_clock_by_type) {
--
2.23.0




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

Re: [PATCH] drm/amd/display: Null check aconnector in event_property_validate

[Kazlauskas, Nicholas]

On 2019-11-25 10:40 a.m., Bhawanpreet Lakha wrote:

[Why]
previously event_property_validate was only called after we enabled the display.
But after "Refactor HDCP to handle multiple displays per link" this function
can be called at any time. In certain cases we don't have a aconnector

[How]
Null check aconnector and exit early. This is ok because we only need to check 
the
ENABLED->DESIRED transition if a connector exists.

Fixes :cc5dae9f6286 drm/amd/display: Refactor HDCP to handle multiple displays 
per link


This should be:

Fixes: cc5dae9f6286 ("drm/amd/display: Refactor HDCP to handle multiple 
displays per link")



Signed-off-by: Bhawanpreet Lakha 


With that fixed this change is:

Reviewed-by: Nicholas Kazlauskas 

Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
index f6864a51891a..ae329335dfcc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
@@ -225,6 +225,9 @@ static void event_property_validate(struct work_struct 
*work)
struct mod_hdcp_display_query query;
struct amdgpu_dm_connector *aconnector = hdcp_work->aconnector;
  
+	if (!aconnector)

+   return;
+
mutex_lock(&hdcp_work->mutex);
  
  	query.encryption_status = MOD_HDCP_ENCRYPTION_STATUS_HDCP_OFF;




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

Re: drm/amd/display: Modify comments to match the code

[Kazlauskas, Nicholas]

On 2019-11-26 9:46 a.m., Zhan liu wrote:

[Why]
This line of code was modified. However, comments
remained unchanged. As a result, comments and code are
mismatching.

[How]
Modifying comments to reflect code. At the same time,
explaining why the value was changed from 200ms to
3000ms.

Signed-off-by: Zhan Liu 


Reviewed-by: Nicholas Kazlauskas 


---
  drivers/gpu/drm/amd/display/dc/dc_helper.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_helper.c 
b/drivers/gpu/drm/amd/display/dc/dc_helper.c
index 8da4576e2908..e41befa067ce 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_helper.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_helper.c
@@ -485,7 +485,12 @@ void generic_reg_wait(const struct dc_context *ctx,
return;
}
  
-	/* something is terribly wrong if time out is > 200ms. (5Hz) */

+   /*
+* Something is terribly wrong if time out is > 3000ms.
+* 3000ms is the maximum time needed for SMU to pass values back.
+* This value comes from experiments.
+*
+*/
ASSERT(delay_between_poll_us * time_out_num_tries <= 300);
  
  	for (i = 0; i <= time_out_num_tries; i++) {




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

Re: [PATCH] drm/amd/display: Get NV14 specific ip params as needed

[Kazlauskas, Nicholas]

On 2019-11-26 4:32 p.m., Zhan Liu wrote:

[Why]
NV14 is using its own ip params that's different from other
DCN2.0 ASICs.

[How]
Add ASIC revision check to make sure NV14 gets correct
ip params.

Signed-off-by: Zhan Liu 


Reviewed-by: Nicholas Kazlauskas 


---
  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 dbc0a4a7c284..3dd2b2429ae2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -3245,6 +3245,9 @@ static struct _vcs_dpi_soc_bounding_box_st 
*get_asic_rev_soc_bb(
  static struct _vcs_dpi_ip_params_st *get_asic_rev_ip_params(
uint32_t hw_internal_rev)
  {
+   if (ASICREV_IS_NAVI14_M(hw_internal_rev))
+   return &dcn2_0_nv14_ip;
+
/* NV12 and NV10 */
return &dcn2_0_ip;
  }



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

Re: [PATCH] drm/amd/display: Drop AMD_EDID_UTILITY defines

[Kazlauskas, Nicholas]

On 2019-11-28 11:33 a.m., Harry Wentland wrote:

We don't use this upstream in the Linux kernel.

Signed-off-by: Harry Wentland 


Reviewed-by: Nicholas Kazlauskas 


---
  drivers/gpu/drm/amd/display/dc/dc_dsc.h  | 2 --
  drivers/gpu/drm/amd/display/dc/dc_hw_types.h | 8 
  drivers/gpu/drm/amd/display/dc/dc_types.h| 4 
  3 files changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dsc.h 
b/drivers/gpu/drm/amd/display/dc/dc_dsc.h
index a782ae18a1c5..cc9915e545cd 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dsc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dsc.h
@@ -41,10 +41,8 @@ struct dc_dsc_bw_range {
  
  struct display_stream_compressor {

const struct dsc_funcs *funcs;
-#ifndef AMD_EDID_UTILITY
struct dc_context *ctx;
int inst;
-#endif
  };
  
  bool dc_dsc_parse_dsc_dpcd(const uint8_t *dpcd_dsc_basic_data,

diff --git a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
index 86043d431d40..25c50bcab9e9 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
@@ -26,8 +26,6 @@
  #ifndef DC_HW_TYPES_H
  #define DC_HW_TYPES_H
  
-#ifndef AMD_EDID_UTILITY

-
  #include "os_types.h"
  #include "fixed31_32.h"
  #include "signal_types.h"
@@ -584,8 +582,6 @@ struct scaling_taps {
bool integer_scaling;
  };
  
-#endif /* AMD_EDID_UTILITY */

-
  enum dc_timing_standard {
DC_TIMING_STANDARD_UNDEFINED,
DC_TIMING_STANDARD_DMT,
@@ -742,8 +738,6 @@ struct dc_crtc_timing {
struct dc_dsc_config dsc_cfg;
  };
  
-#ifndef AMD_EDID_UTILITY

-
  enum trigger_delay {
TRIGGER_DELAY_NEXT_PIXEL = 0,
TRIGGER_DELAY_NEXT_LINE,
@@ -837,7 +831,5 @@ struct tg_color {
uint16_t color_b_cb;
  };
  
-#endif /* AMD_EDID_UTILITY */

-
  #endif /* DC_HW_TYPES_H */
  
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h b/drivers/gpu/drm/amd/display/dc/dc_types.h

index 1363e8907fbf..2b92bfa28bde 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -25,7 +25,6 @@
  #ifndef DC_TYPES_H_
  #define DC_TYPES_H_
  
-#ifndef AMD_EDID_UTILITY

  /* AND EdidUtility only needs a portion
   * of this file, including the rest only
   * causes additional issues.
@@ -781,9 +780,6 @@ struct dc_clock_config {
uint32_t current_clock_khz;/*current clock in use*/
  };
  
-#endif /*AMD_EDID_UTILITY*/

-//AMD EDID UTILITY does not need any of the above structures
-
  /* DSC DPCD capabilities */
  union dsc_slice_caps1 {
struct {



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

Re: [PATCH] drm/amd/display: Loading NV10/14 Bounding Box Data Directly From Code

[Kazlauskas, Nicholas]

On 2019-12-03 12:02 p.m., Zhan Liu wrote:

[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.

Signed-off-by: Zhan Liu 
---
  .../drm/amd/display/dc/dcn20/dcn20_resource.c | 199 +++---
  1 file changed, 121 insertions(+), 2 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..4115b595e36e 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 +3196,12 @@ static bool init_soc_bounding_box(struct dc *dc,
  
  	DC_LOGGER_INIT(dc->ctx->logger);
  
-	if (!bb && !SOC_BOUNDING_BOX_VALID) {

+   if (!bb) {


This will throw an error when we don't have firmware on disk (which now 
isn't required for Navi10 or Navi14).


Please replace SOC_BOUNDING_BOX_VALID with a function that has the logic 
to check whether the ASIC is Navi12 or not and use it below as well...



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)) {


...here, eg.

static bool is_soc_bounding_box_valid(uint32_t hw_internal_rev)
{
if (ASICREV_IS_NAVI12_P(hw_internal_rev))
return false;

return true;
}



int i;
  
  		dcn2_0_nv12_soc.sr_exit_time_us =

@@ -3380,6 +3305,108 @@ static bool init_soc_bounding_box(struct dc *dc,
}
}
  
+	if (bb && (ASICREV_IS_NAVI14_M(dc->ctx->asic_id.hw_internal_rev) || ASICREV_IS_NAVI10_P(dc->ctx->asic_id.hw_internal_rev))) {


These constants are already in the table. We shouldn't need to be 
filling them in below.


Regards,
Nicholas Kazlauskas


+   dcn2_0_soc.sr_exit_time_us = 8.6;
+   dcn2_0_soc.sr_enter_plus_exit_time_us = 10.9;
+   dcn2_0_soc.urgent_latency_us = 4.0;
+   dcn2_0_soc.urgent_latency_pixel_data_only_us = 4.0;
+   dcn2_0_soc.urgent_latency_pixel_mixed_with_vm_data_us = 4.0;
+   dcn2_0_soc.urgent_latency_vm_data_only_us = 4.0;
+   
dcn2_0_soc.urgent_out_of_order_return_per_channel_pixel_only_bytes = 4096;
+   
dcn2_0_soc.urgent_out_of_order_return_per_channel_pixel_and_vm_bytes = 4096;
+   dcn2_0_soc.urgent_out_of_order_return_per_channel_vm_only_bytes 
= 4096;
+   dcn2_0_soc.pct_ideal_dram_sdp_bw_after_urgent_pixel_only = 40.0;
+   dcn2_0_soc.pct_ideal_dram_sdp_bw_after_urgent_pixel_and_vm = 
40.0;
+   dcn2_0_soc.pct_ideal_dram_sdp_bw_after_urgent_vm_only = 40.0;
+   dcn2_0_soc.max_avg_sdp_bw_use_normal_percent = 40.0;
+   dcn2_0_soc.max_avg_dram_bw_use_normal_percent = 40.0;
+   dcn2_0_soc.writeback_latency_us = 12.0;
+   dcn2_0_soc.ideal_dram_bw_after_urgent_percent = 40.0;
+   dcn2_0_soc.max_request_size_bytes = 256;
+   dcn2_0_soc.dram_channel_width_bytes = 2;
+   dcn2_0_soc.fabric_datapath_to_dcn_data_return_bytes = 64;
+   dcn2_0_soc.dcn_downspread_percent = 0.5;
+   dcn2_0_soc.downspread_percent = 0.38;
+   dcn2_0_soc.dram_page_open_time_ns = 50.0;
+   dcn2_0_soc.dram_rw_turnaround_time_ns = 17.5;
+   dcn2_0_soc.dram_return_buffer_per_channel_bytes = 8192;
+   dcn2_0_soc.round_trip_ping_latency_dcfclk_cycles = 131;
+   dcn2_0_soc.urgent_out_of_order_return_per_channel_bytes = 256;
+   dcn2_0_soc.channel_interleave_bytes = 256;
+   dcn2_0_soc.num_banks = 8;
+   dcn2_0_soc.num_chans = 16;
+   dcn2_0_soc.vmm_page_size_bytes = 4096;
+   dcn2_0_soc.dram_clock_change_latency_us = 404.0;
+   dcn2_0_soc.dummy_pstate_latency_us = 5.0;
+   dcn2_0_soc.writeback_dram_clock_change_latency_us = 23.0;
+   dcn2_0_soc.return_bus_width_bytes = 64;
+   dcn2_0_soc.dispclk_dppclk_vco_speed_mhz = 3850;
+   dcn2_0_soc.xfc_bus_transport_time_us = 20;
+   dcn2_0_soc.xfc_xbuf_latency_tolerance_us = 4;
+   dcn2_0_soc.use_urgent_burst_bw = 0;
+   dcn2_0_soc.num_states = 5;
+
+   dcn2_0_soc.clock_limits[0].state = 0;
+   dcn2_0_soc.clock_limits[0].dcfclk_mhz = 560.0;
+   dcn2_0_soc.clock_limits[0].fabricclk_mhz = 560.0;
+   dcn2_0_soc.clock_limits[0].dispclk_mhz = 513.0;
+   dcn2_0_soc.clock_limits[0].dppclk_mhz = 513.0;
+   

Re: [PATCH] drm/amd/display: include linux/slab.h where needed

[Kazlauskas, Nicholas]

On 2019-12-10 2:59 p.m., Arnd Bergmann wrote:

Calling kzalloc() and related functions requires the
linux/slab.h header to be included:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function 
'dcn21_ipp_create':
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:679:3: error: 
implicit declaration of function 'kzalloc'; did you mean 'd_alloc'? 
[-Werror=implicit-function-declaration]
kzalloc(sizeof(struct dcn10_ipp), GFP_KERNEL);

A lot of other headers also miss a direct include in this file,
but this is the only one that causes a problem for now.

Signed-off-by: Arnd Bergmann 


What version of the kernel are you building?

We have:

#include 

in os_types.h which gets included as part of this file:

#include  -> #include  -> #include 

Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index 906c84e6b49b..af57885bbff2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -23,6 +23,8 @@
   *
   */
  
+#include 

+
  #include "dm_services.h"
  #include "dc.h"
  



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

Re: [PATCH] drm/amd/display: fix undefined struct member reference

[Kazlauskas, Nicholas]

On 2019-12-10 3:54 p.m., Liu, Zhan wrote:




-Original Message-
From: Arnd Bergmann 
Sent: 2019/December/10, Tuesday 3:31 PM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Deucher, Alexander
; Koenig, Christian
; Zhou, David(ChunMing)
; David Airlie ; Daniel Vetter
; Liu, Zhan 
Cc: Arnd Bergmann ; Laktyushkin, Dmytro
; Lakha, Bhawanpreet
; Lei, Jun ; Liu,
Charlene ; Yang, Eric ;
Cornij, Nikola ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: [PATCH] drm/amd/display: fix undefined struct member reference

An initialization was added for two optional struct members.  One of these is
always present in the dcn20_resource file, but the other one depends on
CONFIG_DRM_AMD_DC_DSC_SUPPORT and causes a build failure if that is
missing:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:926:1
4: error: excess elements in struct initializer [-Werror]
.num_dsc = 5,

Add another #ifdef around the assignment.

Fixes: c3d03c5a196f ("drm/amd/display: Include num_vmid and num_dsc
within NV14's resource caps")
Signed-off-by: Arnd Bergmann 


Thank you for catching that 😊 On my side I kept that flag enabled all the time, 
so I didn't realize there was a warning hidden here.

Reviewed-by: Zhan Liu 


What tree is this reported on?

We dropped this flag whenever building DCN. Sounds like we're missing a 
patch if you're getting this.


So this is a NAK from me for going into amd-staging-drm-next at least.

Nicholas Kazlauskas




---
  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 ++
  1 file changed, 2 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 faab89d1e694..fdf93e6edf43 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -923,7 +923,9 @@ static const struct resource_caps res_cap_nv14 = {
.num_dwb = 1,
.num_ddc = 5,
.num_vmid = 16,
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
.num_dsc = 5,
+#endif
  };

  static const struct dc_debug_options debug_defaults_drv = {
--
2.20.0


___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [PATCH 1/2] drm/amdgpu/display: include delay.h

[Kazlauskas, Nicholas]

On 2019-12-17 3:47 p.m., Alex Deucher wrote:

For udelay.  This is needed for some platforms.

Signed-off-by: Alex Deucher 


Reviewed-by: Nicholas Kazlauskas 

I wonder if it makes more sense to include this in os_types.h to avoid 
these errors in the future.


Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c 
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c
index 110c8620907b..bcbc0b8a9aa0 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_execution.c
@@ -23,6 +23,8 @@
   *
   */
  
+#include 

+
  #include "hdcp.h"
  
  static inline enum mod_hdcp_status check_receiver_id_list_ready(struct mod_hdcp *hdcp)




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

Re: [PATCH] drm/amd/display: Make underlay rules less strict

[Kazlauskas, Nicholas]

On 2021-05-07 10:37 a.m., Rodrigo Siqueira wrote:

Currently, we reject all conditions where the underlay plane goes
outside the overlay plane limits, which is not entirely correct since we
reject some valid cases like the ones illustrated below:

   ++  ++
   |   Overlay plane|  |   Overlay plane|
   ||  |+---|--+
   | +--+   |  ||   |  |
   | |  |   |  ||   |  |
   ++  ++  |
 | Primary plane|   +--+
 |  (underlay)  |
 +--+
   +-+--+---+  ++
   |Overlay plane   |  |Overlay plane   |
+-|+   |  |   +--+
| ||   |  |   || |
| ||   |  |   || |
| ||   |  |   || |
+-|+   |  |   +--+
   ++  ++

This patch fixes this issue by only rejecting commit requests where the
underlay is entirely outside the overlay limits. After applying this
patch, a set of subtests related to kms_plane, kms_plane_alpha_blend,
and kms_plane_scaling will pass.

Signed-off-by: Rodrigo Siqueira 


What's the size of the overlay plane in your examples? If the overlay 
plane does not cover the entire screen then this patch is incorrect.


We don't want to be enabling the cursor on multiple pipes and the checks 
in DC to allow disabling cursor on bottom pipes only work if the 
underlay is entirely contained within the overlay.


In the case where the primary (underlay) plane extends beyond the screen 
boundaries it should be preclipped by userspace or earlier in the DM 
code before this check.


Feel free to follow up with clarification, but for now this patch is a 
NAK from me.


Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 
  1 file changed, 4 insertions(+), 4 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 cc048c348a92..15006aafc630 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10098,10 +10098,10 @@ static int validate_overlay(struct drm_atomic_state 
*state)
return 0;
  
  	/* Perform the bounds check to ensure the overlay plane covers the primary */

-   if (primary_state->crtc_x < overlay_state->crtc_x ||
-   primary_state->crtc_y < overlay_state->crtc_y ||
-   primary_state->crtc_x + primary_state->crtc_w > overlay_state->crtc_x 
+ overlay_state->crtc_w ||
-   primary_state->crtc_y + primary_state->crtc_h > overlay_state->crtc_y 
+ overlay_state->crtc_h) {
+   if (primary_state->crtc_x + primary_state->crtc_w < 
overlay_state->crtc_x ||
+   primary_state->crtc_x > overlay_state->crtc_x + 
overlay_state->crtc_w ||
+   primary_state->crtc_y > overlay_state->crtc_y + 
overlay_state->crtc_h ||
+   primary_state->crtc_y + primary_state->crtc_h < 
overlay_state->crtc_y) {
DRM_DEBUG_ATOMIC("Overlay plane is enabled with hardware cursor but 
does not fully cover primary plane\n");
return -EINVAL;
}



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

Re: [PATCH] drm/amd/display: Move plane code from amdgpu_dm to amdgpu_dm_plane

[Kazlauskas, Nicholas]

On 2021-05-07 10:39 a.m., Rodrigo Siqueira wrote:

The amdgpu_dm file contains most of the code that works as an interface
between DRM API and Display Core. We maintain all the plane operations
inside amdgpu_dm; this commit extracts the plane code to its specific
file named amdgpu_dm_plane. This commit does not introduce any
functional change to the functions; it only changes some static
functions to global and adds some minor adjustments related to the copy
from one place to another.

Signed-off-by: Rodrigo Siqueira 
---
  .../gpu/drm/amd/display/amdgpu_dm/Makefile|9 +-
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1479 +---
  .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 1496 +
  .../amd/display/amdgpu_dm/amdgpu_dm_plane.h   |   56 +
  4 files changed, 1559 insertions(+), 1481 deletions(-)
  create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
  create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile 
b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
index 9a3b7bf8ab0b..6542ef0ff83e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
@@ -23,9 +23,12 @@
  # Makefile for the 'dm' sub-component of DAL.
  # It provides the control and status of dm blocks.
  
-

-
-AMDGPUDM = amdgpu_dm.o amdgpu_dm_irq.o amdgpu_dm_mst_types.o amdgpu_dm_color.o
+AMDGPUDM := \
+   amdgpu_dm.o \
+   amdgpu_dm_color.o \
+   amdgpu_dm_irq.o \
+   amdgpu_dm_mst_types.o \
+   amdgpu_dm_plane.o
  
  ifneq ($(CONFIG_DRM_AMD_DC),)

  AMDGPUDM += amdgpu_dm_services.o amdgpu_dm_helpers.o amdgpu_dm_pp_smu.o
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 cc048c348a92..60ddb4d8be6c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -44,6 +44,7 @@
  #include "amdgpu_ucode.h"
  #include "atom.h"
  #include "amdgpu_dm.h"
+#include "amdgpu_dm_plane.h"
  #ifdef CONFIG_DRM_AMD_DC_HDCP
  #include "amdgpu_dm_hdcp.h"
  #include 
@@ -181,10 +182,6 @@ static int amdgpu_dm_initialize_drm_device(struct 
amdgpu_device *adev);
  /* removes and deallocates the drm structures, created by the above function 
*/
  static void amdgpu_dm_destroy_drm_device(struct amdgpu_display_manager *dm);
  
-static int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm,

-   struct drm_plane *plane,
-   unsigned long possible_crtcs,
-   const struct dc_plane_cap *plane_cap);
  static int amdgpu_dm_crtc_init(struct amdgpu_display_manager *dm,
   struct drm_plane *plane,
   uint32_t link_index);
@@ -203,9 +200,6 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state);
  static int amdgpu_dm_atomic_check(struct drm_device *dev,
  struct drm_atomic_state *state);
  
-static void handle_cursor_update(struct drm_plane *plane,

-struct drm_plane_state *old_plane_state);
-
  static void amdgpu_dm_set_psr_caps(struct dc_link *link);
  static bool amdgpu_dm_psr_enable(struct dc_stream_state *stream);
  static bool amdgpu_dm_link_setup_psr(struct dc_stream_state *stream);
@@ -4125,925 +4119,12 @@ static const struct drm_encoder_funcs 
amdgpu_dm_encoder_funcs = {
.destroy = amdgpu_dm_encoder_destroy,
  };
  
-

-static void get_min_max_dc_plane_scaling(struct drm_device *dev,
-struct drm_framebuffer *fb,
-int *min_downscale, int *max_upscale)
-{
-   struct amdgpu_device *adev = drm_to_adev(dev);
-   struct dc *dc = adev->dm.dc;
-   /* Caps for all supported planes are the same on DCE and DCN 1 - 3 */
-   struct dc_plane_cap *plane_cap = &dc->caps.planes[0];
-
-   switch (fb->format->format) {
-   case DRM_FORMAT_P010:
-   case DRM_FORMAT_NV12:
-   case DRM_FORMAT_NV21:
-   *max_upscale = plane_cap->max_upscale_factor.nv12;
-   *min_downscale = plane_cap->max_downscale_factor.nv12;
-   break;
-
-   case DRM_FORMAT_XRGB16161616F:
-   case DRM_FORMAT_ARGB16161616F:
-   case DRM_FORMAT_XBGR16161616F:
-   case DRM_FORMAT_ABGR16161616F:
-   *max_upscale = plane_cap->max_upscale_factor.fp16;
-   *min_downscale = plane_cap->max_downscale_factor.fp16;
-   break;
-
-   default:
-   *max_upscale = plane_cap->max_upscale_factor.argb;
-   *min_downscale = plane_cap->max_downscale_factor.argb;
-   break;
-   }
-
-   /*
-* A factor of 1 in the plane_cap means to not allow scaling, ie. use a
-* scaling factor of 1.0 == 1000 units.
-   

Re: [PATCH] drm/amd/display: take dc_lock in short pulse handler only

[Kazlauskas, Nicholas]

On 2021-05-19 4:55 p.m., Aurabindo Pillai wrote:

[Why]
Conditions that end up modifying the global dc state must be locked.
However, during mst allocate payload sequence, lock is already taken.
With StarTech 1.2 DP hub, we get an HPD RX interrupt for a reason other
than to indicate down reply availability right after sending payload
allocation. The handler again takes dc lock before calling the
dc's HPD RX handler. Due to this contention, the DRM thread which waits
for MST down reply never gets a chance to finish its waiting
successfully and ends up timing out. Once the lock is released, the hpd
rx handler fires and goes ahead to read from the MST HUB, but now its
too late and the HUB doesnt lightup all displays since DRM lacks error
handling when payload allocation fails.

[How]
Take lock only if there is a change in link status or if automated test
pattern bit is set. The latter fixes the null pointer dereference when
running certain DP Link Layer Compliance test.

Signed-off-by: Aurabindo Pillai 


Discussed this a bit offline and I'd *really* like the proper interface 
in sooner rather than later.


Conditional locking is almost always a sign of a bug, in this case we 
know it's OK but someone can change the function underneath later 
without understanding that we're duplicating some of the checking logic 
in the upper layer.


I don't think the code changes enough in this area for this to happen 
(as it's spec based), but please be mindful and consider splitting the 
checking logic (which is thread safe) out with the link loss logic (the 
functional bit, that isn't thread safe).


Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +--
  .../gpu/drm/amd/display/dc/core/dc_link_dp.c  |  2 +-
  .../gpu/drm/amd/display/dc/inc/dc_link_dp.h   |  4 
  3 files changed, 22 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 e79910cc179c..2c9d099adfc2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -28,6 +28,7 @@
  
  #include "dm_services_types.h"

  #include "dc.h"
+#include "dc_link_dp.h"
  #include "dc/inc/core_types.h"
  #include "dal_asic_id.h"
  #include "dmub/dmub_srv.h"
@@ -2740,6 +2741,7 @@ static void handle_hpd_rx_irq(void *param)
enum dc_connection_type new_connection_type = dc_connection_none;
struct amdgpu_device *adev = drm_to_adev(dev);
union hpd_irq_data hpd_irq_data;
+   bool lock_flag = 0;
  
  	memset(&hpd_irq_data, 0, sizeof(hpd_irq_data));
  
@@ -2769,15 +2771,28 @@ static void handle_hpd_rx_irq(void *param)

}
}
  
-	if (!amdgpu_in_reset(adev)) {

+   /*
+* TODO: We need the lock to avoid touching DC state while it's being
+* modified during automated compliance testing, or when link loss
+* happens. While this should be split into subhandlers and proper
+* interfaces to avoid having to conditionally lock like this in the
+* outer layer, we need this workaround temporarily to allow MST
+* lightup in some scenarios to avoid timeout.
+*/
+   if (!amdgpu_in_reset(adev) &&
+   (hpd_rx_irq_check_link_loss_status(dc_link, &hpd_irq_data) ||
+hpd_irq_data.bytes.device_service_irq.bits.AUTOMATED_TEST)) {
mutex_lock(&adev->dm.dc_lock);
+   lock_flag = 1;
+   }
+
  #ifdef CONFIG_DRM_AMD_DC_HDCP
result = dc_link_handle_hpd_rx_irq(dc_link, &hpd_irq_data, NULL);
  #else
result = dc_link_handle_hpd_rx_irq(dc_link, NULL, NULL);
  #endif
+   if (!amdgpu_in_reset(adev) && lock_flag)
mutex_unlock(&adev->dm.dc_lock);
-   }
  
  out:

if (result && !is_mst_root_connector) {
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 9e08410bfdfd..32fb9cdbd980 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
@@ -2070,7 +2070,7 @@ enum dc_status read_hpd_rx_irq_data(
return retval;
  }
  
-static bool hpd_rx_irq_check_link_loss_status(

+bool hpd_rx_irq_check_link_loss_status(
struct dc_link *link,
union hpd_irq_data *hpd_irq_dpcd_data)
  {
diff --git a/drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h 
b/drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h
index ffc3f2c63db8..7dd8bca542b9 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h
@@ -68,6 +68,10 @@ bool perform_link_training_with_retries(
enum signal_type signal,
bool do_fallback);
  
+bool hpd_rx_irq_check_link_loss_status(

+   struct dc_link *link,
+   union hpd_irq_data *hpd_irq_dpcd_data);
+
  bool is_mst_supported(struct dc_link *link);
  

Re: [PATCH] drm/amdgpu/display: make backlight setting failure messages debug

[Kazlauskas, Nicholas]

On 2021-05-21 12:08 a.m., Alex Deucher wrote:

Avoid spamming the log.  The backlight controller on DCN chips
gets powered down when the display is off, so if you attempt to
set the backlight level when the display is off, you'll get this
message.  This isn't a problem as we cache the requested backlight
level if it's adjusted when the display is off and set it again
during modeset.

Signed-off-by: Alex Deucher 
Cc: nicholas.c...@amd.com
Cc: harry.wentl...@amd.com


Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
  1 file changed, 2 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 b8026c1baf36..c1f7456aeaa0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3506,7 +3506,7 @@ static int amdgpu_dm_backlight_set_level(struct 
amdgpu_display_manager *dm,
rc = dc_link_set_backlight_level_nits(link[i], true, 
brightness[i],
AUX_BL_DEFAULT_TRANSITION_TIME_MS);
if (!rc) {
-   DRM_ERROR("DM: Failed to update backlight via AUX on 
eDP[%d]\n", i);
+   DRM_DEBUG("DM: Failed to update backlight via AUX on 
eDP[%d]\n", i);
break;
}
}
@@ -3514,7 +3514,7 @@ static int amdgpu_dm_backlight_set_level(struct 
amdgpu_display_manager *dm,
for (i = 0; i < dm->num_of_edps; i++) {
rc = dc_link_set_backlight_level(dm->backlight_link[i], 
brightness[i], 0);
if (!rc) {
-   DRM_ERROR("DM: Failed to update backlight on 
eDP[%d]\n", i);
+   DRM_DEBUG("DM: Failed to update backlight on 
eDP[%d]\n", i);
break;
}
}



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

Re: [PATCH 2/2] drm/amdgpu/dc: fix DCN3.1 FP handling

[Kazlauskas, Nicholas]

On 2021-06-04 2:16 p.m., Alex Deucher wrote:

Missing proper DC_FP_START/DC_FP_END.

Signed-off-by: Alex Deucher 


Thanks for catching these.

Series is Reviewed-by: Nicholas Kazlauskas

Regards,
Nicholas Kazlauskas


---
  .../drm/amd/display/dc/dcn31/dcn31_resource.c  | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
index af978d2cb25f..0d6cb6caad81 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -1633,7 +1633,7 @@ static void dcn31_update_soc_for_wm_a(struct dc *dc, 
struct dc_state *context)
}
  }
  
-static void dcn31_calculate_wm_and_dlg(

+static void dcn31_calculate_wm_and_dlg_fp(
struct dc *dc, struct dc_state *context,
display_e2e_pipe_params_st *pipes,
int pipe_cnt,
@@ -1759,6 +1759,17 @@ static void dcn31_calculate_wm_and_dlg(
dcn20_calculate_dlg_params(dc, context, pipes, pipe_cnt, vlevel);
  }
  
+static void dcn31_calculate_wm_and_dlg(

+   struct dc *dc, struct dc_state *context,
+   display_e2e_pipe_params_st *pipes,
+   int pipe_cnt,
+   int vlevel)
+{
+   DC_FP_START();
+   dcn31_calculate_wm_and_dlg_fp(dc, context, pipes, pipe_cnt, vlevel);
+   DC_FP_END();
+}
+
  static struct dc_cap_funcs cap_funcs = {
.get_dcc_compression_cap = dcn20_get_dcc_compression_cap
  };
@@ -1890,6 +1901,8 @@ static bool dcn31_resource_construct(
struct dc_context *ctx = dc->ctx;
struct irq_service_init_data init_data;
  
+	DC_FP_START();

+
ctx->dc_bios->regs = &bios_regs;
  
  	pool->base.res_cap = &res_cap_dcn31;

@@ -2152,10 +2165,13 @@ static bool dcn31_resource_construct(
  
  	dc->cap_funcs = cap_funcs;
  
+	DC_FP_END();

+
return true;
  
  create_fail:
  
+	DC_FP_END();

dcn31_resource_destruct(pool);
  
  	return false;




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

Re: [PATCH] drm/amdgpu/display: use blanked rather than plane state for sync groups

[Kazlauskas, Nicholas]

On 2020-06-02 5:25 p.m., Alex Deucher wrote:

We may end up with no planes set yet, depending on the ordering, but we
should have the proper blanking state which is either handled by either
DPG or TG depending on the hardware generation.  Check both to determine
the proper blanked state.

Bug: https://gitlab.freedesktop.org/drm/amd/issues/781
Fixes: 5fc0cbfad45648 ("drm/amd/display: determine if a pipe is synced by plane 
state")
Cc: nicholas.kazlaus...@amd.com
Signed-off-by: Alex Deucher 


This looks good to me now from a conceptual level. I guess we'll find 
out later if it breaks anything.


Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/core/dc.c | 24 
  1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 04c3d9f7e323..7fdb6149047d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1017,9 +1017,17 @@ static void program_timing_sync(
}
}
  
-		/* set first pipe with plane as master */

+   /* set first unblanked pipe as master */
for (j = 0; j < group_size; j++) {
-   if (pipe_set[j]->plane_state) {
+   bool is_blanked;
+
+   if (pipe_set[j]->stream_res.opp->funcs->dpg_is_blanked)
+   is_blanked =
+   
pipe_set[j]->stream_res.opp->funcs->dpg_is_blanked(pipe_set[j]->stream_res.opp);
+   else
+   is_blanked =
+   
pipe_set[j]->stream_res.tg->funcs->is_blanked(pipe_set[j]->stream_res.tg);
+   if (!is_blanked) {
if (j == 0)
break;
  
@@ -1040,9 +1048,17 @@ static void program_timing_sync(

status->timing_sync_info.master = false;
  
  		}

-   /* remove any other pipes with plane as they have already been 
synced */
+   /* remove any other unblanked pipes as they have already been 
synced */
for (j = j + 1; j < group_size; j++) {
-   if (pipe_set[j]->plane_state) {
+   bool is_blanked;
+
+   if (pipe_set[j]->stream_res.opp->funcs->dpg_is_blanked)
+   is_blanked =
+   
pipe_set[j]->stream_res.opp->funcs->dpg_is_blanked(pipe_set[j]->stream_res.opp);
+   else
+   is_blanked =
+   
pipe_set[j]->stream_res.tg->funcs->is_blanked(pipe_set[j]->stream_res.tg);
+   if (!is_blanked) {
group_size--;
pipe_set[j] = pipe_set[group_size];
j--;



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

Re: [PATCH] drm/amdgpu/display: fix build without CONFIG_DRM_AMD_DC_DCN3_0

[Kazlauskas, Nicholas]

On 2020-06-03 2:00 p.m., Alex Deucher wrote:

Need to guard some new DCN3.0 stuff.

Signed-off-by: Alex Deucher 


Reviewed-by: Nicholas Kazlauskas 

Thanks!

Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
index 43d0b4e53b5d..2972392f9788 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
@@ -288,13 +288,16 @@ void optc1_program_timing(
if (optc1_is_two_pixels_per_containter(&patched_crtc_timing) || 
optc1->opp_count == 2)
h_div = H_TIMING_DIV_BY2;
  
+#if defined(CONFIG_DRM_AMD_DC_DCN3_0)

if (optc1->tg_mask->OTG_H_TIMING_DIV_MODE != 0) {
if (optc1->opp_count == 4)
h_div = H_TIMING_DIV_BY4;
  
  		REG_UPDATE(OTG_H_TIMING_CNTL,

OTG_H_TIMING_DIV_MODE, h_div);
-   } else {
+   } else
+#endif
+   {
REG_UPDATE(OTG_H_TIMING_CNTL,
OTG_H_TIMING_DIV_BY2, h_div);
}



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

Re: [PATCH 1/1] drm/amd/display: fix compilation error on allmodconfig

[Kazlauskas, Nicholas]

On 2020-06-19 11:27 a.m., Alex Deucher wrote:

On Thu, Jun 18, 2020 at 3:49 PM Qingqing Zhuo  wrote:


when compiled with allmodconfig option, there are error
messages as below:

ERROR: modpost:
"mod_color_is_table_init"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost:
"mod_color_get_table"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost:
"mod_color_set_table_init_state"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

To fix the issue, this commits removes
CONFIG_DRM_AMD_DC_DCN guard in color/makefile.

Signed-off-by: Qingqing Zhuo 
CC: Lewis Huang 
CC: Aric Cyr 
CC: Alexander Deucher 
CC: Harry Wentland 
CC: Nicholas Kazlauskas 
CC: Bhawanpreet Lakha 
CC: Stephen Rothwell 


Acked-by: Alex Deucher 


Reviewed-by: Nicholas Kazlauskas 




---
  drivers/gpu/drm/amd/display/modules/color/Makefile | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/modules/color/Makefile 
b/drivers/gpu/drm/amd/display/modules/color/Makefile
index 3ee7f27ff93b..e66c19a840c2 100644
--- a/drivers/gpu/drm/amd/display/modules/color/Makefile
+++ b/drivers/gpu/drm/amd/display/modules/color/Makefile
@@ -23,11 +23,7 @@
  # Makefile for the color sub-module of DAL.
  #

-MOD_COLOR = color_gamma.o
-
-ifdef CONFIG_DRM_AMD_DC_DCN
-MOD_COLOR += color_table.o
-endif
+MOD_COLOR = color_gamma.o color_table.o

  AMD_DAL_MOD_COLOR = $(addprefix $(AMDDALPATH)/modules/color/,$(MOD_COLOR))
  #$(info   DAL COLOR MODULE MAKEFILE )
--
2.17.1

___
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 04/11] drm/amd/display: Handle SMU msg response

[Kazlauskas, Nicholas]

On 2020-06-26 12:48 p.m., Alex Deucher wrote:

On Fri, Jun 26, 2020 at 12:19 PM Eryk Brol  wrote:


From: Yongqiang Sun 

[Why]
SMU may return error code to driver, but driver only check if response
is OK.

[How]
Check SMU response instead of reg_wait, assert in case of reponse isn't
OK.


Will you ever get concurrent calls to these interfaces or do you
already have a higher level lock to prevent that?  You need to make
sure you don't have multiple threads using these interfaces at the
same time or you'll need locking to protect the message, param, and
response registers.

Alex


IIRC this is a dedicated message port for DCN. I think DC locking 
prevents this from happening on the software side and HW/firmware has a 
different port.


Regards,
Nicholas Kazlauskas





Signed-off-by: Yongqiang Sun 
Reviewed-by: Tony Cheng 
Acked-by: Eryk Brol 
---
  .../dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c  | 39 +-
  .../dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c   | 40 ++-
  2 files changed, 75 insertions(+), 4 deletions(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c
index c320b7af7d34..dbc7cde00433 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c
@@ -26,6 +26,7 @@
  #include "core_types.h"
  #include "clk_mgr_internal.h"
  #include "reg_helper.h"
+#include 

  #define MAX_INSTANCE   5
  #define MAX_SEGMENT5
@@ -68,10 +69,42 @@ static const struct IP_BASE MP1_BASE  = { { { { 0x00016000, 
0, 0, 0, 0 } },
  #define VBIOSSMC_MSG_SetDispclkFreq   0x4
  #define VBIOSSMC_MSG_SetDprefclkFreq  0x5

+#define VBIOSSMC_Status_BUSY  0x0
+#define VBIOSSMC_Result_OK0x1
+#define VBIOSSMC_Result_Failed0xFF
+#define VBIOSSMC_Result_UnknownCmd0xFE
+#define VBIOSSMC_Result_CmdRejectedPrereq 0xFD
+#define VBIOSSMC_Result_CmdRejectedBusy   0xFC
+
+/*
+ * Function to be used instead of REG_WAIT macro because the wait ends when
+ * the register is NOT EQUAL to zero, and because the translation in msg_if.h
+ * won't work with REG_WAIT.
+ */
+static uint32_t rv1_smu_wait_for_response(struct clk_mgr_internal *clk_mgr, 
unsigned int delay_us, unsigned int max_retries)
+{
+   uint32_t res_val = VBIOSSMC_Status_BUSY;
+
+   do {
+   res_val = REG_READ(MP1_SMN_C2PMSG_91);
+   if (res_val != VBIOSSMC_Status_BUSY)
+   break;
+
+   if (delay_us >= 1000)
+   msleep(delay_us/1000);
+   else if (delay_us > 0)
+   udelay(delay_us);
+   } while (max_retries--);
+
+   return res_val;
+}
+
  int rv1_vbios_smu_send_msg_with_param(struct clk_mgr_internal *clk_mgr, 
unsigned int msg_id, unsigned int param)
  {
+   uint32_t result;
+
 /* First clear response register */
-   REG_WRITE(MP1_SMN_C2PMSG_91, 0);
+   REG_WRITE(MP1_SMN_C2PMSG_91, VBIOSSMC_Status_BUSY);

 /* Set the parameter register for the SMU message, unit is Mhz */
 REG_WRITE(MP1_SMN_C2PMSG_83, param);
@@ -79,7 +112,9 @@ int rv1_vbios_smu_send_msg_with_param(struct 
clk_mgr_internal *clk_mgr, unsigned
 /* Trigger the message transaction by writing the message ID */
 REG_WRITE(MP1_SMN_C2PMSG_67, msg_id);

-   REG_WAIT(MP1_SMN_C2PMSG_91, CONTENT, 1, 10, 20);
+   result = rv1_smu_wait_for_response(clk_mgr, 10, 1000);
+
+   ASSERT(result == VBIOSSMC_Result_OK);

 /* Actual dispclk set is returned in the parameter register */
 return REG_READ(MP1_SMN_C2PMSG_83);
diff --git 
a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
index 6878aedf1d3e..d2facbb114d3 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
@@ -26,6 +26,7 @@
  #include "core_types.h"
  #include "clk_mgr_internal.h"
  #include "reg_helper.h"
+#include 

  #include "renoir_ip_offset.h"

@@ -53,10 +54,43 @@
  #define VBIOSSMC_MSG_EnableTmdp48MHzRefclkPwrDown 0xD
  #define VBIOSSMC_MSG_UpdatePmeRestore0xE

+#define VBIOSSMC_Status_BUSY  0x0
+#define VBIOSSMC_Result_OK0x1
+#define VBIOSSMC_Result_Failed0xFF
+#define VBIOSSMC_Result_UnknownCmd0xFE
+#define VBIOSSMC_Result_CmdRejectedPrereq 0xFD
+#define VBIOSSMC_Result_CmdRejectedBusy   0xFC
+
+/*
+ * Function to be used instead of REG_WAIT macro because the wait ends when
+ * the register is NOT EQUAL to zero, and because the translation in msg_if.h
+ * won't work with REG_WAIT.
+ */
+static uint32_t rn_smu_wait_for_res

Re: [PATCH] Revert "drm/amd/display: Revalidate bandwidth before commiting DC updates"

[Kazlauskas, Nicholas]

On 2020-06-29 11:36 a.m., Alex Deucher wrote:

Seems to cause stability issues for some users.

This reverts commit a24eaa5c51255b344d5a321f1eeb3205f2775498.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191
Signed-off-by: Alex Deucher 


I don't see the error in their log. How do we know this commit is 
actually causing the issue?


I don't really want to revert this commit because it means that we 
missed rejecting a commit during atomic check, meaning we're either 
going to get underflow on the screen or a pipe hang.


Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/core/dc.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 67402d75e67e..94230bb3195d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2607,12 +2607,6 @@ 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,



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

Re: [PATCH] Revert "drm/amd/display: Revalidate bandwidth before commiting DC updates"

[Kazlauskas, Nicholas]

On 2020-06-29 11:40 a.m., Kazlauskas, Nicholas wrote:

On 2020-06-29 11:36 a.m., Alex Deucher wrote:

Seems to cause stability issues for some users.

This reverts commit a24eaa5c51255b344d5a321f1eeb3205f2775498.

Bug: 
https://gitlab.freedesktop.org/drm/amd/-/issues/1191 


Signed-off-by: Alex Deucher 


I don't see the error in their log. How do we know this commit is 
actually causing the issue?


I don't really want to revert this commit because it means that we 
missed rejecting a commit during atomic check, meaning we're either 
going to get underflow on the screen or a pipe hang.


Regards,
Nicholas Kazlauskas


Actually, we only want to be doing this on full updates - it's not a 
very fast operation. Not sure if this is causing their stability issue 
though.


Regards,
Nicholas Kazlauskas




---
  drivers/gpu/drm/amd/display/dc/core/dc.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c

index 67402d75e67e..94230bb3195d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2607,12 +2607,6 @@ 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,



___
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 dmcub check on RENOIR

[Kazlauskas, Nicholas]

Looks good to me.

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas

On 2020-07-08 10:15 a.m., Deucher, Alexander wrote:

[AMD Public Use]


[AMD Public Use]


Acked-by: Alex Deucher 

*From:* Aaron Ma 
*Sent:* Wednesday, July 8, 2020 4:16 AM
*To:* Wentland, Harry ; Li, Sun peng (Leo) 
; Deucher, Alexander ; 
Koenig, Christian ; airl...@linux.ie 
; dan...@ffwll.ch ; 
amd-gfx@lists.freedesktop.org ; 
dri-de...@lists.freedesktop.org ; 
linux-ker...@vger.kernel.org ; 
mapen...@gmail.com ; aaron...@canonical.com 


*Subject:* [PATCH] drm/amd/display: add dmcub check on RENOIR
RENOIR loads dmub fw not dmcu, check dmcu only will prevent loading iram,
it breaks backlight control.

Bug: 
https://bugzilla.kernel.org/show_bug.cgi?id=208277 


Signed-off-by: Aaron Ma 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

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 10ac8076d4f2..db5e0bb0d935 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1358,7 +1358,7 @@ static int dm_late_init(void *handle)
  struct dmcu *dmcu = NULL;
  bool ret;

-   if (!adev->dm.fw_dmcu)
+   if (!adev->dm.fw_dmcu && !adev->dm.dmub_fw)
  return detect_mst_link_for_all_connectors(adev->ddev);

  dmcu = adev->dm.dc->res_pool->dmcu;
--
2.25.1


___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [PATCH] drm/amdgpu/display: create fake mst encoders ahead of time (v2)

[Kazlauskas, Nicholas]

On 2020-07-10 9:58 a.m., Alex Deucher wrote:

Prevents a warning in the MST create connector case.

v2: create global fake encoders rather per connector fake encoders
to avoid running out of encoder indices.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1108
Fixes: c6385e503aeaf9 ("drm/amdgpu: drop legacy drm load and unload callbacks")
Signed-off-by: Alex Deucher 


I thought it was rather odd that the last patch was creating 6 per 
connector even though we were only using one.


Makes a lot more sense to be on the adev instead.

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 11 +++-
  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 53 +--
  .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |  3 ++
  4 files changed, 48 insertions(+), 28 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 0e5d99a85307..74d8e61f30e4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -978,6 +978,9 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
/* Update the actual used number of crtc */
adev->mode_info.num_crtc = adev->dm.display_indexes_num;
  
+	/* create fake encoders for MST */

+   dm_dp_create_fake_mst_encoders(adev);
+
/* TODO: Add_display_info? */
  
  	/* TODO use dynamic cursor width */

@@ -1001,6 +1004,12 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
  
  static void amdgpu_dm_fini(struct amdgpu_device *adev)

  {
+   int i;
+
+   for (i = 0; i < AMDGPU_DM_MAX_CRTC; i++) {
+   drm_encoder_cleanup(&adev->dm.mst_encoders[i].base);
+   }
+
amdgpu_dm_audio_fini(adev);
  
  	amdgpu_dm_destroy_drm_device(&adev->dm);

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 86c132ddc452..3f50328fe537 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -43,6 +43,9 @@
   */
  
  #define AMDGPU_DM_MAX_DISPLAY_INDEX 31

+
+#define AMDGPU_DM_MAX_CRTC 6
+
  /*
  #include "include/amdgpu_dal_power_if.h"
  #include "amdgpu_dm_irq.h"
@@ -330,6 +333,13 @@ struct amdgpu_display_manager {
 * available in FW
 */
const struct gpu_info_soc_bounding_box_v1_0 *soc_bounding_box;
+
+   /**
+* @mst_encoders:
+*
+* fake encoders used for DP MST.
+*/
+   struct amdgpu_encoder mst_encoders[AMDGPU_DM_MAX_CRTC];
  };
  
  struct amdgpu_dm_connector {

@@ -358,7 +368,6 @@ struct amdgpu_dm_connector {
struct amdgpu_dm_dp_aux dm_dp_aux;
struct drm_dp_mst_port *port;
struct amdgpu_dm_connector *mst_port;
-   struct amdgpu_encoder *mst_encoder;
struct drm_dp_aux *dsc_aux;
  
  	/* TODO see if we can merge with ddc_bus or make a dm_connector */

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index cf15248739f7..176973da18ef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -95,7 +95,6 @@ dm_dp_mst_connector_destroy(struct drm_connector *connector)
  {
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
-   struct amdgpu_encoder *amdgpu_encoder = aconnector->mst_encoder;
  
  	if (aconnector->dc_sink) {

dc_link_remove_remote_sink(aconnector->dc_link,
@@ -105,8 +104,6 @@ dm_dp_mst_connector_destroy(struct drm_connector *connector)
  
  	kfree(aconnector->edid);
  
-	drm_encoder_cleanup(&amdgpu_encoder->base);

-   kfree(amdgpu_encoder);
drm_connector_cleanup(connector);
drm_dp_mst_put_port_malloc(aconnector->port);
kfree(aconnector);
@@ -243,7 +240,11 @@ static struct drm_encoder *
  dm_mst_atomic_best_encoder(struct drm_connector *connector,
   struct drm_connector_state *connector_state)
  {
-   return &to_amdgpu_dm_connector(connector)->mst_encoder->base;
+   struct drm_device *dev = connector->dev;
+   struct amdgpu_device *adev = dev->dev_private;
+   struct amdgpu_crtc *acrtc = to_amdgpu_crtc(connector_state->crtc);
+
+   return &adev->dm.mst_encoders[acrtc->crtc_id].base;
  }
  
  static int

@@ -306,31 +307,27 @@ static const struct drm_encoder_funcs 
amdgpu_dm_encoder_funcs = {
.destroy = amdgpu_dm_encoder_destroy,
  };
  
-static struct amdgpu_encoder *

-dm_dp_create_fake_mst_encoder(struct amdgpu_dm_connector *connector)
+void
+dm_dp_create_fake_mst_encoders(struct amdgpu_device *adev)
  {
-   struct drm_device *dev = connector->base.dev;
-   struct amdgpu_device *adev = dev->dev_private;
-   

Re: [PATCH] drm/amdgpu/display: create fake mst encoders ahead of time (v4)

[Kazlauskas, Nicholas]

On 2020-07-10 11:50 a.m., Alex Deucher wrote:

Prevents a warning in the MST create connector case.

v2: create global fake encoders rather per connector fake encoders
to avoid running out of encoder indices.

v3: use the actual number of crtcs on the asic rather than the max
to conserve encoders.

v4: v3 plus missing hunk I forgot to git add.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1108
Fixes: c6385e503aeaf9 ("drm/amdgpu: drop legacy drm load and unload callbacks")
Signed-off-by: Alex Deucher 


This looks fine to me as well.

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 11 +++-
  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 53 +--
  .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |  3 ++
  4 files changed, 48 insertions(+), 28 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 0e5d99a85307..6f937e25a62c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -978,6 +978,9 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
/* Update the actual used number of crtc */
adev->mode_info.num_crtc = adev->dm.display_indexes_num;
  
+	/* create fake encoders for MST */

+   dm_dp_create_fake_mst_encoders(adev);
+
/* TODO: Add_display_info? */
  
  	/* TODO use dynamic cursor width */

@@ -1001,6 +1004,12 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
  
  static void amdgpu_dm_fini(struct amdgpu_device *adev)

  {
+   int i;
+
+   for (i = 0; i < adev->dm.display_indexes_num; i++) {
+   drm_encoder_cleanup(&adev->dm.mst_encoders[i].base);
+   }
+
amdgpu_dm_audio_fini(adev);
  
  	amdgpu_dm_destroy_drm_device(&adev->dm);

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 86c132ddc452..3f50328fe537 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -43,6 +43,9 @@
   */
  
  #define AMDGPU_DM_MAX_DISPLAY_INDEX 31

+
+#define AMDGPU_DM_MAX_CRTC 6
+
  /*
  #include "include/amdgpu_dal_power_if.h"
  #include "amdgpu_dm_irq.h"
@@ -330,6 +333,13 @@ struct amdgpu_display_manager {
 * available in FW
 */
const struct gpu_info_soc_bounding_box_v1_0 *soc_bounding_box;
+
+   /**
+* @mst_encoders:
+*
+* fake encoders used for DP MST.
+*/
+   struct amdgpu_encoder mst_encoders[AMDGPU_DM_MAX_CRTC];
  };
  
  struct amdgpu_dm_connector {

@@ -358,7 +368,6 @@ struct amdgpu_dm_connector {
struct amdgpu_dm_dp_aux dm_dp_aux;
struct drm_dp_mst_port *port;
struct amdgpu_dm_connector *mst_port;
-   struct amdgpu_encoder *mst_encoder;
struct drm_dp_aux *dsc_aux;
  
  	/* TODO see if we can merge with ddc_bus or make a dm_connector */

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index cf15248739f7..0affd1997fe7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -95,7 +95,6 @@ dm_dp_mst_connector_destroy(struct drm_connector *connector)
  {
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
-   struct amdgpu_encoder *amdgpu_encoder = aconnector->mst_encoder;
  
  	if (aconnector->dc_sink) {

dc_link_remove_remote_sink(aconnector->dc_link,
@@ -105,8 +104,6 @@ dm_dp_mst_connector_destroy(struct drm_connector *connector)
  
  	kfree(aconnector->edid);
  
-	drm_encoder_cleanup(&amdgpu_encoder->base);

-   kfree(amdgpu_encoder);
drm_connector_cleanup(connector);
drm_dp_mst_put_port_malloc(aconnector->port);
kfree(aconnector);
@@ -243,7 +240,11 @@ static struct drm_encoder *
  dm_mst_atomic_best_encoder(struct drm_connector *connector,
   struct drm_connector_state *connector_state)
  {
-   return &to_amdgpu_dm_connector(connector)->mst_encoder->base;
+   struct drm_device *dev = connector->dev;
+   struct amdgpu_device *adev = dev->dev_private;
+   struct amdgpu_crtc *acrtc = to_amdgpu_crtc(connector_state->crtc);
+
+   return &adev->dm.mst_encoders[acrtc->crtc_id].base;
  }
  
  static int

@@ -306,31 +307,27 @@ static const struct drm_encoder_funcs 
amdgpu_dm_encoder_funcs = {
.destroy = amdgpu_dm_encoder_destroy,
  };
  
-static struct amdgpu_encoder *

-dm_dp_create_fake_mst_encoder(struct amdgpu_dm_connector *connector)
+void
+dm_dp_create_fake_mst_encoders(struct amdgpu_device *adev)
  {
-   struct drm_device *dev = connector->base.dev;
-   struct amdgpu_device *adev = dev->dev_priv

Re: [PATCH] drm/amd/display: Explicitly set stack size to 4

[Kazlauskas, Nicholas]

On 2020-07-21 11:38 a.m., Kent Russell wrote:

In certain kernels using GCC 8.2, we get compilation errors saying:
-mpreferred-stack-boundary=3 is not between 4 and 12
Explicitly set -mpreferred-stack-boundary=4 in the Display Makefiles,
even when SSE2 is enabled

Change-Id: Ic7c4637e2e521af2d0444d3b5886f710131c80ca
Signed-off-by: Kent Russell 


Seems reasonable to me. I'd imagine we want this anyway since SIMD 
generally wants to be 16-byte aligned anyway and this code has FP in it.


Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 
  drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 8 
  drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 8 
  drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 8 
  drivers/gpu/drm/amd/display/dc/dml/Makefile   | 9 +
  drivers/gpu/drm/amd/display/dc/dsc/Makefile   | 8 
  6 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
index 4674aca8f206..5c519cec9039 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@ -26,7 +26,9 @@
  #
  
  ifdef CONFIG_X86

-calcs_ccflags := -mhard-float -msse
+# Certain kernels don't compile with -mpreferred-stack-boundary=3, so 
explicitly set it
+# to 4, even if we enable SSE2
+calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
  endif
  
  ifdef CONFIG_PPC64

@@ -40,12 +42,10 @@ endif
  endif
  
  ifdef CONFIG_X86

-ifdef IS_OLD_GCC
+ifndef IS_OLD_GCC
  # Stack alignment mismatch, proceed with caution.
  # GCC < 7.1 cannot compile code using `double` and 
-mpreferred-stack-boundary=3
  # (8B stack alignment).
-calcs_ccflags += -mpreferred-stack-boundary=4
-else
  calcs_ccflags += -msse2
  endif
  endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
index 5fcaf78334ff..78d3e0563a4c 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
@@ -10,7 +10,9 @@ DCN20 = dcn20_resource.o dcn20_init.o dcn20_hwseq.o 
dcn20_dpp.o dcn20_dpp_cm.o d
  DCN20 += dcn20_dsc.o
  
  ifdef CONFIG_X86

-CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o := -mhard-float -msse
+# Certain kernels don't compile with -mpreferred-stack-boundary=3, so 
explicitly set it
+# to 4, even if we enable SSE2
+CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
  endif
  
  ifdef CONFIG_PPC64

@@ -24,12 +26,10 @@ endif
  endif
  
  ifdef CONFIG_X86

-ifdef IS_OLD_GCC
+ifndef IS_OLD_GCC
  # Stack alignment mismatch, proceed with caution.
  # GCC < 7.1 cannot compile code using `double` and 
-mpreferred-stack-boundary=3
  # (8B stack alignment).
-CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o += -mpreferred-stack-boundary=4
-else
  CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o += -msse2
  endif
  endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
index 07684d3e375a..6183e8f141bb 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
@@ -6,7 +6,9 @@ DCN21 = dcn21_init.o dcn21_hubp.o dcn21_hubbub.o 
dcn21_resource.o \
 dcn21_hwseq.o dcn21_link_encoder.o
  
  ifdef CONFIG_X86

-CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse
+# Certain kernels don't compile with -mpreferred-stack-boundary=3, so 
explicitly set it
+# to 4, even if we enable SSE2
+CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
  endif
  
  ifdef CONFIG_PPC64

@@ -20,12 +22,10 @@ endif
  endif
  
  ifdef CONFIG_X86

-ifdef IS_OLD_GCC
+ifndef IS_OLD_GCC
  # Stack alignment mismatch, proceed with caution.
  # GCC < 7.1 cannot compile code using `double` and 
-mpreferred-stack-boundary=3
  # (8B stack alignment).
-CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o += -mpreferred-stack-boundary=4
-else
  CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o += -msse2
  endif
  endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
index 025637a83c3b..0d803486e051 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
@@ -33,19 +33,19 @@ DCN30 = dcn30_init.o dcn30_hubbub.o dcn30_hubp.o 
dcn30_dpp.o dcn30_optc.o \
  
  CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -mhard-float -msse -mpreferred-stack-boundary=4
  
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -mhard-float -msse

+# Certain kernels don't compile with -mpreferred-stack-boundary=3, so 
explicitly set it
+# to 4, even if we enable SSE2
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
  ifdef CONFIG_CC_IS_GCC
  ifeq ($(call cc-ifversion, -lt, 0701, y), y)
  IS_OLD_G

Re: [PATCH] drm/amd/display: Explicitly set stack size to 4

[Kazlauskas, Nicholas]

On 2020-07-21 12:03 p.m., Felix Kuehling wrote:

Am 2020-07-21 um 11:38 a.m. schrieb Kent Russell:

In certain kernels using GCC 8.2, we get compilation errors saying:
-mpreferred-stack-boundary=3 is not between 4 and 12
Explicitly set -mpreferred-stack-boundary=4 in the Display Makefiles,
even when SSE2 is enabled


As I understand it, -mpreferred-stack-boundary does not affect the stack
size, but the alignment of the stack frame.

The GCC manpage explains that mixing different stack boundary settings
can lead to errors when functions compiled with stack-boundary=3 call
functions with stack-boundary=4. That sounds like setting a different
stack boundary explicitly in only some parts of the code is probably a
bad idea.

Quote from the gcc mangage:


    Warning: When generating code for the x86-64 architecture
with SSE
    extensions disabled, -mpreferred-stack-boundary=3 can be
used to
    keep the stack boundary aligned to 8 byte boundary.  Since
x86-64
    ABI require 16 byte stack alignment, this is ABI
incompatible and
    intended to be used in controlled environment where stack
space is
    important limitation.  This option leads to wrong code when
    functions compiled with 16 byte stack alignment (such as
functions
    from a standard library) are called with misaligned stack.
In this
    case, SSE instructions may lead to misaligned memory access
traps.
    In addition, variable arguments are handled incorrectly for
16 byte
    aligned objects (including x87 long double and __int128),
leading
    to wrong results.  You must build all modules with
    -mpreferred-stack-boundary=3, including any libraries.  This
    includes the system libraries and startup modules.


Regards,
   Felix


Oh right, I remember that this issue was brought up before.

https://github.com/ClangBuiltLinux/linux/issues/735

I don't think we want to be mixing alignment then. Maybe let's hold off 
on this change for now and figure out if we still need this flag set at 
all for GCC 8.2 onward.


like

#ifndef GCC82
ccflags += -mpreferred-stack-boundary=3
#endif

Regards,
Nicholas Kazlauskas






Change-Id: Ic7c4637e2e521af2d0444d3b5886f710131c80ca
Signed-off-by: Kent Russell 
---
  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 
  drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 8 
  drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 8 
  drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 8 
  drivers/gpu/drm/amd/display/dc/dml/Makefile   | 9 +
  drivers/gpu/drm/amd/display/dc/dsc/Makefile   | 8 
  6 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
index 4674aca8f206..5c519cec9039 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@ -26,7 +26,9 @@
  #
  
  ifdef CONFIG_X86

-calcs_ccflags := -mhard-float -msse
+# Certain kernels don't compile with -mpreferred-stack-boundary=3, so 
explicitly set it
+# to 4, even if we enable SSE2
+calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
  endif
  
  ifdef CONFIG_PPC64

@@ -40,12 +42,10 @@ endif
  endif
  
  ifdef CONFIG_X86

-ifdef IS_OLD_GCC
+ifndef IS_OLD_GCC
  # Stack alignment mismatch, proceed with caution.
  # GCC < 7.1 cannot compile code using `double` and 
-mpreferred-stack-boundary=3
  # (8B stack alignment).
-calcs_ccflags += -mpreferred-stack-boundary=4
-else
  calcs_ccflags += -msse2
  endif
  endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
index 5fcaf78334ff..78d3e0563a4c 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
@@ -10,7 +10,9 @@ DCN20 = dcn20_resource.o dcn20_init.o dcn20_hwseq.o 
dcn20_dpp.o dcn20_dpp_cm.o d
  DCN20 += dcn20_dsc.o
  
  ifdef CONFIG_X86

-CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o := -mhard-float -msse
+# Certain kernels don't compile with -mpreferred-stack-boundary=3, so 
explicitly set it
+# to 4, even if we enable SSE2
+CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
  endif
  
  ifdef CONFIG_PPC64

@@ -24,12 +26,10 @@ endif
  endif
  
  ifdef CONFIG_X86

-ifdef IS_OLD_GCC
+ifndef IS_OLD_GCC
  # Stack alignment mismatch, proceed with caution.
  # GCC < 7.1 cannot compile code using `double` and 
-mpreferred-stack-boundary=3
  # (8B stack alignment).
-CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o += -mpreferred-stack-boundary=4
-else
  CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o += -msse2
  endif
  endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
index 07684d3e375a..6183e8f141bb 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
+++ b/drivers/gpu/d

Re: [PATCH] drm/amdgpu/dc: Simplify drm_crtc_state::active checks

[Kazlauskas, Nicholas]

On 2020-07-22 8:51 a.m., Daniel Vetter wrote:

On Wed, Jul 22, 2020 at 2:38 PM Michel Dänzer  wrote:


From: Michel Dänzer 

drm_atomic_crtc_check enforces that ::active can only be true if
::enable is as well.

Signed-off-by: Michel Dänzer 


Looks fine to me. The check is sufficiently old enough that I don't mind 
relying on the core for this either.


Reviewed-by: Nicholas Kazlauskas 



modeset vs modereset is a bit an inglorious name choice ... since this
seems to be glue code and not part of core dc, maybe rename to
enable_required/disable_required to keep it consistent with the
wording atomic helpers use? DC also seems to use reset for a lot of
other things already (state reset, like atomic, or gpu reset like
drm/scheduler's td_r_), so I think this would also help clarity from a
DC perspective.

Patch itself is good, above just an idea for another patch on top.

Reviewed-by: Daniel Vetter 


That sounds like a reasonable idea to me. These are used more as a 
stream_changed / stream_removed flag, but I don't think these helpers 
really need to exist at all.


That could come as a follow up patch.

Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16 +++-
  1 file changed, 3 insertions(+), 13 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 312c543b258f..dabef307a74f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3415,21 +3415,12 @@ static bool modeset_required(struct drm_crtc_state 
*crtc_state,
  struct dc_stream_state *new_stream,
  struct dc_stream_state *old_stream)
  {
-   if (!drm_atomic_crtc_needs_modeset(crtc_state))
-   return false;
-
-   if (!crtc_state->enable)
-   return false;
-
-   return crtc_state->active;
+   return crtc_state->active && drm_atomic_crtc_needs_modeset(crtc_state);
  }

  static bool modereset_required(struct drm_crtc_state *crtc_state)
  {
-   if (!drm_atomic_crtc_needs_modeset(crtc_state))
-   return false;
-
-   return !crtc_state->enable || !crtc_state->active;
+   return !crtc_state->active && drm_atomic_crtc_needs_modeset(crtc_state);
  }

  static void amdgpu_dm_encoder_destroy(struct drm_encoder *encoder)
@@ -8108,8 +8099,7 @@ static int dm_update_crtc_state(struct 
amdgpu_display_manager *dm,
  * We want to do dc stream updates that do not require a
  * full modeset below.
  */
-   if (!(enable && aconnector && new_crtc_state->enable &&
- new_crtc_state->active))
+   if (!(enable && aconnector && new_crtc_state->active))
 return 0;
 /*
  * Given above conditions, the dc state cannot be NULL because:
--
2.28.0.rc0

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel






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

Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free

[Kazlauskas, Nicholas]

On 2020-07-23 5:10 p.m., Mazin Rezk wrote:

When amdgpu_dm_atomic_commit_tail is running in the workqueue,
drm_atomic_state_put will get called while amdgpu_dm_atomic_commit_tail is
running, causing a race condition where state (and then dm_state) is
sometimes freed while amdgpu_dm_atomic_commit_tail is running. This bug has
occurred since 5.7-rc1 and is well documented among polaris11 users [1].

Prior to 5.7, this was not a noticeable issue since the freelist pointer
was stored at the beginning of dm_state (base), which was unused. After
changing the freelist pointer to be stored in the middle of the struct, the
freelist pointer overwrote the context, causing dc_state to become garbage
data and made the call to dm_enable_per_frame_crtc_master_sync dereference
a freelist pointer.

This patch fixes the aforementioned issue by calling drm_atomic_state_get
in amdgpu_dm_atomic_commit before drm_atomic_helper_commit is called and
drm_atomic_state_put after amdgpu_dm_atomic_commit_tail is complete.

According to my testing on 5.8.0-rc6, this should fix bug 207383 on
Bugzilla [1].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=207383

Fixes: 3202fa62f ("slub: relocate freelist pointer to middle of object")
Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk 


Thanks for the investigation and your patch. I appreciate the help in 
trying to narrow down the root cause as this issue has been difficult to 
reproduce on my setups.


Though I'm not sure this really resolves the issue - we make use of the 
drm_atomic_helper_commit helper function from DRM which internally does 
what you're doing with this patch:


drm_atomic_state_get(state);
if (nonblock)
queue_work(system_unbound_wq, &state->commit_work);
else
commit_tail(state);

So even when it gets queued off to the unbound workqueue we still have a 
reference on the state.


That reference gets dropped as part of commit tail helper in DRM as well:

if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
drm_atomic_helper_commit_tail(old_state);

commit_time_ms = ktime_ms_delta(ktime_get(), start);
if (commit_time_ms > 0)
drm_self_refresh_helper_update_avg_times(old_state,
 (unsigned long)commit_time_ms,
 new_self_refresh_mask);

drm_atomic_helper_commit_cleanup_done(old_state);

drm_atomic_state_put(old_state);

So instead of a use after free happening when we access the state we get 
a double-free happening later at the end of commit tail in DRM.


What I think would be the right next step here is to actually determine 
what sequence of IOCTLs and atomic commits are happening under your 
setup with a very verbose dmesg log. You can set a debug level for DRM 
in your kernel parameters with something like:


drm.debug=0x54

I don't see anything in amdgpu_dm.c that looks like it would be freeing 
the state so I suspect something in the core is this doing this.



---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
  1 file changed, 3 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 86ffa0c2880f..86d6652872f2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7303,6 +7303,7 @@ static int amdgpu_dm_atomic_commit(struct drm_device *dev,
 * unset legacy_cursor_update
 */

+   drm_atomic_state_get(state);


Also note that if the drm_atomic_helper_commit() call fails here then 
we're going to never free this structure. So we should really be 
checking the return code here below before trying to do this, if at all.


Regards,
Nicholas Kazlauskas


return drm_atomic_helper_commit(dev, state, nonblock);

/*TODO Handle EINTR, reenable IRQ*/
@@ -7628,6 +7629,8 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)

if (dc_state_temp)
dc_release_state(dc_state_temp);
+
+   drm_atomic_state_put(state);
  }


--
2.27.0



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

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

[Kazlauskas, Nicholas]

On 2020-07-27 1:40 a.m., Mazin Rezk wrote:

This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
are requested and the second one finishes before the first. Essentially,
this bug occurs when the following sequence of events happens:

1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.

2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.

3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.

4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.

Since this bug has only been spotted with fast commits, this patch fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found,
removing the dm_state should not have any consequences in fast updates.

This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for fast 
updates")
Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
  1 file changed, 27 insertions(+), 9 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 86ffa0c2880f..710edc70e37e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8717,20 +8717,38 @@ static int amdgpu_dm_atomic_check(struct drm_device 
*dev,
 * the same resource. If we have a new DC context as part of
 * the DM atomic state from validation we need to free it and
 * retain the existing one instead.
+*
+* Furthermore, since the DM atomic state only contains the DC
+* context and can safely be annulled, we can free the state
+* and clear the associated private object now to free
+* some memory and avoid a possible use-after-free later.
 */
-   struct dm_atomic_state *new_dm_state, *old_dm_state;

-   new_dm_state = dm_atomic_get_new_state(state);
-   old_dm_state = dm_atomic_get_old_state(state);
+   for (i = 0; i < state->num_private_objs; i++) {
+   struct drm_private_obj *obj = 
state->private_objs[i].ptr;

-   if (new_dm_state && old_dm_state) {
-   if (new_dm_state->context)
-   dc_release_state(new_dm_state->context);
+   if (obj->funcs == adev->dm.atomic_obj.funcs) {
+   int j = state->num_private_objs-1;

-   new_dm_state->context = old_dm_state->context;
+   dm_atomic_destroy_state(obj,
+   state->private_objs[i].state);
+
+   /* If i is not at the end of the array then the
+* last element needs to be moved to where i was
+* before the array can safely be truncated.
+*/
+   if (i != j)
+   state->private_objs[i] =
+   state->private_objs[j];

-   if (old_dm_state->context)
-   dc_retain_state(old_dm_state->context);
+   state->private_objs[j].ptr = NULL;
+   state->private_objs[j].state = NULL;
+   state->private_objs[j].old_state = NULL;
+   state->private_objs[j].new_state = NULL;
+
+   state->num_private_objs = j;
+   break;
+   }


In the bug report itself I mentioned that I don't really like hacking 
around the DRM core for resolving this patch but to go into more 
specifics, it's really two issues of code maintenance:


1. It's iterating over internal structures and layout of private objects 
in the state and modifying the state. The core doesn't really guarantee 
how these things are going to be laid out and it may change in the future.


2. It's freeing an allocation we don

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

[Kazlauskas, Nicholas]

On 2020-07-27 9:39 a.m., Christian König wrote:

Am 27.07.20 um 07:40 schrieb Mazin Rezk:

This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
are requested and the second one finishes before the first. Essentially,
this bug occurs when the following sequence of events happens:

1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.

2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.

3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.

4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.


Well I only have a one mile high view on this, but why don't you let the 
work items execute in order?


That would be better anyway cause this way we don't trigger a cache line 
ping pong between CPUs.


Christian.


We use the DRM helpers for managing drm_atomic_commit_state and those 
helpers internally push non-blocking commit work into the system unbound 
work queue.


While we could duplicate a copy of that code with nothing but the 
workqueue changed that isn't something I'd really like to maintain going 
forward.


Regards,
Nicholas Kazlauskas





Since this bug has only been spotted with fast commits, this patch fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is 
found,

removing the dm_state should not have any consequences in fast updates.

This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).

Bugzilla: 
https://bugzilla.kernel.org/show_bug.cgi?id=207383 

Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for 
fast updates")

Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
  1 file changed, 27 insertions(+), 9 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 86ffa0c2880f..710edc70e37e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8717,20 +8717,38 @@ static int amdgpu_dm_atomic_check(struct 
drm_device *dev,

   * the same resource. If we have a new DC context as part of
   * the DM atomic state from validation we need to free it and
   * retain the existing one instead.
+ *
+ * Furthermore, since the DM atomic state only contains the DC
+ * context and can safely be annulled, we can free the state
+ * and clear the associated private object now to free
+ * some memory and avoid a possible use-after-free later.
   */
-    struct dm_atomic_state *new_dm_state, *old_dm_state;

-    new_dm_state = dm_atomic_get_new_state(state);
-    old_dm_state = dm_atomic_get_old_state(state);
+    for (i = 0; i < state->num_private_objs; i++) {
+    struct drm_private_obj *obj = state->private_objs[i].ptr;

-    if (new_dm_state && old_dm_state) {
-    if (new_dm_state->context)
-    dc_release_state(new_dm_state->context);
+    if (obj->funcs == adev->dm.atomic_obj.funcs) {
+    int j = state->num_private_objs-1;

-    new_dm_state->context = old_dm_state->context;
+    dm_atomic_destroy_state(obj,
+    state->private_objs[i].state);
+
+    /* If i is not at the end of the array then the
+ * last element needs to be moved to where i was
+ * before the array can safely be truncated.
+ */
+    if (i != j)
+    state->private_objs[i] =
+    state->private_objs[j];

-    if (old_dm_state->context)
-    dc_retain_state(old_dm_state->context);
+    state->private_objs[j].ptr = NULL;
+    state->private_objs[j].state = NULL;
+    state->private_objs[j].old_state = NULL;
+    state->private_objs[j].new_state = NULL;
+
+    state->num_private_objs = j;
+    break;
+    }
  }
  }

--
2.27.0





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

Re: [PATCH] drm/amd/display: Use proper abm/backlight functions for DCN3

[Kazlauskas, Nicholas]

On 2020-07-27 11:23 a.m., Alex Deucher wrote:

On Mon, Jul 27, 2020 at 11:22 AM Bhawanpreet Lakha
 wrote:


Use DCN21 functions instead of DCE110

Signed-off-by: Bhawanpreet Lakha 


Acked-by: Alex Deucher 


Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas




---
  drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c 
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c
index 1b354c219d0a..9afee7160490 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c
@@ -26,6 +26,7 @@
  #include "dce110/dce110_hw_sequencer.h"
  #include "dcn10/dcn10_hw_sequencer.h"
  #include "dcn20/dcn20_hwseq.h"
+#include "dcn21/dcn21_hwseq.h"
  #include "dcn30_hwseq.h"

  static const struct hw_sequencer_funcs dcn30_funcs = {
@@ -87,8 +88,8 @@ static const struct hw_sequencer_funcs dcn30_funcs = {
 .set_flip_control_gsl = dcn20_set_flip_control_gsl,
 .get_vupdate_offset_from_vsync = dcn10_get_vupdate_offset_from_vsync,
 .apply_idle_power_optimizations = dcn30_apply_idle_power_optimizations,
-   .set_backlight_level = dce110_set_backlight_level,
-   .set_abm_immediate_disable = dce110_set_abm_immediate_disable,
+   .set_backlight_level = dcn21_set_backlight_level,
+   .set_abm_immediate_disable = dcn21_set_abm_immediate_disable,
  };

  static const struct hwseq_private_funcs dcn30_private_funcs = {
--
2.17.1

___
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: Clear dm_state for fast updates

[Kazlauskas, Nicholas]

On 2020-07-27 5:32 p.m., Daniel Vetter wrote:

On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk  wrote:


On Monday, July 27, 2020 4:29 PM, Daniel Vetter  wrote:


On Mon, Jul 27, 2020 at 9:28 PM Christian König
 wrote:


Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas:

On 2020-07-27 9:39 a.m., Christian König wrote:

Am 27.07.20 um 07:40 schrieb Mazin Rezk:

This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking
commits
are requested and the second one finishes before the first.
Essentially,
this bug occurs when the following sequence of events happens:

1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.

2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.

3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.

4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.


Well I only have a one mile high view on this, but why don't you let
the work items execute in order?

That would be better anyway cause this way we don't trigger a cache
line ping pong between CPUs.

Christian.


We use the DRM helpers for managing drm_atomic_commit_state and those
helpers internally push non-blocking commit work into the system
unbound work queue.


Mhm, well if you send those helper atomic commits in the order A,B and
they execute it in the order B,A I would call that a bug :)


The way it works is it pushes all commits into unbound work queue, but
then forces serialization as needed. We do _not_ want e.g. updates on
different CRTC to be serialized, that would result in lots of judder.
And hw is funny enough that there's all kinds of dependencies.

The way you force synchronization is by adding other CRTC state
objects. So if DC is busted and can only handle a single update per
work item, then I guess you always need all CRTC states and everything
will be run in order. But that also totally kills modern multi-screen
compositors. Xorg isn't modern, just in case that's not clear :-)

Lucking at the code it seems like you indeed have only a single dm
state, so yeah global sync is what you'll need as immediate fix, and
then maybe fix up DM to not be quite so silly ... or at least only do
the dm state stuff when really needed.

We could also sprinkle the drm_crtc_commit structure around a bit
(it's the glue that provides the synchronization across commits), but
since your dm state is global just grabbing all crtc states
unconditionally as part of that is probably best.


While we could duplicate a copy of that code with nothing but the
workqueue changed that isn't something I'd really like to maintain
going forward.


I'm not talking about duplicating the code, I'm talking about fixing the
helpers. I don't know that code well, but from the outside it sounds
like a bug there.

And executing work items in the order they are submitted is trivial.

Had anybody pinged Daniel or other people familiar with the helper code
about it?


Yeah something is wrong here, and the fix looks horrible :-)

Aside, I've also seen some recent discussion flare up about
drm_atomic_state_get/put used to paper over some other use-after-free,
but this time related to interrupt handlers. Maybe a few rules about
that:
- dont
- especially not when it's interrupt handlers, because you can't call
drm_atomic_state_put from interrupt handlers.

Instead have an spin_lock_irq to protect the shared date with your
interrupt handler, and _copy_ the date over. This is e.g. what
drm_crtc_arm_vblank_event does.


Nicholas wrote a patch that attempted to resolve the issue by adding every
CRTC into the commit to use use the stall checks. [1] While this forces
synchronisation on commits, it's kind of a hacky method that may take a
toll on performance.

Is it possible to have a DRM helper that forces synchronisation on some
commits without having to add every CRTC into the commit?

Also, is synchronisation really necessary for fast updates in amdgpu?
I'll admit, the idea of eliminating the use-after-free bug by eliminating
the use entirely doesn't seem ideal; but is forcing synchronisation on
these updates that much better?


Well clearing the dc_state pointer here and then allocating another
one in atomic_commit_tail also looks fishy. The proper fix is probably
a lot more involved, but yeah interim fix is to grab all crtc states
iff you also grabbed the dm_atomic_state structure. Real fix is to
only do this when necessary, which pretty much means the dc_state
needs to be somehow split up, or there needs to be some guarantees
about when it's necessary and when not. Otherwise parallel commits on
different CRTC are not possible with the current dc backend code.


Thanks 

Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free

[Kazlauskas, Nicholas]

On 2020-07-28 5:22 a.m., Paul Menzel wrote:

Dear Linux folks,


Am 25.07.20 um 07:20 schrieb Mazin Rezk:

On Saturday, July 25, 2020 12:59 AM, Duncan wrote:


On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote:


Am 24.07.20 um 19:33 schrieb Kees Cook:


There was a fix to disable the async path for this driver that
worked around the bug too, yes? That seems like a safer and more
focused change that doesn't revert the SLUB defense for all
users, and would actually provide a complete, I think, workaround


That said, I haven't seen the async disabling patch. If you could
link to it, I'd be glad to test it out and perhaps we can use that
instead.


I'm confused. Not to put words in Kees' mouth; /I/ am confused (which
admittedly could well be just because I make no claims to be a
coder and am simply reading the bug and thread, but I'd appreciate some
"unconfusing" anyway).

My interpretation of the "async disabling" reference was that it was to
comment #30 on the bug:

https://bugzilla.kernel.org/show_bug.cgi?id=207383#c30 



... which (if I'm not confused on this point too) appears to be yours.
There it was stated...

I've also found that this bug exclusively occurs when commit_work is on
the workqueue. After forcing drm_atomic_helper_commit to run all of the
commits without adding to the workqueue and running the OS, the issue
seems to have disappeared.


Would not forcing all commits to run directly, without placing them on
the workqueue, be "async disabling"? That's what I /thought/ he was
referencing.


Oh, I thought he was referring to a different patch. Kees, could I get
your confirmation on this?

The change I made actually affected all of the DRM code, although this 
could

easily be changed to be specific to amdgpu. (By forcing blocking on
amdgpu_dm's non-blocking commit code)

That said, I'd still need to test further because I only did test it 
for a

couple of hours then. Although it should work in theory.


OTOH your base/context swap idea sounds like a possibly "less
disturbance" workaround, if it works, and given the point in the
commit cycle... (But if it's out Sunday it's likely too late to test
and get it in now anyway; if it's another week, tho...)


The base/context swap idea should make the use-after-free behave how it
did in 5.6. Since the bug doesn't cause an issue in 5.6, it's less of a
"less disturbance" workaround and more of a "no disturbance" workaround.


Sorry for bothering, but is there now a solution, besides reverting the 
commits, to avoid freezes/crashes *without* performance regressions?



Kind regards,

Paul


Mazin's "drm/amd/display: Clear dm_state for fast updates" change 
accomplishes this, at least as a temporary hack.


I've started work on a more large scale fix that we could get in in after.

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

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

[Kazlauskas, Nicholas]

On 2020-07-28 5:08 a.m., dan...@ffwll.ch wrote:

On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote:

On 2020-07-27 5:32 p.m., Daniel Vetter wrote:

On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk  wrote:


On Monday, July 27, 2020 4:29 PM, Daniel Vetter  wrote:


On Mon, Jul 27, 2020 at 9:28 PM Christian König
 wrote:


Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas:

On 2020-07-27 9:39 a.m., Christian König wrote:

Am 27.07.20 um 07:40 schrieb Mazin Rezk:

This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking
commits
are requested and the second one finishes before the first.
Essentially,
this bug occurs when the following sequence of events happens:

1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.

2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.

3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.

4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.


Well I only have a one mile high view on this, but why don't you let
the work items execute in order?

That would be better anyway cause this way we don't trigger a cache
line ping pong between CPUs.

Christian.


We use the DRM helpers for managing drm_atomic_commit_state and those
helpers internally push non-blocking commit work into the system
unbound work queue.


Mhm, well if you send those helper atomic commits in the order A,B and
they execute it in the order B,A I would call that a bug :)


The way it works is it pushes all commits into unbound work queue, but
then forces serialization as needed. We do _not_ want e.g. updates on
different CRTC to be serialized, that would result in lots of judder.
And hw is funny enough that there's all kinds of dependencies.

The way you force synchronization is by adding other CRTC state
objects. So if DC is busted and can only handle a single update per
work item, then I guess you always need all CRTC states and everything
will be run in order. But that also totally kills modern multi-screen
compositors. Xorg isn't modern, just in case that's not clear :-)

Lucking at the code it seems like you indeed have only a single dm
state, so yeah global sync is what you'll need as immediate fix, and
then maybe fix up DM to not be quite so silly ... or at least only do
the dm state stuff when really needed.

We could also sprinkle the drm_crtc_commit structure around a bit
(it's the glue that provides the synchronization across commits), but
since your dm state is global just grabbing all crtc states
unconditionally as part of that is probably best.


While we could duplicate a copy of that code with nothing but the
workqueue changed that isn't something I'd really like to maintain
going forward.


I'm not talking about duplicating the code, I'm talking about fixing the
helpers. I don't know that code well, but from the outside it sounds
like a bug there.

And executing work items in the order they are submitted is trivial.

Had anybody pinged Daniel or other people familiar with the helper code
about it?


Yeah something is wrong here, and the fix looks horrible :-)

Aside, I've also seen some recent discussion flare up about
drm_atomic_state_get/put used to paper over some other use-after-free,
but this time related to interrupt handlers. Maybe a few rules about
that:
- dont
- especially not when it's interrupt handlers, because you can't call
drm_atomic_state_put from interrupt handlers.

Instead have an spin_lock_irq to protect the shared date with your
interrupt handler, and _copy_ the date over. This is e.g. what
drm_crtc_arm_vblank_event does.


Nicholas wrote a patch that attempted to resolve the issue by adding every
CRTC into the commit to use use the stall checks. [1] While this forces
synchronisation on commits, it's kind of a hacky method that may take a
toll on performance.

Is it possible to have a DRM helper that forces synchronisation on some
commits without having to add every CRTC into the commit?

Also, is synchronisation really necessary for fast updates in amdgpu?
I'll admit, the idea of eliminating the use-after-free bug by eliminating
the use entirely doesn't seem ideal; but is forcing synchronisation on
these updates that much better?


Well clearing the dc_state pointer here and then allocating another
one in atomic_commit_tail also looks fishy. The proper fix is probably
a lot more involved, but yeah interim fix is to grab all crtc states
iff you also grabbed the dm_atomic_state structure. Real fix is to
only do this when necessary, which pretty much means the dc_state
needs to be somehow split up, or there needs to be some guarantees
about when it's necessary 

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

[Kazlauskas, Nicholas]

This is a cleaner change the other proposed patch since it doesn't need 
to modify the exist conversion functions but I'd be worried about broken 
userspace relying on 0-255 as the only acceptable range.


Not an expert on existing implementations to point out a specific one 
though.


Regards,
Nicholas Kazlauskas

On 2020-08-03 4:02 p.m., Alexander Monakov wrote:

Documentation for sysfs backlight level interface requires that
values in both 'brightness' and 'actual_brightness' files are
interpreted to be in range from 0 to the value given in the
'max_brightness' file.

With amdgpu, max_brightness gives 255, and values written by the user
into 'brightness' are internally rescaled to a wider range. However,
reading from 'actual_brightness' gives the raw register value without
inverse rescaling. This causes issues for various userspace tools such
as PowerTop and systemd that expect the value to be in the correct
range.

Introduce a helper to retrieve internal backlight range. Extend the
existing 'convert_brightness' function to handle conversion in both
directions.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=203905
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1242
Cc: Alex Deucher 
Signed-off-by: Alexander Monakov 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 73 ---
  1 file changed, 32 insertions(+), 41 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 710edc70e37e..03e21e7b7917 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2881,51 +2881,42 @@ static int set_backlight_via_aux(struct dc_link *link, 
uint32_t brightness)
return rc ? 0 : 1;
  }
  
-static u32 convert_brightness(const struct amdgpu_dm_backlight_caps *caps,

- const uint32_t user_brightness)
+static int get_brightness_range(const struct amdgpu_dm_backlight_caps *caps,
+   unsigned *min, unsigned *max)
  {
-   u32 min, max, conversion_pace;
-   u32 brightness = user_brightness;
-
if (!caps)
-   goto out;
+   return 0;
  
-	if (!caps->aux_support) {

-   max = caps->max_input_signal;
-   min = caps->min_input_signal;
-   /*
-* The brightness input is in the range 0-255
-* It needs to be rescaled to be between the
-* requested min and max input signal
-* It also needs to be scaled up by 0x101 to
-* match the DC interface which has a range of
-* 0 to 0x
-*/
-   conversion_pace = 0x101;
-   brightness =
-   user_brightness
-   * conversion_pace
-   * (max - min)
-   / AMDGPU_MAX_BL_LEVEL
-   + min * conversion_pace;
+   if (caps->aux_support) {
+   // Firmware limits are in nits, DC API wants millinits.
+   *max = 1000 * caps->aux_max_input_signal;
+   *min = 1000 * caps->aux_min_input_signal;
} else {
-   /* TODO
-* We are doing a linear interpolation here, which is OK but
-* does not provide the optimal result. We probably want
-* something close to the Perceptual Quantizer (PQ) curve.
-*/
-   max = caps->aux_max_input_signal;
-   min = caps->aux_min_input_signal;
-
-   brightness = (AMDGPU_MAX_BL_LEVEL - user_brightness) * min
-  + user_brightness * max;
-   // Multiple the value by 1000 since we use millinits
-   brightness *= 1000;
-   brightness = DIV_ROUND_CLOSEST(brightness, AMDGPU_MAX_BL_LEVEL);
+   // Firmware limits are 8-bit, PWM control is 16-bit.
+   *max = 0x101 * caps->max_input_signal;
+   *min = 0x101 * caps->min_input_signal;
}
+   return 1;
+}
  
-out:

-   return brightness;
+static u32 convert_brightness(const struct amdgpu_dm_backlight_caps *caps,
+ const uint32_t brightness, int from_user)
+{
+   unsigned min, max;
+
+   if (!get_brightness_range(caps, &min, &max))
+   return brightness;
+
+   if (from_user)
+   // Rescale 0..255 to min..max
+   return min + DIV_ROUND_CLOSEST((max - min) * brightness,
+  AMDGPU_MAX_BL_LEVEL);
+
+   if (brightness < min)
+   return 0;
+   // Rescale min..max to 0..255
+   return DIV_ROUND_CLOSEST(AMDGPU_MAX_BL_LEVEL * (brightness - min),
+max - min);
  }
  
  static int amdgpu_dm_backlight_update_status(struct backlight_device *bd)

@@ -2941,7 +2932,7 @@ static int amdgpu_dm_back

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

[Kazlauskas, Nicholas]

On 2020-08-03 4:02 p.m., Alexander Monakov wrote:

Documentation for sysfs backlight level interface requires that
values in both 'brightness' and 'actual_brightness' files are
interpreted to be in range from 0 to the value given in the
'max_brightness' file.

With amdgpu, max_brightness gives 255, and values written by the user
into 'brightness' are internally rescaled to a wider range. However,
reading from 'actual_brightness' gives the raw register value without
inverse rescaling. This causes issues for various userspace tools such
as PowerTop and systemd that expect the value to be in the correct
range.

Introduce a helper to retrieve internal backlight range. Extend the
existing 'convert_brightness' function to handle conversion in both
directions.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=203905
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1242
Cc: Alex Deucher 
Signed-off-by: Alexander Monakov 


Overall approach seems reasonable, nice catch.

I suggest to add convert_to_user_brightness() instead of making 
from_user a flag and extending the current functionality though. It 
makes it more clear from the call site what's happening.


Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 73 ---
  1 file changed, 32 insertions(+), 41 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 710edc70e37e..03e21e7b7917 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2881,51 +2881,42 @@ static int set_backlight_via_aux(struct dc_link *link, 
uint32_t brightness)
return rc ? 0 : 1;
  }
  
-static u32 convert_brightness(const struct amdgpu_dm_backlight_caps *caps,

- const uint32_t user_brightness)
+static int get_brightness_range(const struct amdgpu_dm_backlight_caps *caps,
+   unsigned *min, unsigned *max)
  {
-   u32 min, max, conversion_pace;
-   u32 brightness = user_brightness;
-
if (!caps)
-   goto out;
+   return 0;
  
-	if (!caps->aux_support) {

-   max = caps->max_input_signal;
-   min = caps->min_input_signal;
-   /*
-* The brightness input is in the range 0-255
-* It needs to be rescaled to be between the
-* requested min and max input signal
-* It also needs to be scaled up by 0x101 to
-* match the DC interface which has a range of
-* 0 to 0x
-*/
-   conversion_pace = 0x101;
-   brightness =
-   user_brightness
-   * conversion_pace
-   * (max - min)
-   / AMDGPU_MAX_BL_LEVEL
-   + min * conversion_pace;
+   if (caps->aux_support) {
+   // Firmware limits are in nits, DC API wants millinits.
+   *max = 1000 * caps->aux_max_input_signal;
+   *min = 1000 * caps->aux_min_input_signal;
} else {
-   /* TODO
-* We are doing a linear interpolation here, which is OK but
-* does not provide the optimal result. We probably want
-* something close to the Perceptual Quantizer (PQ) curve.
-*/
-   max = caps->aux_max_input_signal;
-   min = caps->aux_min_input_signal;
-
-   brightness = (AMDGPU_MAX_BL_LEVEL - user_brightness) * min
-  + user_brightness * max;
-   // Multiple the value by 1000 since we use millinits
-   brightness *= 1000;
-   brightness = DIV_ROUND_CLOSEST(brightness, AMDGPU_MAX_BL_LEVEL);
+   // Firmware limits are 8-bit, PWM control is 16-bit.
+   *max = 0x101 * caps->max_input_signal;
+   *min = 0x101 * caps->min_input_signal;
}
+   return 1;
+}
  
-out:

-   return brightness;
+static u32 convert_brightness(const struct amdgpu_dm_backlight_caps *caps,
+ const uint32_t brightness, int from_user)
+{
+   unsigned min, max;
+
+   if (!get_brightness_range(caps, &min, &max))
+   return brightness;
+
+   if (from_user)
+   // Rescale 0..255 to min..max
+   return min + DIV_ROUND_CLOSEST((max - min) * brightness,
+  AMDGPU_MAX_BL_LEVEL);
+
+   if (brightness < min)
+   return 0;
+   // Rescale min..max to 0..255
+   return DIV_ROUND_CLOSEST(AMDGPU_MAX_BL_LEVEL * (brightness - min),
+max - min);
  }
  
  static int amdgpu_dm_backlight_update_status(struct backlight_device *bd)

@@ -2941,7 +2932,7 @@ static int amdgpu_dm_backlight_update_status(struct 
backlight_devi

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

[Kazlauskas, Nicholas]

On 2020-08-04 12:28 p.m., Alexander Monakov wrote:



On Tue, 4 Aug 2020, Kazlauskas, Nicholas wrote:


This is a cleaner change the other proposed patch since it doesn't need to


Can you give a URL to the other patch please?


Sorry, replied to the wrong email by accident here.

The other change was modifying the max_brightness range and rescaling 
internal min/max defaults.


I don't think it was sent out to the list yet.

Regards,
Nicholas Kazlauskas




modify the exist conversion functions but I'd be worried about broken
userspace relying on 0-255 as the only acceptable range.


Not sure what you mean by this. Userspace simply reads the maximum value from
max_brightness sysfs file. On other gpu/firmware combinations it can be 7 or 9
for example, it just happens to be 255 with modern amdgpu. Minimum value is
always zero.

Value seen in max_brightness remains 255 with this patch, so as far as userspace
is concerned nothing is changed apart from value given by actual_brightness 
file.

Alexander



Not an expert on existing implementations to point out a specific one though.

Regards,
Nicholas Kazlauskas

On 2020-08-03 4:02 p.m., Alexander Monakov wrote:

Documentation for sysfs backlight level interface requires that
values in both 'brightness' and 'actual_brightness' files are
interpreted to be in range from 0 to the value given in the
'max_brightness' file.

With amdgpu, max_brightness gives 255, and values written by the user
into 'brightness' are internally rescaled to a wider range. However,
reading from 'actual_brightness' gives the raw register value without
inverse rescaling. This causes issues for various userspace tools such
as PowerTop and systemd that expect the value to be in the correct
range.

Introduce a helper to retrieve internal backlight range. Extend the
existing 'convert_brightness' function to handle conversion in both
directions.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=203905
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1242
Cc: Alex Deucher 
Signed-off-by: Alexander Monakov 
---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 73 ---
   1 file changed, 32 insertions(+), 41 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 710edc70e37e..03e21e7b7917 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2881,51 +2881,42 @@ static int set_backlight_via_aux(struct dc_link
*link, uint32_t brightness)
return rc ? 0 : 1;
   }
   -static u32 convert_brightness(const struct amdgpu_dm_backlight_caps
*caps,
- const uint32_t user_brightness)
+static int get_brightness_range(const struct amdgpu_dm_backlight_caps
*caps,
+   unsigned *min, unsigned *max)
   {
-   u32 min, max, conversion_pace;
-   u32 brightness = user_brightness;
-
if (!caps)
-   goto out;
+   return 0;
   -if (!caps->aux_support) {
-   max = caps->max_input_signal;
-   min = caps->min_input_signal;
-   /*
-* The brightness input is in the range 0-255
-* It needs to be rescaled to be between the
-* requested min and max input signal
-* It also needs to be scaled up by 0x101 to
-* match the DC interface which has a range of
-* 0 to 0x
-*/
-   conversion_pace = 0x101;
-   brightness =
-   user_brightness
-   * conversion_pace
-   * (max - min)
-   / AMDGPU_MAX_BL_LEVEL
-   + min * conversion_pace;
+   if (caps->aux_support) {
+   // Firmware limits are in nits, DC API wants millinits.
+   *max = 1000 * caps->aux_max_input_signal;
+   *min = 1000 * caps->aux_min_input_signal;
} else {
-   /* TODO
-* We are doing a linear interpolation here, which is OK but
-* does not provide the optimal result. We probably want
-* something close to the Perceptual Quantizer (PQ) curve.
-*/
-   max = caps->aux_max_input_signal;
-   min = caps->aux_min_input_signal;
-
-   brightness = (AMDGPU_MAX_BL_LEVEL - user_brightness) * min
-  + user_brightness * max;
-   // Multiple the value by 1000 since we use millinits
-   brightness *= 1000;
-   brightness = DIV_ROUND_CLOSEST(brightness,
AMDGPU_MAX_BL_LEVEL);
+   // Firmware limits are 8-bit, PWM control is 16-bit.
+   *max = 0x101 * caps->max_input_signal;
+   *min = 0x101 * 

Re: [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state

[Kazlauskas, Nicholas]

On 2020-08-05 4:37 p.m., Rodrigo Siqueira wrote:

Hi,

I have some minor inline comments, but everything looks fine when I
tested it on Raven; feel free to add

Tested-by: Rodrigo Siqueira 

in the whole series.


Thanks for the reviews!

I can clean up the nitpicks for this patch and make a v2.

Regards,
Nicholas Kazlauskas



On 07/30, Nicholas Kazlauskas wrote:

[Why]
DM atomic check was structured in a way that we required old DC state
in order to dynamically add and remove planes and streams from the
context to build the DC state context for validation.

DRM private objects were used to carry over the last DC state and
were added to the context on nearly every commit - regardless of fast
or full so we could check whether or not the new state could affect
bandwidth.

The problem with this model is that DRM private objects do not
implicitly stall out other commits.

So if you have two commits touching separate DRM objects they could
run concurrently and potentially execute out of order - leading to a
use-after-free.

If we want this to be safe we have two options:
1. Stall out concurrent commits since they touch the same private object
2. Refactor DM to not require old DC state and drop private object usage

[How]
This implements approach #2 since it still allows for judder free
updates in multi-display scenarios.

I'll list the big changes in order at a high level:

1. Subclass DRM atomic state instead of using DRM private objects.

DC relied on the old state to determine which changes cause bandwidth
updates but now we have DM perform similar checks based on DRM state
instead - dropping the requirement for old state to exist at all.

This means that we can now build a new DC context from scratch whenever
we have something that DM thinks could affect bandwidth.

Whenever we need to rebuild bandwidth we now add all CRTCs and planes
to the DRM state in order to get the absolute set of DC streams and
DC planes.

This introduces a stall on other commits, but this stall already
exists because of the lock_and_validation logic and it's necessary
since updates may move around pipes and require full reprogramming.

2. Drop workarounds to add planes to maintain z-order early in atomic
check. This is no longer needed because of the changes for (1).

This also involves fixing up should_plane_reset checks since we can just
avoid resetting streams and planes when they haven't actually changed.

3. Rework dm_update_crtc_state and dm_update_plane_state to be single
pass instead of two pass.

This is necessary since we no longer have the dc_state to add and
remove planes to the context in and we want to defer creation to the
end of commit_check.

It also makes the logic a lot simpler to follow since as an added bonus.

Cc: Bhawanpreet Lakha 
Cc: Harry Wentland 
Cc: Leo Li 
Cc: Daniel Vetter 
Signed-off-by: Nicholas Kazlauskas 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 720 +++---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  11 +-
  2 files changed, 280 insertions(+), 451 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 59829ec81694..97a7dfc620e8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1839,7 +1839,6 @@ static int dm_resume(void *handle)
struct drm_plane *plane;
struct drm_plane_state *new_plane_state;
struct dm_plane_state *dm_new_plane_state;
-   struct dm_atomic_state *dm_state = 
to_dm_atomic_state(dm->atomic_obj.state);
enum dc_connection_type new_connection_type = dc_connection_none;
struct dc_state *dc_state;
int i, r, j;
@@ -1879,11 +1878,6 @@ static int dm_resume(void *handle)
  
  		return 0;

}
-   /* Recreate dc_state - DC invalidates it when setting power state to 
S3. */
-   dc_release_state(dm_state->context);
-   dm_state->context = dc_create_state(dm->dc);
-   /* TODO: Remove dc_state->dccg, use dc->dccg directly. */
-   dc_resource_state_construct(dm->dc, dm_state->context);
  
  	/* Before powering on DC we need to re-initialize DMUB. */

r = dm_dmub_hw_init(adev);
@@ -2019,11 +2013,51 @@ const struct amdgpu_ip_block_version dm_ip_block =
   * *WIP*
   */
  
+struct drm_atomic_state *dm_atomic_state_alloc(struct drm_device *dev)

+{
+   struct dm_atomic_state *dm_state;
+
+   dm_state = kzalloc(sizeof(*dm_state), GFP_KERNEL);


How about use GFP_ATOMIC here?


+
+   if (!dm_state)
+   return NULL;
+
+   if (drm_atomic_state_init(dev, &dm_state->base) < 0) {
+   kfree(dm_state);
+   return NULL;
+   }
+
+   return &dm_state->base;
+}
+
+void dm_atomic_state_free(struct drm_atomic_state *state)
+{
+   struct dm_atomic_state *dm_state = to_dm_atomic_state(state);
+
+   if (dm_state->context) {
+   dc_release_state(dm_state->context);
+

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

[Kazlauskas, Nicholas]

On 2020-08-05 5:11 p.m., Rodrigo Siqueira wrote:

On 07/30, Nicholas Kazlauskas wrote:

[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)


Why not add a case when we move to a TMZ area?

Reviewed-by: Rodrigo Siqueira 


TMZ doesn't affect DML calculations or validation in this case so we can 
safely skip it.


Regards,
Nicholas Kazlauskas




return true;
}
  
--

2.25.1





___
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

[Kazlauskas, Nicholas]

On 2020-08-05 4:45 p.m., Rodrigo Siqueira wrote:

On 07/30, Nicholas Kazlauskas wrote:

[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.


How about adding this optimization description in our TODO list
under-display folder?

Reviewed-by: Rodrigo Siqueira 


Sure, I'll make another patch to clean up some of the TODO items in the 
text file.


Regards,
Nicholas Kazlauskas

  

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CRodrigo.Siqueira%40amd.com%7Ccc095e7ce6164f529e2708d834c86d1b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637317382766607890&sdata=omLC%2BizXVEjjGe6IylBpniZzyUGlzTATrgRoWEo6dHc%3D&reserved=0




___
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

[Kazlauskas, Nicholas]

On 2020-08-07 4:34 a.m., dan...@ffwll.ch wrote:

On Thu, Jul 30, 2020 at 04:36:40PM -0400, Nicholas Kazlauskas wrote:

[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.


I think we do something similar in i915, where we have a "nothing except
base address changed" fast path, but for anything else we fully compute a
new state. Obviously you should try to keep global state synchronization
to a minimum for this step, so it's not entirely only 2 options.

Once we have the states, we compare them and figure out whether we can get
away with a fast modeset operation (maybe what you guys call medium
update). Anyway I think being slightly more aggressive with computing full
state, and then falling back to more optimized update again is a good
approach. Only risk is if we you have too much synchronization in your
locking (e.g. modern compositors do like to change tiling and stuff,
especially once you have modifiers enabled, so this shouldn't cause a sync
across crtc except when absolutely needed).
-Daniel


Sounds like the right approach then.

We can support tiling changes in the fast path, but the more optimized 
version of that last check is really linear <-> tiled. That requires 
global validation with DC to revalidate bandwidth and calculate 
requestor parameters for HW. So we'll have to stall for some of these 
changes unfortunately since we need the full HW state for validation.


Regards,
Nicholas Kazlauskas





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

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel




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

Re: [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes

[Kazlauskas, Nicholas]

On 2020-08-07 4:30 a.m., dan...@ffwll.ch wrote:

On Thu, Jul 30, 2020 at 04:36:38PM -0400, Nicholas Kazlauskas wrote:

[Why]
We're racing with userspace as the flags could potentially change
from when we acquired and validated them in commit_check.


Uh ... I didn't know these could change. I think my comments on Bas'
series are even more relevant now. I think long term would be best to bake
these flags in at addfb time when modifiers aren't set. And otherwise
always use the modifiers flag, and completely ignore the legacy flags
here.
-Daniel



There's a set tiling/mod flags IOCTL that can be called after addfb 
happens, so unless there's some sort of driver magic preventing this 
from working when it's already been pinned for scanout then I don't see 
anything stopping this from happening.


I still need to review the modifiers series in a little more detail but 
that looks like a good approach to fixing these kind of issues.


Regards,
Nicholas Kazlauskas



[How]
We unfortunately can't drop this function in its entirety from
prepare_planes since we don't know the afb->address at commit_check
time yet.

So instead of querying new tiling_flags and tmz_surface use the ones
from the plane_state directly.

While we're at it, also update the force_disable_dcc option based
on the state from atomic check.

Cc: Bhawanpreet Lakha 
Cc: Rodrigo Siqueira 
Signed-off-by: Nicholas Kazlauskas 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
  1 file changed, 19 insertions(+), 17 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 bf1881bd492c..f78c09c9585e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5794,14 +5794,8 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
*plane,
struct list_head list;
struct ttm_validate_buffer tv;
struct ww_acquire_ctx ticket;
-   uint64_t tiling_flags;
uint32_t domain;
int r;
-   bool tmz_surface = false;
-   bool force_disable_dcc = false;
-
-   dm_plane_state_old = to_dm_plane_state(plane->state);
-   dm_plane_state_new = to_dm_plane_state(new_state);
  
  	if (!new_state->fb) {

DRM_DEBUG_DRIVER("No FB bound\n");
@@ -5845,27 +5839,35 @@ static int dm_plane_helper_prepare_fb(struct drm_plane 
*plane,
return r;
}
  
-	amdgpu_bo_get_tiling_flags(rbo, &tiling_flags);

-
-   tmz_surface = amdgpu_bo_encrypted(rbo);
-
ttm_eu_backoff_reservation(&ticket, &list);
  
  	afb->address = amdgpu_bo_gpu_offset(rbo);
  
  	amdgpu_bo_ref(rbo);
  
+	/**

+* We don't do surface updates on planes that have been newly created,
+* but we also don't have the afb->address during atomic check.
+*
+* Fill in buffer attributes depending on the address here, but only on
+* newly created planes since they're not being used by DC yet and this
+* won't modify global state.
+*/
+   dm_plane_state_old = to_dm_plane_state(plane->state);
+   dm_plane_state_new = to_dm_plane_state(new_state);
+
if (dm_plane_state_new->dc_state &&
-   dm_plane_state_old->dc_state != 
dm_plane_state_new->dc_state) {
-   struct dc_plane_state *plane_state = 
dm_plane_state_new->dc_state;
+   dm_plane_state_old->dc_state != dm_plane_state_new->dc_state) {
+   struct dc_plane_state *plane_state =
+   dm_plane_state_new->dc_state;
+   bool force_disable_dcc = !plane_state->dcc.enable;
  
-		force_disable_dcc = adev->asic_type == CHIP_RAVEN && adev->in_suspend;

fill_plane_buffer_attributes(
adev, afb, plane_state->format, plane_state->rotation,
-   tiling_flags, &plane_state->tiling_info,
-   &plane_state->plane_size, &plane_state->dcc,
-   &plane_state->address, tmz_surface,
-   force_disable_dcc);
+   dm_plane_state_new->tiling_flags,
+   &plane_state->tiling_info, &plane_state->plane_size,
+   &plane_state->dcc, &plane_state->address,
+   dm_plane_state_new->tmz_surface, force_disable_dcc);
}
  
  	return 0;

--
2.25.1

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel




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

Re: [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state

[Kazlauskas, Nicholas]

On 2020-08-07 4:52 a.m., dan...@ffwll.ch wrote:

On Thu, Jul 30, 2020 at 04:36:42PM -0400, Nicholas Kazlauskas wrote:

@@ -440,7 +431,7 @@ struct dm_crtc_state {
  #define to_dm_crtc_state(x) container_of(x, struct dm_crtc_state, base)
  
  struct dm_atomic_state {

-   struct drm_private_state base;
+   struct drm_atomic_state base;
  
  	struct dc_state *context;


Also curiosity: Can't we just embed dc_state here, instead of a pointer?
Then it would become a lot more obvious that mostly this is a state object
container like drm_atomic_state, but for the DC specific state structures.
And we could look into moving the actual DC states into drm private states
perhaps (if that helps with the code structure and overall flow).

Maybe as next steps.
-Daniel



It's the refcounting that's the problem with this stuff. I'd like to 
move DC to a model where we have no memory allocation/ownership but that 
might be a bit of a more long term plan at this point.


Same with dc_plane_state and dc_stream_state as well - these could exist 
on the DRM objects as long as they're not refcounted.


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

Re: [PATCH v2] drm/amd/display: use correct scale for actual_brightness

[Kazlauskas, Nicholas]

No objections from my side - and thanks for addressing my feedback.

Regards,
Nicholas Kazlauskas

On 2020-08-18 12:15 p.m., Alex Deucher wrote:

Applied.  Thanks!

Alex

On Mon, Aug 17, 2020 at 1:59 PM Alex Deucher  wrote:


On Mon, Aug 17, 2020 at 3:09 AM Alexander Monakov  wrote:


Ping.


Patch looks good to me:
Reviewed-by: Alex Deucher 

Nick, unless you have any objections, I'll go ahead and apply it.

Alex



On Tue, 4 Aug 2020, Alexander Monakov wrote:


Documentation for sysfs backlight level interface requires that
values in both 'brightness' and 'actual_brightness' files are
interpreted to be in range from 0 to the value given in the
'max_brightness' file.

With amdgpu, max_brightness gives 255, and values written by the user
into 'brightness' are internally rescaled to a wider range. However,
reading from 'actual_brightness' gives the raw register value without
inverse rescaling. This causes issues for various userspace tools such
as PowerTop and systemd that expect the value to be in the correct
range.

Introduce a helper to retrieve internal backlight range. Use it to
reimplement 'convert_brightness' as 'convert_brightness_from_user' and
introduce 'convert_brightness_to_user'.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=203905
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1242
Cc: Alex Deucher 
Cc: Nicholas Kazlauskas 
Signed-off-by: Alexander Monakov 
---
v2: split convert_brightness to &_from_user and &_to_user (Nicholas)

  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 81 +--
  1 file changed, 40 insertions(+), 41 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 710edc70e37e..b60a763f3f95 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2881,51 +2881,50 @@ static int set_backlight_via_aux(struct dc_link *link, 
uint32_t brightness)
   return rc ? 0 : 1;
  }

-static u32 convert_brightness(const struct amdgpu_dm_backlight_caps *caps,
-   const uint32_t user_brightness)
+static int get_brightness_range(const struct amdgpu_dm_backlight_caps *caps,
+ unsigned *min, unsigned *max)
  {
- u32 min, max, conversion_pace;
- u32 brightness = user_brightness;
-
   if (!caps)
- goto out;
+ return 0;

- if (!caps->aux_support) {
- max = caps->max_input_signal;
- min = caps->min_input_signal;
- /*
-  * The brightness input is in the range 0-255
-  * It needs to be rescaled to be between the
-  * requested min and max input signal
-  * It also needs to be scaled up by 0x101 to
-  * match the DC interface which has a range of
-  * 0 to 0x
-  */
- conversion_pace = 0x101;
- brightness =
- user_brightness
- * conversion_pace
- * (max - min)
- / AMDGPU_MAX_BL_LEVEL
- + min * conversion_pace;
+ if (caps->aux_support) {
+ // Firmware limits are in nits, DC API wants millinits.
+ *max = 1000 * caps->aux_max_input_signal;
+ *min = 1000 * caps->aux_min_input_signal;
   } else {
- /* TODO
-  * We are doing a linear interpolation here, which is OK but
-  * does not provide the optimal result. We probably want
-  * something close to the Perceptual Quantizer (PQ) curve.
-  */
- max = caps->aux_max_input_signal;
- min = caps->aux_min_input_signal;
-
- brightness = (AMDGPU_MAX_BL_LEVEL - user_brightness) * min
-+ user_brightness * max;
- // Multiple the value by 1000 since we use millinits
- brightness *= 1000;
- brightness = DIV_ROUND_CLOSEST(brightness, AMDGPU_MAX_BL_LEVEL);
+ // Firmware limits are 8-bit, PWM control is 16-bit.
+ *max = 0x101 * caps->max_input_signal;
+ *min = 0x101 * caps->min_input_signal;
   }
+ return 1;
+}

-out:
- return brightness;
+static u32 convert_brightness_from_user(const struct amdgpu_dm_backlight_caps 
*caps,
+ uint32_t brightness)
+{
+ unsigned min, max;
+
+ if (!get_brightness_range(caps, &min, &max))
+ return brightness;
+
+ // Rescale 0..255 to min..max
+ return min + DIV_ROUND_CLOSEST((max - min) * brightness,
+AMDGPU_MAX_BL_LEVEL);
+}
+
+static u32 convert_brightness_to_user(const struct amdgpu_dm_backlight_caps 
*caps,
+   uint32_t brightness)
+{
+ unsigned min, max;
+
+ if (!get_brightness_range(caps, &min, &max))
+ return brightness;
+
+ if (bright

Re: [PATCH 2/2] amd/display: add cursor check for YUV primary plane

[Kazlauskas, Nicholas]

On 2021-02-19 11:19 a.m., Simon Ser wrote:

The cursor plane can't be displayed if the primary plane isn't
using an RGB format. Reject such atomic commits so that user-space
can have a fallback instead of an invisible cursor.

In theory we could support YUV if the cursor is also YUV, but at the
moment only ARGB cursors are supported.


Patch 1 looks good, but this patch needs to be adjusted.

We can support cursor plane, but only if we have an overlay plane 
enabled that's using XRGB/ARGB.


This is what we do on Chrome OS for video playback:

Cursor Plane - ARGB
Overlay Plane - ARGB Desktop/UI with cutout for video
Primary Plane - NV12 video

So this new check would break this usecase. It needs to check that there 
isn't an XRGB/ARGB plane at the top of the blending chain instead.


Regards,
Nicholas Kazlauskas



Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
  1 file changed, 7 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 4548b779bbce..f659e6cfdfcf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9239,6 +9239,13 @@ static int dm_check_crtc_cursor(struct drm_atomic_state 
*state,
return -EINVAL;
}
  
+	/* In theory we could probably support YUV cursors when the primary

+* plane uses a YUV format, but there's no use-case for it yet. */
+   if (new_primary_state->fb && new_primary_state->fb->format->is_yuv) {
+   drm_dbg_atomic(crtc->dev, "Cursor plane can't be used with YUV 
primary plane\n");
+   return -EINVAL;
+   }
+
return 0;
  }
  



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

Re: [PATCH 2/2] amd/display: add cursor check for YUV primary plane

[Kazlauskas, Nicholas]

On 2021-02-19 12:29 p.m., Simon Ser wrote:

On Friday, February 19th, 2021 at 6:22 PM, Kazlauskas, Nicholas 
 wrote:


We can support cursor plane, but only if we have an overlay plane
enabled that's using XRGB/ARGB.

This is what we do on Chrome OS for video playback:

Cursor Plane - ARGB
Overlay Plane - ARGB Desktop/UI with cutout for video
Primary Plane - NV12 video

So this new check would break this usecase. It needs to check that there
isn't an XRGB/ARGB plane at the top of the blending chain instead.


Oh, interesting. I'll adjust the patch.

Related: how does this affect scaling? Right now there is a check that makes
sure the cursor plane scaling matches the primary plane's. Should we instead
check that the cursor plane scaling matches the top-most XRGB/ARGB plane's?



Can't really do scaling on the cursor plane itself. It scales with the 
underlying pipe driving it so it'll only be correct if it matches that.


Primary plane isn't the correct check here since we always use the 
topmost pipe in the blending chain to draw the cursor - in the example I 
gave it'd have to match the overlay plane's scaling, not the primary 
plane's.


Regards,
Nicholas Kazlauskas

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

Re: [PATCH] drm/amdgpu: stream's id should reduced after stream destruct

[Kazlauskas, Nicholas]

On 2021-02-20 1:30 a.m., ZhiJie.Zhang wrote:

Signed-off-by: ZhiJie.Zhang 
---
  drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
index c103f858375d..dc7b7e57a86c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
@@ -137,6 +137,8 @@ static void dc_stream_destruct(struct dc_stream_state 
*stream)
dc_transfer_func_release(stream->out_transfer_func);
stream->out_transfer_func = NULL;
}
+
+   stream->ctx->dc_stream_id_count--;


This is supposed to be a unique identifier so we shouldn't be reusing 
any old ID when creating a new stream.


Regards,
Nicholas Kazlauskas


  }
  
  void dc_stream_retain(struct dc_stream_state *stream)




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

Re: [PATCH] drm/amdgpu/display: fix compilation when CONFIG_DRM_AMD_DC_DCN is not set

[Kazlauskas, Nicholas]

On 2021-02-23 10:22 a.m., Alex Deucher wrote:

Missing some CONFIG_DRM_AMD_DC_DCN ifdefs.

Fixes: 9d99a805a9a0 ("drm/amd/display: Fix system hang after multiple hotplugs")
Signed-off-by: Alex Deucher 
Cc: Stephen Rothwell 
Cc: Qingqing Zhuo 


Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
  1 file changed, 2 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 7a393eeae4b1..22443e696567 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5457,12 +5457,14 @@ static inline int dm_set_vblank(struct drm_crtc *crtc, 
bool enable)
if (amdgpu_in_reset(adev))
return 0;
  
+#if defined(CONFIG_DRM_AMD_DC_DCN)

spin_lock_irqsave(&dm->vblank_lock, flags);
dm->vblank_workqueue->dm = dm;
dm->vblank_workqueue->otg_inst = acrtc->otg_inst;
dm->vblank_workqueue->enable = enable;
spin_unlock_irqrestore(&dm->vblank_lock, flags);
schedule_work(&dm->vblank_workqueue->mall_work);
+#endif
  
  	return 0;

  }



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

Re: [PATCH v6 3/3] drm/amd/display: Skip modeset for front porch change

[Kazlauskas, Nicholas]

On 2021-02-12 8:08 p.m., Aurabindo Pillai wrote:

[Why]
A seamless transition between modes can be performed if the new incoming
mode has the same timing parameters as the optimized mode on a display with a
variable vtotal min/max.

Smooth video playback usecases can be enabled with this seamless transition by
switching to a new mode which has a refresh rate matching the video.

[How]
Skip full modeset if userspace requested a compatible freesync mode which only
differs in the front porch timing from the current mode.

Signed-off-by: Aurabindo Pillai 
Acked-by: Christian König 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 220 ++
  1 file changed, 180 insertions(+), 40 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 c472905c7d72..628fec855e14 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -212,6 +212,9 @@ static bool amdgpu_dm_psr_disable_all(struct 
amdgpu_display_manager *dm);
  static const struct drm_format_info *
  amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
  
+static bool

+is_timing_unchanged_for_freesync(struct drm_crtc_state *old_crtc_state,
+struct drm_crtc_state *new_crtc_state);
  /*
   * dm_vblank_get_counter
   *
@@ -335,6 +338,17 @@ static inline bool amdgpu_dm_vrr_active(struct 
dm_crtc_state *dm_state)
   dm_state->freesync_config.state == VRR_STATE_ACTIVE_FIXED;
  }
  
+static inline bool is_dc_timing_adjust_needed(struct dm_crtc_state *old_state,

+ struct dm_crtc_state *new_state)
+{
+   if (new_state->freesync_config.state ==  VRR_STATE_ACTIVE_FIXED)
+   return true;
+   else if (amdgpu_dm_vrr_active(old_state) != 
amdgpu_dm_vrr_active(new_state))
+   return true;
+   else
+   return false;
+}
+
  /**
   * dm_pflip_high_irq() - Handle pageflip interrupt
   * @interrupt_params: ignored
@@ -5008,19 +5022,16 @@ static void 
fill_stream_properties_from_drm_display_mode(
timing_out->hdmi_vic = hv_frame.vic;
}
  
-	timing_out->h_addressable = mode_in->crtc_hdisplay;

-   timing_out->h_total = mode_in->crtc_htotal;
-   timing_out->h_sync_width =
-   mode_in->crtc_hsync_end - mode_in->crtc_hsync_start;
-   timing_out->h_front_porch =
-   mode_in->crtc_hsync_start - mode_in->crtc_hdisplay;
-   timing_out->v_total = mode_in->crtc_vtotal;
-   timing_out->v_addressable = mode_in->crtc_vdisplay;
-   timing_out->v_front_porch =
-   mode_in->crtc_vsync_start - mode_in->crtc_vdisplay;
-   timing_out->v_sync_width =
-   mode_in->crtc_vsync_end - mode_in->crtc_vsync_start;
-   timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+   timing_out->h_addressable = mode_in->hdisplay;
+   timing_out->h_total = mode_in->htotal;
+   timing_out->h_sync_width = mode_in->hsync_end - mode_in->hsync_start;
+   timing_out->h_front_porch = mode_in->hsync_start - mode_in->hdisplay;
+   timing_out->v_total = mode_in->vtotal;
+   timing_out->v_addressable = mode_in->vdisplay;
+   timing_out->v_front_porch = mode_in->vsync_start - mode_in->vdisplay;
+   timing_out->v_sync_width = mode_in->vsync_end - mode_in->vsync_start;
+   timing_out->pix_clk_100hz = mode_in->clock * 10;
+
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
  
  	stream->output_color_space = get_output_color_space(timing_out);

@@ -5240,6 +5251,33 @@ get_highest_refresh_rate_mode(struct amdgpu_dm_connector 
*aconnector,
return m_pref;
  }
  
+static bool is_freesync_video_mode(struct drm_display_mode *mode,

+  struct amdgpu_dm_connector *aconnector)
+{
+   struct drm_display_mode *high_mode;
+   int timing_diff;
+
+   high_mode = get_highest_refresh_rate_mode(aconnector, false);
+   if (!high_mode || !mode)
+   return false;
+
+   timing_diff = high_mode->vtotal - mode->vtotal;
+
+   if (high_mode->clock == 0 || high_mode->clock != mode->clock ||
+   high_mode->hdisplay != mode->hdisplay ||
+   high_mode->vdisplay != mode->vdisplay ||
+   high_mode->hsync_start != mode->hsync_start ||
+   high_mode->hsync_end != mode->hsync_end ||
+   high_mode->htotal != mode->htotal ||
+   high_mode->hskew != mode->hskew ||
+   high_mode->vscan != mode->vscan ||
+   high_mode->vsync_start - mode->vsync_start != timing_diff ||
+   high_mode->vsync_end - mode->vsync_end != timing_diff)
+   return false;
+   else
+   return true;
+}
+
  static struct dc_stream_state *
  create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
   const struct drm_display_mode *drm_mode,
@@ -5253,8 +5291,10 @@

Re: [PATCH 3/6] amd/display: fail on cursor plane without an underlying plane

[Kazlauskas, Nicholas]

On 2021-03-04 4:05 a.m., Michel Dänzer wrote:

On 2021-03-03 8:17 p.m., Daniel Vetter wrote:

On Wed, Mar 3, 2021 at 5:53 PM Michel Dänzer  wrote:


On 2021-02-19 7:58 p.m., Simon Ser wrote:

Make sure there's an underlying pipe that can be used for the
cursor.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
---
   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)

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 acbe1537e7cf..a5d6010405bf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9226,9 +9226,14 @@ static int dm_check_crtc_cursor(struct 
drm_atomic_state *state,

   }

   new_cursor_state = drm_atomic_get_new_plane_state(state, 
crtc->cursor);
- if (!new_cursor_state || !new_underlying_state || 
!new_cursor_state->fb)

+ if (!new_cursor_state || !new_cursor_state->fb)
   return 0;

+ if (!new_underlying_state || !new_underlying_state->fb) {
+ drm_dbg_atomic(crtc->dev, "Cursor plane can't be 
enabled without underlying plane\n");

+ return -EINVAL;
+ }
+
   cursor_scale_w = new_cursor_state->crtc_w * 1000 /
    (new_cursor_state->src_w >> 16);
   cursor_scale_h = new_cursor_state->crtc_h * 1000 /



Houston, we have a problem I'm afraid. Adding Daniel.


If the primary plane is enabled with a format which isn't compatible 
with the HW cursor,
and no overlay plane is enabled, the same issues as described in 
b836a274b797
"drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC 
is" can again occur:



* The legacy cursor ioctl fails with EINVAL for a non-0 cursor FB ID
  (which enables the cursor plane).

* If the cursor plane is enabled (e.g. using the legacy cursor ioctl
  during DPMS off), changing the legacy DPMS property value from off to
  on fails with EINVAL.


atomic_check should still be run when the crtc is off, so the legacy
cursor ioctl should fail when dpms off in this case already.


Good point. This could already be problematic though. E.g. mutter treats
EINVAL from the cursor ioctl as the driver not supporting HW cursors at
all, so it falls back to SW cursor and never tries to use the HW cursor
again. (I don't think mutter could hit this particular case with an
incompatible format though, but there might be other similar user space)



Moreover, in the same scenario plus an overlay plane enabled with a
HW cursor compatible format, if the FB bound to the overlay plane is
destroyed, the common DRM code will attempt to disable the overlay
plane, but dm_check_crtc_cursor will reject that now. I can't remember
exactly what the result is, but AFAIR it's not pretty.


CRTC gets disabled instead. That's why we went with the "always
require primary plane" hack. I think the only solution here would be
to enable the primary plane (but not in userspace-visible state, so
this needs to be done in the dc derived state objects only) that scans
out black any time we're in such a situation with cursor with no
planes.


This is about a scenario described by Nicholas earlier:

Cursor Plane - ARGB

Overlay Plane - ARGB Desktop/UI with cutout for video

Primary Plane - NV12 video

And destroying the FB bound to the overlay plane. The fallback to disable
the CRTC in atomic_remove_fb only kicks in for the primary plane, so it
wouldn't in this case and would fail. Which would in turn trigger the
WARN in drm_framebuffer_remove (and leave the overlay plane scanning out
from freed memory?).


The cleanest solution might be not to allow any formats incompatible with
the HW cursor for the primary plane.




Legacy X userspace doesn't use overlays but Chrome OS does.

This would regress ChromeOS MPO support because it relies on the NV12 
video plane being on the bottom.


When ChromeOS disables MPO it doesn't do it plane by plane, it does it 
in one go from NV12+ARGB -> ARGB8.


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

Re: [PATCH 3/6] amd/display: fail on cursor plane without an underlying plane

[Kazlauskas, Nicholas]

On 2021-03-04 10:35 a.m., Michel Dänzer wrote:

On 2021-03-04 4:09 p.m., Kazlauskas, Nicholas wrote:

On 2021-03-04 4:05 a.m., Michel Dänzer wrote:

On 2021-03-03 8:17 p.m., Daniel Vetter wrote:

On Wed, Mar 3, 2021 at 5:53 PM Michel Dänzer  wrote:


Moreover, in the same scenario plus an overlay plane enabled with a
HW cursor compatible format, if the FB bound to the overlay plane is
destroyed, the common DRM code will attempt to disable the overlay
plane, but dm_check_crtc_cursor will reject that now. I can't remember
exactly what the result is, but AFAIR it's not pretty.


CRTC gets disabled instead. That's why we went with the "always
require primary plane" hack. I think the only solution here would be
to enable the primary plane (but not in userspace-visible state, so
this needs to be done in the dc derived state objects only) that scans
out black any time we're in such a situation with cursor with no
planes.


This is about a scenario described by Nicholas earlier:

Cursor Plane - ARGB

Overlay Plane - ARGB Desktop/UI with cutout for video

Primary Plane - NV12 video

And destroying the FB bound to the overlay plane. The fallback to disable
the CRTC in atomic_remove_fb only kicks in for the primary plane, so it
wouldn't in this case and would fail. Which would in turn trigger the
WARN in drm_framebuffer_remove (and leave the overlay plane scanning out
from freed memory?).


The cleanest solution might be not to allow any formats incompatible with
the HW cursor for the primary plane.


Legacy X userspace doesn't use overlays but Chrome OS does.

This would regress ChromeOS MPO support because it relies on the NV12
video plane being on the bottom.


Could it use the NV12 overlay plane below the ARGB primary plane?


Plane ordering was previously undefined in DRM so we have userspace that 
assumes overlays are on top.


Today we have the z-order property in DRM that defines where it is in 
the stack, so technically it could but we'd also be regressing existing 
behavior on Chrome OS today.






When ChromeOS disables MPO it doesn't do it plane by plane, it does it
in one go from NV12+ARGB -> ARGB8.


Even so, we cannot expect all user space to do the same, and we cannot
allow any user space to trigger a WARN and scanout from freed memory.




The WARN doesn't trigger because there's still a reference on the FB - 
the reference held by DRM since it's still scanning out the overlay. 
Userspace can't reclaim this memory with another buffer allocation 
because it's still in use.


It's a little odd that a disable commit can fail, but I don't think 
there's anything in DRM core that specifies that this can't happen for 
planes.


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

Re: [PATCH 2/4] drm/amdgpu/display: don't assert in set backlight function

[Kazlauskas, Nicholas]

On 2021-03-04 12:41 p.m., Alex Deucher wrote:

It just spams the logs.

Signed-off-by: Alex Deucher 


This series in general looks reasonable to me:
Reviewed-by: Nicholas Kazlauskas 


---
  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
  1 file changed, 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 fa9a62dc174b..974b70f21837 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2614,7 +2614,6 @@ bool dc_link_set_backlight_level(const struct dc_link 
*link,
if (pipe_ctx->plane_state == NULL)
frame_ramp = 0;
} else {
-   ASSERT(false);


Just a comment on what's actually going on here with this warning:

Technically we can't apply the backlight level without a plane_state in 
the context but the panel is also off anyway.


I think there might be a bug here when the panel turns on and we're not 
applying values set when it was off but I don't think anyone's reported 
this as an issue.


I'm not entirely sure if the value gets cached and reapplied with the 
correct value later, but it's something to keep in mind.


Regards,
Nicholas Kazlauskas


return false;
}
  



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

Re: [PATCH 2/4] drm/amdgpu/display: don't assert in set backlight function

[Kazlauskas, Nicholas]

On 2021-03-04 1:41 p.m., Alex Deucher wrote:

On Thu, Mar 4, 2021 at 1:33 PM Kazlauskas, Nicholas
 wrote:


On 2021-03-04 12:41 p.m., Alex Deucher wrote:

It just spams the logs.

Signed-off-by: Alex Deucher 


This series in general looks reasonable to me:
Reviewed-by: Nicholas Kazlauskas 


---
   drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
   1 file changed, 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 fa9a62dc174b..974b70f21837 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2614,7 +2614,6 @@ bool dc_link_set_backlight_level(const struct dc_link 
*link,
   if (pipe_ctx->plane_state == NULL)
   frame_ramp = 0;
   } else {
- ASSERT(false);


Just a comment on what's actually going on here with this warning:

Technically we can't apply the backlight level without a plane_state in
the context but the panel is also off anyway.

I think there might be a bug here when the panel turns on and we're not
applying values set when it was off but I don't think anyone's reported
this as an issue.

I'm not entirely sure if the value gets cached and reapplied with the
correct value later, but it's something to keep in mind.


It doesn't.  I have additional patches here to cache it:
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agd5f%2Flinux%2Flog%2F%3Fh%3Dbacklight_wip&data=04%7C01%7Cnicholas.kazlauskas%40amd.com%7Cf259e9290b0e4ffbc87308d8df3d3121%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504801203988045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ROSclecKkfu2km3YeeM7sZK%2FP%2BcC8BajHSxJXQQCRw%3D&reserved=0

Alex


That's aligned with my expectations then.

I can take a peek at the branch and help review the patches.

Regards,
Nicholas Kazlauskas





Regards,
Nicholas Kazlauskas


   return false;
   }




___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cnicholas.kazlauskas%40amd.com%7Cf259e9290b0e4ffbc87308d8df3d3121%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504801203988045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BbwO5oOXuXFWD%2F8qNTygROj%2B9ZItRsXJb1U7ilcICh4%3D&reserved=0


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

Re: [PATCH 3/6] amd/display: fail on cursor plane without an underlying plane

[Kazlauskas, Nicholas]

On 2021-03-08 3:18 p.m., Daniel Vetter wrote:

On Fri, Mar 5, 2021 at 10:24 AM Michel Dänzer  wrote:


On 2021-03-04 7:26 p.m., Kazlauskas, Nicholas wrote:

On 2021-03-04 10:35 a.m., Michel Dänzer wrote:

On 2021-03-04 4:09 p.m., Kazlauskas, Nicholas wrote:

On 2021-03-04 4:05 a.m., Michel Dänzer wrote:

On 2021-03-03 8:17 p.m., Daniel Vetter wrote:

On Wed, Mar 3, 2021 at 5:53 PM Michel Dänzer 
wrote:


Moreover, in the same scenario plus an overlay plane enabled with a
HW cursor compatible format, if the FB bound to the overlay plane is
destroyed, the common DRM code will attempt to disable the overlay
plane, but dm_check_crtc_cursor will reject that now. I can't
remember
exactly what the result is, but AFAIR it's not pretty.


CRTC gets disabled instead. That's why we went with the "always
require primary plane" hack. I think the only solution here would be
to enable the primary plane (but not in userspace-visible state, so
this needs to be done in the dc derived state objects only) that scans
out black any time we're in such a situation with cursor with no
planes.


This is about a scenario described by Nicholas earlier:

Cursor Plane - ARGB

Overlay Plane - ARGB Desktop/UI with cutout for video

Primary Plane - NV12 video

And destroying the FB bound to the overlay plane. The fallback to
disable
the CRTC in atomic_remove_fb only kicks in for the primary plane, so it
wouldn't in this case and would fail. Which would in turn trigger the
WARN in drm_framebuffer_remove (and leave the overlay plane scanning
out
from freed memory?).


The cleanest solution might be not to allow any formats incompatible
with
the HW cursor for the primary plane.


Legacy X userspace doesn't use overlays but Chrome OS does.

This would regress ChromeOS MPO support because it relies on the NV12
video plane being on the bottom.


Could it use the NV12 overlay plane below the ARGB primary plane?


Plane ordering was previously undefined in DRM so we have userspace that
assumes overlays are on top.


They can still be by default?


Today we have the z-order property in DRM that defines where it is in
the stack, so technically it could but we'd also be regressing existing
behavior on Chrome OS today.


That's unfortunate, but might be the least bad choice overall.

BTW, doesn't Chrome OS try to disable the ARGB overlay plane while there are no 
UI elements to display? If it does, this series might break it anyway (if the 
cursor plane can be enabled while the ARGB overlay plane is off).



When ChromeOS disables MPO it doesn't do it plane by plane, it does it
in one go from NV12+ARGB -> ARGB8.


Even so, we cannot expect all user space to do the same, and we cannot
allow any user space to trigger a WARN and scanout from freed memory.


The WARN doesn't trigger because there's still a reference on the FB -


The WARN triggers if atomic_remove_fb returns an error, which is the case if it can't 
disable an overlay plane. I actually hit this with IGT tests while working on 
b836a274b797 "drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC 
is" (I initially tried allowing the cursor plane to be enabled together with an 
overlay plane while the primary plane is off).


the reference held by DRM since it's still scanning out the overlay.
Userspace can't reclaim this memory with another buffer allocation
because it's still in use.


Good point, so at least there's no scanout of freed memory. Even so, the 
overlay plane continues displaying contents which user space apparently doesn't 
want to be displayed anymore.


Hm I do wonder how much we need to care for this. If you use planes,
you better use TEST_ONLY in atomic to it's full extend (including
cursor, if that's a real plane, which it is for every driver except
msm/mdp4). If userspace screws this up and worse, shuts of planes with
an RMFB, I think it's not entirely unreasonable to claim that it
should keep the pieces.

So maybe we should refine the WARN_ON to not trigger if other planes
than crtc->primary and crtc->cursor are enabled right now?


It's a little odd that a disable commit can fail, but I don't think
there's anything in DRM core that specifies that this can't happen for
planes.


I'd say it's more than just a little odd. :) Being unable to disable an overlay 
plane seems very surprising, and could make it tricky for user space (not to 
mention core DRM code like atomic_remove_fb) to find a solution.

I'd suggest the amdgpu DM code should rather virtualize the KMS API planes 
somehow such that an overlay plane can always be disabled. While this might 
incur some short-term pain, it will likely save more pain overall in the long 
term.


Yeah I think this amd dc cursor problem is the first case where
removing a plane can make things worse.

Since the hw is what it is, ca

Re: [PATCH] drm/amdgpu: add DMUB outbox event IRQ source define/complete/debug flag

[Kazlauskas, Nicholas]

On 2021-03-31 11:21 p.m., Jude Shih wrote:

[Why & How]
We use outbox interrupt that allows us to do the AUX via DMUB
Therefore, we need to add some irq source related definition
in the header files;
Also, I added debug flag that allows us to turn it on/off
for testing purpose.


Missing your signed-off-by here, please recommit with

git commit --amend --sign


---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 2 +-
  drivers/gpu/drm/amd/include/amd_shared.h  | 3 ++-
  drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h | 2 ++
  4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 963ecfd84347..479c8a28a3a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -923,6 +923,7 @@ struct amdgpu_device {
struct amdgpu_irq_src   pageflip_irq;
struct amdgpu_irq_src   hpd_irq;
struct amdgpu_irq_src   dmub_trace_irq;
+   struct amdgpu_irq_src   outbox_irq;
  
  	/* rings */

u64 fence_context;
@@ -1077,6 +1078,7 @@ struct amdgpu_device {
  
  	boolin_pci_err_recovery;

struct pci_saved_state  *pci_state;
+   struct completion dmub_aux_transfer_done;
  };
  
  static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6a06234dbcad..0b88e13f5a7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -159,7 +159,7 @@ int amdgpu_smu_pptable_id = -1;
   * PSR (bit 3) disabled by default
   */
  uint amdgpu_dc_feature_mask = 2;
-uint amdgpu_dc_debug_mask;
+uint amdgpu_dc_debug_mask = 0x10;


If this is intended to be enabled by default then it shouldn't be a 
debug flag. Please either leave the default alone or fully switch over 
to DMCUB AUX support for ASIC that support it.


If you don't already have a check from driver to DMCUB firmware to 
ensure that the firmware itself supports it you'd need that as well - 
users can be running older firmware (like the firmware that originally 
released with DCN2.1/DCN3.0 support) and that wouldn't support this feature.


My recommendation:
- Add a command to check for DMUB AUX capability or add bits to the 
metadata to indicate that the firmware does support it
- Assume that the DMUB AUX implementation is solid and a complete 
replacement for existing AUX support on firmware that does support it
- Add a debug flag like DC_DISABLE_DMUB_AUX for optionally debugging 
issues if they arise



  int amdgpu_async_gfx_ring = 1;
  int amdgpu_mcbp;
  int amdgpu_discovery = -1;
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
b/drivers/gpu/drm/amd/include/amd_shared.h
index 43ed6291b2b8..097672cc78a1 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -227,7 +227,8 @@ enum DC_DEBUG_MASK {
DC_DISABLE_PIPE_SPLIT = 0x1,
DC_DISABLE_STUTTER = 0x2,
DC_DISABLE_DSC = 0x4,
-   DC_DISABLE_CLOCK_GATING = 0x8
+   DC_DISABLE_CLOCK_GATING = 0x8,
+   DC_ENABLE_DMUB_AUX = 0x10,
  };
  
  enum amd_dpm_forced_level;

diff --git a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h 
b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
index e2bffcae273a..754170a86ea4 100644
--- a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
+++ b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
@@ -1132,5 +1132,7 @@
  
  #define DCN_1_0__SRCID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   0x68

  #define DCN_1_0__CTXID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   6
+#define DCN_1_0__SRCID__DMCUB_OUTBOX_LOW_PRIORITY_READY_INT0x68 // 
DMCUB_IHC_outbox1_ready_int IHC_DMCUB_outbox1_ready_int_ack 
DMCUB_OUTBOX_LOW_PRIORITY_READY_INTERRUPT DISP_INTERRUPT_STATUS_CONTINUE24 
Level/Pulse
+#define DCN_1_0__CTXID__DMCUB_OUTBOX_LOW_PRIORITY_READY_INT8


This technically isn't on DCN_1_0 but I guess we've been using this file 
for all the DCNs.


I do wish this was labeled DCN_2_1 instead to make it more explicit but 
I guess this is fine for now.


Regards,
Nicholas Kazlauskas

  
  #endif // __IRQSRCS_DCN_1_0_H__




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

Re: [PATCH] drm/amdgpu: add DMUB outbox event IRQ source define/complete/debug flag

[Kazlauskas, Nicholas]

On 2021-04-06 9:40 a.m., Jude Shih wrote:

[Why & How]
We use outbox interrupt that allows us to do the AUX via DMUB
Therefore, we need to add some irq source related definition
in the header files;
Also, I added debug flag that allows us to turn it on/off
for testing purpose.

Signed-off-by: Jude Shih 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 2 ++
  drivers/gpu/drm/amd/include/amd_shared.h  | 3 ++-
  drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h | 2 ++
  3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 963ecfd84347..7e64fc5e0dcd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -923,6 +923,7 @@ struct amdgpu_device {
struct amdgpu_irq_src   pageflip_irq;
struct amdgpu_irq_src   hpd_irq;
struct amdgpu_irq_src   dmub_trace_irq;
+   struct amdgpu_irq_src   dmub_outbox_irq;
  
  	/* rings */

u64 fence_context;
@@ -1077,6 +1078,7 @@ struct amdgpu_device {
  
  	boolin_pci_err_recovery;

struct pci_saved_state  *pci_state;
+   struct completion dmub_aux_transfer_done;


Does this completion need to be on the amdgpu device itself?

I would prefer if we keep this as needed within DM itself if possible.


  };
  
  static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)

diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
b/drivers/gpu/drm/amd/include/amd_shared.h
index 43ed6291b2b8..097672cc78a1 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -227,7 +227,8 @@ enum DC_DEBUG_MASK {
DC_DISABLE_PIPE_SPLIT = 0x1,
DC_DISABLE_STUTTER = 0x2,
DC_DISABLE_DSC = 0x4,
-   DC_DISABLE_CLOCK_GATING = 0x8
+   DC_DISABLE_CLOCK_GATING = 0x8,
+   DC_ENABLE_DMUB_AUX = 0x10,


My problem with still leaving this as DC_ENABLE_DMUB_AUX is we shouldn't 
require the user to have to flip this on by default later. I think I'd 
prefer this still as a DISABLE option if we want to leave it for users 
to debug any potential issues.


If there's no value in having end users debug issues by setting this bit 
then we should keep it as a dc->debug default in DCN resource.


Regards,
Nicholas Kazlauskas


  };
  
  enum amd_dpm_forced_level;

diff --git a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h 
b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
index e2bffcae273a..754170a86ea4 100644
--- a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
+++ b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
@@ -1132,5 +1132,7 @@
  
  #define DCN_1_0__SRCID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   0x68

  #define DCN_1_0__CTXID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   6
+#define DCN_1_0__SRCID__DMCUB_OUTBOX_LOW_PRIORITY_READY_INT0x68 // 
DMCUB_IHC_outbox1_ready_int IHC_DMCUB_outbox1_ready_int_ack 
DMCUB_OUTBOX_LOW_PRIORITY_READY_INTERRUPT DISP_INTERRUPT_STATUS_CONTINUE24 
Level/Pulse
+#define DCN_1_0__CTXID__DMCUB_OUTBOX_LOW_PRIORITY_READY_INT8
  
  #endif // __IRQSRCS_DCN_1_0_H__




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

Re: [PATCH] drm/amdgpu: add DMUB outbox event IRQ source define/complete/debug flag

[Kazlauskas, Nicholas]

On 2021-04-06 10:22 a.m., Shih, Jude wrote:

[AMD Official Use Only - Internal Distribution Only]

Hi Nicholas,

Does this completion need to be on the amdgpu device itself?

I would prefer if we keep this as needed within DM itself if possible.

=> do you mean move it to amdgpu_display_manager in amdgpu_dm.h as global 
variable?


There's a amdgpu_display_manager per device, but yes, it should be 
contained in there if possible since it's display code.




My problem with still leaving this as DC_ENABLE_DMUB_AUX is we shouldn't 
require the user to have to flip this on by default later. I think I'd prefer 
this still as a DISABLE option if we want to leave it for users to debug any 
potential issues.
=> do you mean DC_ENABLE_DMUB_AUX = 0x10 => DC_DISABLE_DMUB_AUX = 0x10
and amdgpu_dc_debug_mask = 0x10 as default to turn it off?


Don't modify the default debug mask and leave it alone. We can still 
have DC_DISABLE_DMUB_AUX = 0x10 as a user debug option if they have 
firmware that supports this.


Flag or not, we need a mechanism from driver to firmware to query 
whether the firmware supports it in the first place. It's not sufficient 
to fully control this feature with just a debug flag, there needs to be 
a cap check regardless with the firmware for support.


Older firmware won't implement this check and therefore won't enable the 
feature.


Newer (or test) firmware could enable this feature and report back to 
driver that it does support it.


Driver can then decide to enable this based on 
dc->debug.dmub_aux_support or something similar to that - it can be 
false or ASIC that we won't be supporting this on, but for ASIC that we 
do we can leave it off by default until it's production ready.


For developer testing we can hardcode the flag = true, I think the DC 
debug flags here in AMDGPU base driver only have value if we want 
general end user or validation to use this to debug potential issues.


Regards,
Nicholas Kazlauskas



Thanks,

Best Regards,

Jude

-Original Message-
From: Kazlauskas, Nicholas 
Sent: Tuesday, April 6, 2021 10:04 PM
To: Shih, Jude ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Lin, Wayne ; 
Hung, Cruise 
Subject: Re: [PATCH] drm/amdgpu: add DMUB outbox event IRQ source 
define/complete/debug flag

On 2021-04-06 9:40 a.m., Jude Shih wrote:

[Why & How]
We use outbox interrupt that allows us to do the AUX via DMUB
Therefore, we need to add some irq source related definition in the
header files; Also, I added debug flag that allows us to turn it
on/off for testing purpose.

Signed-off-by: Jude Shih 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 2 ++
   drivers/gpu/drm/amd/include/amd_shared.h  | 3 ++-
   drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h | 2 ++
   3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 963ecfd84347..7e64fc5e0dcd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -923,6 +923,7 @@ struct amdgpu_device {
struct amdgpu_irq_src   pageflip_irq;
struct amdgpu_irq_src   hpd_irq;
struct amdgpu_irq_src   dmub_trace_irq;
+   struct amdgpu_irq_src   dmub_outbox_irq;
   
   	/* rings */

u64 fence_context;
@@ -1077,6 +1078,7 @@ struct amdgpu_device {
   
   	boolin_pci_err_recovery;

struct pci_saved_state  *pci_state;
+   struct completion dmub_aux_transfer_done;


Does this completion need to be on the amdgpu device itself?

I would prefer if we keep this as needed within DM itself if possible.


   };
   
   static inline struct amdgpu_device *drm_to_adev(struct drm_device

*ddev) diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_shared.h
index 43ed6291b2b8..097672cc78a1 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -227,7 +227,8 @@ enum DC_DEBUG_MASK {
DC_DISABLE_PIPE_SPLIT = 0x1,
DC_DISABLE_STUTTER = 0x2,
DC_DISABLE_DSC = 0x4,
-   DC_DISABLE_CLOCK_GATING = 0x8
+   DC_DISABLE_CLOCK_GATING = 0x8,
+   DC_ENABLE_DMUB_AUX = 0x10,


My problem with still leaving this as DC_ENABLE_DMUB_AUX is we shouldn't 
require the user to have to flip this on by default later. I think I'd prefer 
this still as a DISABLE option if we want to leave it for users to debug any 
potential issues.

If there's no value in having end users debug issues by setting this bit then we 
should keep it as a dc->debug default in DCN resource.

Regards,
Nicholas Kazlauskas


   };
   
   enum amd_dpm_forced_level;

diff --git a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
i

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

[Kazlauskas, Nicholas]

On 2021-04-22 7:20 p.m., Harry Wentland wrote:

[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.

Signed-off-by: Harry Wentland 
Change-Id: I5e951f95fc87c86517b9ea6e094d73603184f00b


Drop the Change-ID on submit.


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
  1 file changed, 7 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 4b3b9599aaf7..99fd555ebb91 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2825,6 +2825,13 @@ 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;
  
+

+   if (state->fb &&
+   state->fb->format->format == DRM_FORMAT_NV12 &&
+   (scaling_info->src_rect.x != 0 ||
+scaling_info->src_rect.y != 0))
+   return -EINVAL;
+


Would like to see a comment in the source code similar to what's 
explained in the commit message so if people skim through the code they 
understand some of the background on this.


I'd also like to know if this is generic across all DCN or specific to 
DCN1. For now at least we can disable it generically I think.


With the commit message updated and source commented this patch is:

Reviewed-by: Nicholas Kazlauskas 


scaling_info->src_rect.width = state->src_w >> 16;
if (scaling_info->src_rect.width == 0)
return -EINVAL;



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

Re: [PATCH] drm/amd/display: Clear dc remote sinks on MST disconnect

[Kazlauskas, Nicholas]

On 2020-11-26 9:31 a.m., Aurabindo Pillai wrote:

[Why&How]
Recent changes to upstream mst code remove the callback which
cleared the internal state for mst. Move the missing functionality
that was previously called through the destroy call back for mst connector
destroy

Signed-off-by: Aurabindo Pillai 
Signed-off-by: Eryk Brol 
---
  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 22 +--
  drivers/gpu/drm/amd/display/dc/dm_helpers.h   |  2 +-
  2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index b7d7ec3ba00d..d8b0f07deaf2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -418,9 +418,10 @@ bool dm_helpers_dp_mst_start_top_mgr(
  
  void dm_helpers_dp_mst_stop_top_mgr(

struct dc_context *ctx,
-   const struct dc_link *link)
+   struct dc_link *link)
  {
struct amdgpu_dm_connector *aconnector = link->priv;
+   uint8_t i;
  
  	if (!aconnector) {

DRM_ERROR("Failed to find connector for link!");
@@ -430,8 +431,25 @@ void dm_helpers_dp_mst_stop_top_mgr(
DRM_INFO("DM_MST: stopping TM on aconnector: %p [id: %d]\n",
aconnector, aconnector->base.base.id);
  
-	if (aconnector->mst_mgr.mst_state == true)

+   if (aconnector->mst_mgr.mst_state == true) {
drm_dp_mst_topology_mgr_set_mst(&aconnector->mst_mgr, false);
+
+   for (i = 0; i < MAX_SINKS_PER_LINK; i++) {
+   if (link->remote_sinks[i] == NULL)
+   continue;
+
+   if (link->remote_sinks[i]->sink_signal ==
+   SIGNAL_TYPE_DISPLAY_PORT_MST) {
+   dc_link_remove_remote_sink(link, 
link->remote_sinks[i]);


In general I think this patch looks fine, and you can have the:

Reviewed-by: Nicholas Kazlauskas 

But I think that this loop is redundant - dc_link_remove_remote_sink 
should be removing all the remote sinks. Not sure if remote_sinks can 
start at an index other than 0 though.


Regards,
Nicholas Kazlauskas


+
+   if (aconnector->dc_sink) {
+   dc_sink_release(aconnector->dc_sink);
+   aconnector->dc_sink = NULL;
+   
aconnector->dc_link->cur_link_settings.lane_count = 0;
+   }
+   }
+   }
+   } >   }
  
  bool dm_helpers_dp_read_dpcd(

diff --git a/drivers/gpu/drm/amd/display/dc/dm_helpers.h 
b/drivers/gpu/drm/amd/display/dc/dm_helpers.h
index b2cd8491c707..07e349b1067b 100644
--- a/drivers/gpu/drm/amd/display/dc/dm_helpers.h
+++ b/drivers/gpu/drm/amd/display/dc/dm_helpers.h
@@ -113,7 +113,7 @@ bool dm_helpers_dp_mst_start_top_mgr(
  
  void dm_helpers_dp_mst_stop_top_mgr(

struct dc_context *ctx,
-   const struct dc_link *link);
+   struct dc_link *link);
  /**
   * OS specific aux read callback.
   */



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

Re: [PATCH] drm/amd/display: turn DPMS off on mst connector unplug

[Kazlauskas, Nicholas]

On 2020-11-26 2:50 p.m., Aurabindo Pillai wrote:

[Why&How]

Set dpms off on the MST connector that was unplugged, for the side effect of
releasing some references held through deallocation of mst payload.

Signed-off-by: Aurabindo Pillai 
Signed-off-by: Eryk Brol 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 63 ++-
  1 file changed, 62 insertions(+), 1 deletion(-)

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 e213246e3f04..fc984cf6e316 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1984,6 +1984,64 @@ static void dm_gpureset_commit_state(struct dc_state 
*dc_state,
return;
  }
  
+static void dm_set_dpms_off(struct dc_link *link)

+{
+   struct {
+   struct dc_surface_update surface_updates[MAX_SURFACES];
+   struct dc_stream_update stream_update;
+   } * bundle;
+   struct dc_stream_state *stream_state;
+   struct dc_context *dc_ctx = link->ctx;
+   int i;
+
+   bundle = kzalloc(sizeof(*bundle), GFP_KERNEL);
+
+   if (!bundle) {
+   dm_error("Failed to allocate update bundle\n");
+   return;
+   }
+
+   bundle->stream_update.dpms_off = kzalloc(sizeof(bool), GFP_KERNEL);


You don't need to allocate memory for the bool. You can just use a local 
here, DC doesn't need it after the call ends.


I think the same should apply to the surface updates as well. I'm not 
entirely sure how much stack the bundle takes up for a single stream 
here but it should be small enough that we can leave it on the stack.



+
+   if (!bundle->stream_update.dpms_off) {
+   dm_error("Failed to allocate update bundle\n");
+   goto cleanup;
+   }
+
+   *bundle->stream_update.dpms_off = true;
+
+   for (i = 0; i< MAX_PIPES; i++) {
+   if (dc_ctx->dc->current_state->streams[i] == NULL)
+   continue;
+
+   if (dc_ctx->dc->current_state->streams[i]->link == link) {
+   stream_state = dc_ctx->dc->current_state->streams[i];
+   goto link_found;
+   }
+   }


We shouldn't be reading from dc->current_state directly in DM, it's 
essentially private state.


I think we should actually have a new helper here in dc_stream.h that's 
like:


struct dc_stream_state *dc_stream_find_from_link(const struct dc_link 
*link);


to replace this block of code.

Note that any time we touch current_state we also need to be locking - 
it looks like this function is missing the appropriate calls to:


mutex_lock(&adev->dm.dc_lock);
mutex_unlock(&adev->dm.dc_lock);

Regards,
Nicholas Kazlauskas



+
+   dm_error("Cannot find link associated with the stream to be 
disabled\n");
+   return;
+
+link_found:
+   if (stream_state == NULL) {
+   dm_error("Stream state associated with the link is NULL\n");
+   return;
+   }
+
+   bundle->stream_update.stream = stream_state;
+
+   dc_commit_updates_for_stream(stream_state->ctx->dc, 
bundle->surface_updates, 0,
+stream_state, &bundle->stream_update,
+stream_state->ctx->dc->current_state);
+
+   kfree(bundle->stream_update.dpms_off);
+cleanup:
+   kfree(bundle);
+
+   return;
+}
+
  static int dm_resume(void *handle)
  {
struct amdgpu_device *adev = handle;
@@ -2434,8 +2492,11 @@ static void handle_hpd_irq(void *param)
drm_kms_helper_hotplug_event(dev);
  
  	} else if (dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD)) {

-   amdgpu_dm_update_connector_after_detect(aconnector);
+   if (new_connection_type == dc_connection_none &&
+   aconnector->dc_link->type == dc_connection_none)
+   dm_set_dpms_off(aconnector->dc_link);
  
+		amdgpu_dm_update_connector_after_detect(aconnector);
  
  		drm_modeset_lock_all(dev);

dm_restore_drm_connector_state(dev, connector);



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

Re: [PATCH v2] drm/amd/display: turn DPMS off on mst connector unplug

[Kazlauskas, Nicholas]

On 2020-11-26 4:45 p.m., Aurabindo Pillai wrote:

[Why&How]

Set dpms off on the MST connector that was unplugged, for the side effect of
releasing some references held through deallocation of mst payload.

Signed-off-by: Aurabindo Pillai 
Signed-off-by: Eryk Brol 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 ++-
  drivers/gpu/drm/amd/display/dc/core/dc.c  | 17 ++
  drivers/gpu/drm/amd/display/dc/dc_stream.h|  1 +
  3 files changed, 50 insertions(+), 1 deletion(-)

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 e213246e3f04..6203cbf3ee33 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1984,6 +1984,34 @@ static void dm_gpureset_commit_state(struct dc_state 
*dc_state,
return;
  }
  
+static void dm_set_dpms_off(struct dc_link *link)

+{
+   struct dc_stream_state *stream_state;
+   struct amdgpu_dm_connector *aconnector = link->priv;
+   struct amdgpu_device *adev = drm_to_adev(aconnector->base.dev);
+   struct {
+   struct dc_surface_update surface_updates[MAX_SURFACES];


Let's remove the bundle and drop the surface_updates here. A 
surface_count of 0 should be sufficient to guard against NULL 
surface_updates array.



+   struct dc_stream_update stream_update;
+   } bundle = {0};
+   bool dpms_off = true;
+
+   bundle.stream_update.dpms_off = &dpms_off;
+
+   mutex_lock(&adev->dm.dc_lock);
+   stream_state = dc_stream_find_from_link(link);
+   mutex_unlock(&adev->dm.dc_lock);


This needs to be move under dc_commit_updates_for_stream(). It's not 
safe to call dc_commit_updates_for_stream while unlocked since it 
modifies global state.



+
+   if (stream_state == NULL) {
+   dm_error("Error finding stream state associated with link!\n");
+   return;
+   }
+
+   bundle.stream_update.stream = stream_state;
+   dc_commit_updates_for_stream(stream_state->ctx->dc, 
bundle.surface_updates, 0,
+stream_state, &bundle.stream_update,
+stream_state->ctx->dc->current_state);
+}
+
  static int dm_resume(void *handle)
  {
struct amdgpu_device *adev = handle;
@@ -2434,8 +2462,11 @@ static void handle_hpd_irq(void *param)
drm_kms_helper_hotplug_event(dev);
  
  	} else if (dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD)) {

-   amdgpu_dm_update_connector_after_detect(aconnector);
+   if (new_connection_type == dc_connection_none &&
+   aconnector->dc_link->type == dc_connection_none)
+   dm_set_dpms_off(aconnector->dc_link);
  
+		amdgpu_dm_update_connector_after_detect(aconnector);
  
  		drm_modeset_lock_all(dev);

dm_restore_drm_connector_state(dev, connector);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 903353389edb..7a2b2802faa2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2798,6 +2798,23 @@ struct dc_stream_state *dc_get_stream_at_index(struct dc 
*dc, uint8_t i)
return NULL;
  }
  
+struct dc_stream_state *dc_stream_find_from_link(const struct dc_link *link)

+{
+   uint8_t i;
+   struct dc_context *ctx = link->ctx;
+
+   for (i = 0; i< MAX_PIPES; i++) {
+   if (ctx->dc->current_state->streams[i] == NULL)
+   continue;


Drop the NULL check above and change MAX_PIPES to 
dc->current_state->stream_count.


Regards,
Nicholas Kazlauskas


+
+   if (ctx->dc->current_state->streams[i]->link == link) {
+   return ctx->dc->current_state->streams[i];
+   }
+   }
+
+   return NULL;
+}
+
  enum dc_irq_source dc_interrupt_to_irq_source(
struct dc *dc,
uint32_t src_id,
diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h 
b/drivers/gpu/drm/amd/display/dc/dc_stream.h
index bf090afc2f70..b7910976b81a 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
@@ -292,6 +292,7 @@ void dc_stream_log(const struct dc *dc, const struct 
dc_stream_state *stream);
  
  uint8_t dc_get_current_stream_count(struct dc *dc);

  struct dc_stream_state *dc_get_stream_at_index(struct dc *dc, uint8_t i);
+struct dc_stream_state *dc_stream_find_from_link(const struct dc_link *link);
  
  /*

   * Return the current frame counter.



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

Re: [PATCH v3] drm/amd/display: turn DPMS off on mst connector unplug

[Kazlauskas, Nicholas]

On 2020-11-26 7:18 p.m., Aurabindo Pillai wrote:

[Why&How]

Set dpms off on the MST connector that was unplugged, for the side effect of
releasing some references held through deallocation of mst payload.


Applies to non-MST now too, so the description and title should be updated.



Signed-off-by: Aurabindo Pillai 
Signed-off-by: Eryk Brol 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 31 ++-
  drivers/gpu/drm/amd/display/dc/core/dc.c  | 13 
  drivers/gpu/drm/amd/display/dc/dc_stream.h|  1 +
  3 files changed, 44 insertions(+), 1 deletion(-)

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 e213246e3f04..9966679d29e7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1984,6 +1984,32 @@ static void dm_gpureset_commit_state(struct dc_state 
*dc_state,
return;
  }
  
+static void dm_set_dpms_off(struct dc_link *link)

+{
+   struct dc_stream_state *stream_state;
+   struct amdgpu_dm_connector *aconnector = link->priv;
+   struct amdgpu_device *adev = drm_to_adev(aconnector->base.dev);
+   struct dc_stream_update stream_update = {0};


Please use a memset instead of a zero initializer here. Some compilers 
complain about that.



+   bool dpms_off = true;
+
+   stream_update.dpms_off = &dpms_off;
+
+   mutex_lock(&adev->dm.dc_lock);
+   stream_state = dc_stream_find_from_link(link);
+
+   if (stream_state == NULL) {
+   dm_error("Error finding stream state associated with link!\n");


This shouldn't be using a dm_error print here. a DRM_DEBUG_DRIVER would 
be better suited.


With these three items fixed the v4 of this patch will be:

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


+   mutex_unlock(&adev->dm.dc_lock);
+   return;
+   }
+
+   stream_update.stream = stream_state;
+   dc_commit_updates_for_stream(stream_state->ctx->dc, NULL, 0,
+stream_state, &stream_update,
+stream_state->ctx->dc->current_state);
+   mutex_unlock(&adev->dm.dc_lock);
+}
+
  static int dm_resume(void *handle)
  {
struct amdgpu_device *adev = handle;
@@ -2434,8 +2460,11 @@ static void handle_hpd_irq(void *param)
drm_kms_helper_hotplug_event(dev);
  
  	} else if (dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD)) {

-   amdgpu_dm_update_connector_after_detect(aconnector);
+   if (new_connection_type == dc_connection_none &&
+   aconnector->dc_link->type == dc_connection_none)
+   dm_set_dpms_off(aconnector->dc_link);
  
+		amdgpu_dm_update_connector_after_detect(aconnector);
  
  		drm_modeset_lock_all(dev);

dm_restore_drm_connector_state(dev, connector);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 903353389edb..58eb0d69873a 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2798,6 +2798,19 @@ struct dc_stream_state *dc_get_stream_at_index(struct dc 
*dc, uint8_t i)
return NULL;
  }
  
+struct dc_stream_state *dc_stream_find_from_link(const struct dc_link *link)

+{
+   uint8_t i;
+   struct dc_context *ctx = link->ctx;
+
+   for (i = 0; i < ctx->dc->current_state->stream_count; i++) {
+   if (ctx->dc->current_state->streams[i]->link == link)
+   return ctx->dc->current_state->streams[i];
+   }
+
+   return NULL;
+}
+
  enum dc_irq_source dc_interrupt_to_irq_source(
struct dc *dc,
uint32_t src_id,
diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h 
b/drivers/gpu/drm/amd/display/dc/dc_stream.h
index bf090afc2f70..b7910976b81a 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
@@ -292,6 +292,7 @@ void dc_stream_log(const struct dc *dc, const struct 
dc_stream_state *stream);
  
  uint8_t dc_get_current_stream_count(struct dc *dc);

  struct dc_stream_state *dc_get_stream_at_index(struct dc *dc, uint8_t i);
+struct dc_stream_state *dc_stream_find_from_link(const struct dc_link *link);
  
  /*

   * Return the current frame counter.



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

Re: [PATCH 2/2] drm/amd/display: add cursor pitch check

[Kazlauskas, Nicholas]

On 2020-12-02 4:09 p.m., Simon Ser wrote:

Replace the width check with a pitch check, which matches DM internals.
Add a new check to make sure the pitch (in pixels) matches the width.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 


Series is:

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +++
  1 file changed, 15 insertions(+), 4 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 9e328101187e..862a59703060 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8988,6 +8988,7 @@ static int dm_update_plane_state(struct dc *dc,
struct amdgpu_crtc *new_acrtc;
bool needs_reset;
int ret = 0;
+   unsigned int pitch;
  
  
  	new_plane_crtc = new_plane_state->crtc;

@@ -9021,15 +9022,25 @@ static int dm_update_plane_state(struct dc *dc,
return -EINVAL;
}
  
-			switch (new_plane_state->fb->width) {

+   /* Pitch in pixels */
+   pitch = new_plane_state->fb->pitches[0] / 
new_plane_state->fb->format->cpp[0];
+
+   if (new_plane_state->fb->width != pitch) {
+   DRM_DEBUG_ATOMIC("Cursor FB width %d doesn't match 
pitch %d",
+new_plane_state->fb->width,
+pitch);
+   return -EINVAL;
+   }
+
+   switch (pitch) {
case 64:
case 128:
case 256:
-   /* FB width is supported by cursor plane */
+   /* FB pitch is supported by cursor plane */
break;
default:
-   DRM_DEBUG_ATOMIC("Bad cursor FB width %d\n",
-new_plane_state->fb->width);
+   DRM_DEBUG_ATOMIC("Bad cursor FB pitch %d px\n",
+pitch);
return -EINVAL;
}
}



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

Re: [PATCH 2/2] drm/amd/display: check cursor FB is linear

[Kazlauskas, Nicholas]

On 2020-12-03 3:19 p.m., Simon Ser wrote:

Previously we accepted non-linear buffers for the cursor plane. This
results in bad output, DC validation failures and oops.

Make sure the FB uses a linear layout in the atomic check function.

The GFX8- check is inspired from ac_surface_set_bo_metadata in Mesa.
The GFX9+ check comes from convert_tiling_flags_to_modifier.

Signed-off-by: Simon Ser 
References: https://gitlab.freedesktop.org/drm/amd/-/issues/1390
Cc: Bas Nieuwenhuizen 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
---


Looks good to me, series is:

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +++
  1 file changed, 19 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 070bb55ec4e1..b46b188588b4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8978,7 +8978,10 @@ static int dm_check_cursor_fb(struct amdgpu_crtc 
*new_acrtc,
  struct drm_plane_state *new_plane_state,
  struct drm_framebuffer *fb)
  {
+   struct amdgpu_device *adev = drm_to_adev(new_acrtc->base.dev);
+   struct amdgpu_framebuffer *afb = to_amdgpu_framebuffer(fb);
unsigned int pitch;
+   bool linear;
  
  	if (fb->width > new_acrtc->max_cursor_width ||

fb->height > new_acrtc->max_cursor_height) {
@@ -9013,6 +9016,22 @@ static int dm_check_cursor_fb(struct amdgpu_crtc 
*new_acrtc,
return -EINVAL;
}
  
+	/* Core DRM takes care of checking FB modifiers, so we only need to

+* check tiling flags when the FB doesn't have a modifier. */
+   if (!(fb->flags & DRM_MODE_FB_MODIFIERS)) {
+   if (adev->family < AMDGPU_FAMILY_AI) {
+   linear = AMDGPU_TILING_GET(afb->tiling_flags, ARRAY_MODE) != 
DC_ARRAY_2D_TILED_THIN1 &&
+AMDGPU_TILING_GET(afb->tiling_flags, ARRAY_MODE) != 
DC_ARRAY_1D_TILED_THIN1 &&
+AMDGPU_TILING_GET(afb->tiling_flags, 
MICRO_TILE_MODE) == 0;
+   } else {
+   linear = AMDGPU_TILING_GET(afb->tiling_flags, 
SWIZZLE_MODE) == 0;
+   }
+   if (!linear) {
+   DRM_DEBUG_ATOMIC("Cursor FB not linear");
+   return -EINVAL;
+   }
+   }
+
return 0;
  }
  



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

Re: [PATCH] drm/amdgpu/disply: set num_crtc earlier

[Kazlauskas, Nicholas]

On 2020-12-04 9:30 a.m., Alex Deucher wrote:

To avoid a recently added warning:
  Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf (full crtc 
mask=0x7)
  WARNING: CPU: 3 PID: 439 at drivers/gpu/drm/drm_mode_config.c:617 
drm_mode_config_validate+0x178/0x200 [drm]
In this case the warning is harmless, but confusing to users.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209123
Signed-off-by: Alex Deucher 


Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 -
  1 file changed, 4 insertions(+), 5 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 313501cc39fc..1ec57bc798e2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1130,9 +1130,6 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
goto error;
}
  
-	/* Update the actual used number of crtc */

-   adev->mode_info.num_crtc = adev->dm.display_indexes_num;
-
/* create fake encoders for MST */
dm_dp_create_fake_mst_encoders(adev);
  
@@ -3364,6 +3361,10 @@ static int amdgpu_dm_initialize_drm_device(struct amdgpu_device *adev)

enum dc_connection_type new_connection_type = dc_connection_none;
const struct dc_plane_cap *plane;
  
+	dm->display_indexes_num = dm->dc->caps.max_streams;

+   /* Update the actual used number of crtc */
+   adev->mode_info.num_crtc = adev->dm.display_indexes_num;
+
link_cnt = dm->dc->caps.max_links;
if (amdgpu_dm_mode_config_init(dm->adev)) {
DRM_ERROR("DM: Failed to initialize mode config\n");
@@ -3425,8 +3426,6 @@ static int amdgpu_dm_initialize_drm_device(struct 
amdgpu_device *adev)
goto fail;
}
  
-	dm->display_indexes_num = dm->dc->caps.max_streams;

-
/* loops over all connectors on the board */
for (i = 0; i < link_cnt; i++) {
struct dc_link *link = NULL;



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

Re: [PATCH 2/2] drm/amd/display: add S/G support for Vangogh

[Kazlauskas, Nicholas]

On 2020-12-07 3:03 p.m., roman...@amd.com wrote:

From: Roman Li 

[Why]
Scatter/gather feature is supported on Vangogh.

[How]
Add GTT domain support for Vangogh to enable
display buffers in system memory.

Signed-off-by: Roman Li 


Series is:

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 63401bc8f37b..a638709e9c92 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -526,6 +526,7 @@ uint32_t amdgpu_display_supported_domains(struct 
amdgpu_device *adev,
domain |= AMDGPU_GEM_DOMAIN_GTT;
break;
case CHIP_RENOIR:
+   case CHIP_VANGOGH:
domain |= AMDGPU_GEM_DOMAIN_GTT;
break;
  



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

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

[Kazlauskas, Nicholas]

On 2020-12-11 12:08 a.m., Shashank Sharma wrote:


On 10/12/20 11:20 pm, Aurabindo Pillai wrote:

On Thu, 2020-12-10 at 18:29 +0530, Shashank Sharma wrote:

On 10/12/20 8:15 am, Aurabindo Pillai wrote:

[Why&How]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes for common freesync frame rates.
When commiting these mode changes, a full modeset is not needed.
If the change in only in the front porch timing value, skip full
modeset and continue using the same stream.

Signed-off-by: Aurabindo Pillai <
aurabindo.pil...@amd.com
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 169
--
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
  2 files changed, 153 insertions(+), 17 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 f699a3d41cad..c8c72887906a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -217,6 +217,9 @@ static bool amdgpu_dm_psr_disable_all(struct
amdgpu_display_manager *dm);
  static const struct drm_format_info *
  amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
  
+static bool

+is_timing_unchanged_for_freesync(struct drm_crtc_state
*old_crtc_state,
+struct drm_crtc_state
*new_crtc_state);
  /*
   * dm_vblank_get_counter
   *
@@ -5096,8 +5099,11 @@ copy_crtc_timing_for_drm_display_mode(const
struct drm_display_mode *src_mode,
  static void
  decide_crtc_timing_for_drm_display_mode(struct drm_display_mode
*drm_mode,
const struct drm_display_mode
*native_mode,
-   bool scale_enabled)
+   bool scale_enabled, bool
fs_mode)
  {
+   if (fs_mode)
+   return;

so we are adding an input flag just so that we can return from the
function at top ? How about adding this check at the caller without
changing the function parameters ?

Will fix this.


+
if (scale_enabled) {
copy_crtc_timing_for_drm_display_mode(native_mode,
drm_mode);
} else if (native_mode->clock == drm_mode->clock &&
@@ -5241,6 +5247,24 @@ get_highest_freesync_mode(struct
amdgpu_dm_connector *aconnector,
return m_high;
  }
  
+static bool is_freesync_video_mode(struct drm_display_mode *mode,

+  struct amdgpu_dm_connector
*aconnector)
+{
+   struct drm_display_mode *high_mode;
+

I thought we were adding a string "_FSV" in the end for the mode-

name, why can't we check that instead of going through the whole

list of modes again ?

Actually I only added _FSV to distinguish the newly added modes easily.
On second thoughts, I'm not sure if there are any userspace
applications that might depend on parsing the mode name, for maybe to
print the resolution. I think its better not to break any such
assumptions if they do exist by any chance. I think I'll just remove
_FSV from the mode name. We already set DRM_MODE_TYPE_DRIVER for
userspace to recognize these additional modes, so it shouldnt be a
problem.


Actually, I am rather happy with this, as in when we want to test out this 
feature with a IGT type stuff, or if a userspace wants to utilize this option 
in any way, this method of differentiation would be useful. DRM_MODE_DRIVER is 
being used by some other places apart from freesync, so it might not be a 
unique identifier. So my recommendation would be to keep this.

My comment was, if we have already parsed the whole connector list once, and added the 
mode, there should be a better way of doing it instead of checking it again by calling 
"get_highest_freesync_mod"

Some things I can think on top of my mind would be:

- Add a read-only amdgpu driver private flag (not DRM flag), while adding a new 
freesync mode, which will uniquely identify if a mode is FS mode. On modeset, 
you have to just check that flag.

- As we are not handling a lot of modes, cache the FS modes locally and check 
only from that DB (instead of the whole modelist)

- Cache the VIC of the mode (if available) and then look into the VIC table 
(not sure if detailed modes provide VIC, like CEA-861 modes)

or something better than this.

- Shashank


I'd rather we not make mode name part of a UAPI or to identify a 
"FreeSync mode". This is already behind a module option and from the 
driver's perspective we only need the timing to understand whether or 
not we can do an optimized modeset using FreeSync into it. Driver 
private flags can optimize the check away but it's only a few 
comparisons so I don't see much benefit.


We will always need to reference the original preferred mode regardless 
of how the FreeSync mode is identified since there could be a case where 
we're enabling the CRTC from disabled -> enabled. The display was 
previously blank and we need to reprogram the OTG timing to the mode 
that doesn't ha

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

[Kazlauskas, Nicholas]

On 2020-12-11 10:35 a.m., Shashank Sharma wrote:


On 11/12/20 8:19 pm, Kazlauskas, Nicholas wrote:

On 2020-12-11 12:08 a.m., Shashank Sharma wrote:

On 10/12/20 11:20 pm, Aurabindo Pillai wrote:

On Thu, 2020-12-10 at 18:29 +0530, Shashank Sharma wrote:

On 10/12/20 8:15 am, Aurabindo Pillai wrote:

[Why&How]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes for common freesync frame rates.
When commiting these mode changes, a full modeset is not needed.
If the change in only in the front porch timing value, skip full
modeset and continue using the same stream.

Signed-off-by: Aurabindo Pillai <
aurabindo.pil...@amd.com
---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 169
--
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
   2 files changed, 153 insertions(+), 17 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 f699a3d41cad..c8c72887906a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -217,6 +217,9 @@ static bool amdgpu_dm_psr_disable_all(struct
amdgpu_display_manager *dm);
   static const struct drm_format_info *
   amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
   
+static bool

+is_timing_unchanged_for_freesync(struct drm_crtc_state
*old_crtc_state,
+struct drm_crtc_state
*new_crtc_state);
   /*
* dm_vblank_get_counter
*
@@ -5096,8 +5099,11 @@ copy_crtc_timing_for_drm_display_mode(const
struct drm_display_mode *src_mode,
   static void
   decide_crtc_timing_for_drm_display_mode(struct drm_display_mode
*drm_mode,
const struct drm_display_mode
*native_mode,
-   bool scale_enabled)
+   bool scale_enabled, bool
fs_mode)
   {
+   if (fs_mode)
+   return;

so we are adding an input flag just so that we can return from the
function at top ? How about adding this check at the caller without
changing the function parameters ?

Will fix this.


+
if (scale_enabled) {
copy_crtc_timing_for_drm_display_mode(native_mode,
drm_mode);
} else if (native_mode->clock == drm_mode->clock &&
@@ -5241,6 +5247,24 @@ get_highest_freesync_mode(struct
amdgpu_dm_connector *aconnector,
return m_high;
   }
   
+static bool is_freesync_video_mode(struct drm_display_mode *mode,

+  struct amdgpu_dm_connector
*aconnector)
+{
+   struct drm_display_mode *high_mode;
+

I thought we were adding a string "_FSV" in the end for the mode-

name, why can't we check that instead of going through the whole

list of modes again ?

Actually I only added _FSV to distinguish the newly added modes easily.
On second thoughts, I'm not sure if there are any userspace
applications that might depend on parsing the mode name, for maybe to
print the resolution. I think its better not to break any such
assumptions if they do exist by any chance. I think I'll just remove
_FSV from the mode name. We already set DRM_MODE_TYPE_DRIVER for
userspace to recognize these additional modes, so it shouldnt be a
problem.

Actually, I am rather happy with this, as in when we want to test out this 
feature with a IGT type stuff, or if a userspace wants to utilize this option 
in any way, this method of differentiation would be useful. DRM_MODE_DRIVER is 
being used by some other places apart from freesync, so it might not be a 
unique identifier. So my recommendation would be to keep this.

My comment was, if we have already parsed the whole connector list once, and added the 
mode, there should be a better way of doing it instead of checking it again by calling 
"get_highest_freesync_mod"

Some things I can think on top of my mind would be:

- Add a read-only amdgpu driver private flag (not DRM flag), while adding a new 
freesync mode, which will uniquely identify if a mode is FS mode. On modeset, 
you have to just check that flag.

- As we are not handling a lot of modes, cache the FS modes locally and check 
only from that DB (instead of the whole modelist)

- Cache the VIC of the mode (if available) and then look into the VIC table 
(not sure if detailed modes provide VIC, like CEA-861 modes)

or something better than this.

- Shashank

I'd rather we not make mode name part of a UAPI or to identify a
"FreeSync mode". This is already behind a module option and from the
driver's perspective we only need the timing to understand whether or
not we can do an optimized modeset using FreeSync into it. Driver
private flags can optimize the check away but it's only a few
comparisons so I don't see much benefit.

The module parameter is just to control the addition of freesync modes or not, 
but that doesn&

Re: [PATCH] drm/amd/display: Fix memory leaks in S3 resume

[Kazlauskas, Nicholas]

Reviewed-by: Nicholas Kazlauskas 

Feel free to merge.

Regards,
Nicholas Kazlauskas

On 2020-12-21 11:45 a.m., Deucher, Alexander wrote:

[AMD Official Use Only - Internal Distribution Only]


This leak is still present.  Can we get this applied?

Acked-by: Alex Deucher 

*From:* Wang, Chao-kai (Stylon) 
*Sent:* Tuesday, November 10, 2020 2:49 AM
*To:* amd-gfx@lists.freedesktop.org 
*Cc:* Wang, Chao-kai (Stylon) ; Kazlauskas, 
Nicholas ; Deucher, Alexander 
; Wentland, Harry 

*Subject:* [PATCH] drm/amd/display: Fix memory leaks in S3 resume
EDID parsing in S3 resume pushes new display modes
to probed_modes list but doesn't consolidate to actual
mode list. This creates a race condition when
amdgpu_dm_connector_ddc_get_modes() re-initializes the
list head without walking the list and results in  memory leak.

Signed-off-by: Stylon Wang 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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 0b6adf23d316..715e0bd489f8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2337,7 +2337,8 @@ void amdgpu_dm_update_connector_after_detect(

  drm_connector_update_edid_property(connector,
 
aconnector->edid);

-   drm_add_edid_modes(connector, aconnector->edid);
+   aconnector->num_modes = 
drm_add_edid_modes(connector, aconnector->edid);

+   drm_connector_list_update(connector);

  if (aconnector->dc_link->aux_mode)
  
drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,

--
2.25.1



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

Re: [PATCH] drm/amdgpu: Do not change amdgpu framebuffer format during page flip

[Kazlauskas, Nicholas]

On 2020-12-21 10:18 p.m., Zhan Liu wrote:

[Why]
Driver cannot change amdgpu framebuffer (afb) format while doing
page flip. Force system doing so will cause ioctl error, and result in
breaking several functionalities including FreeSync.

If afb format is forced to change during page flip, following message
will appear in dmesg.log:

"[drm:drm_mode_page_flip_ioctl [drm]]
Page flip is not allowed to change frame buffer format."

[How]
Do not change afb format while doing page flip. It is okay to check
whether afb format is valid here, however, forcing afb format change
shouldn't happen here.

Signed-off-by: Zhan Liu 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index a638709e9c92..0efebd592b65 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -831,8 +831,6 @@ static int convert_tiling_flags_to_modifier(struct 
amdgpu_framebuffer *afb)
modifier);
if (!format_info)
return -EINVAL;
-
-   afb->base.format = format_info;


Adding Bas for comment since he added the modifiers conversion, but I'll 
leave my own thoughts below.


This patch is a NAK from me - the framebuffer is still expected to be in 
a specific format/tiling configuration and ignoring the incoming format 
doesn't resolve the problem.


The problem is that the legacy page IOCTL has this check in the first 
place expecting that no driver is capable of performing this action.


This is not the case for amdgpu (be it DC enabled or not), so I think 
it's best to have a driver cap here or some new driver hook to validate 
that the flip is valid.


This is legacy code, and in the shared path, so I don't know how others 
in the list feel about modifying this but I think we do expect that 
legacy userspace can do this from the X side of things.


I recall seeing this happen going from DCC disabled to non DCC enabled 
buffers and some of this functionality being behind a version check in 
xf86-video-amdgpu.


Regards,
Nicholas Kazlauskas


}
}
  



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

Re: [PATCH 1/3] drm/amd/display: Add module parameter for freesync video mode

[Kazlauskas, Nicholas]

On 2020-12-09 9:45 p.m., Aurabindo Pillai wrote:

[Why&How]
Adds a module parameter to enable experimental freesync video mode modeset
optimization. Enabling this mode allows the driver to skip a full modeset when
freesync compatible modes are requested by the userspace. This paramters also
adds some standard modes based on the connected monitor's VRR range.

Signed-off-by: Aurabindo Pillai 


Reviewed-by: Nicholas Kazlauskas 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 
  2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 83ac06a3ec05..efbfee93c359 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -177,6 +177,7 @@ extern int amdgpu_gpu_recovery;
  extern int amdgpu_emu_mode;
  extern uint amdgpu_smu_memory_pool_size;
  extern uint amdgpu_dc_feature_mask;
+extern uint amdgpu_exp_freesync_vid_mode;
  extern uint amdgpu_dc_debug_mask;
  extern uint amdgpu_dm_abm_level;
  extern struct amdgpu_mgpu_info mgpu_info;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index b2a1dd7581bf..ece51ecd53d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -158,6 +158,7 @@ int amdgpu_mes;
  int amdgpu_noretry = -1;
  int amdgpu_force_asic_type = -1;
  int amdgpu_tmz;
+uint amdgpu_exp_freesync_vid_mode;
  int amdgpu_reset_method = -1; /* auto */
  int amdgpu_num_kcq = -1;
  
@@ -786,6 +787,17 @@ module_param_named(abmlevel, amdgpu_dm_abm_level, uint, 0444);

  MODULE_PARM_DESC(tmz, "Enable TMZ feature (-1 = auto, 0 = off (default), 1 = 
on)");
  module_param_named(tmz, amdgpu_tmz, int, 0444);
  
+/**

+ * DOC: experimental_freesync_video (uint)
+ * Enabled the optimization to adjust front porch timing to achieve seamless 
mode change experience
+ * when setting a freesync supported mode for which full modeset is not needed.
+ * The default value: 0 (off).
+ */
+MODULE_PARM_DESC(
+   experimental_freesync_video,
+   "Enable freesync modesetting optimization feature (0 = off (default), 1 = 
on)");
+module_param_named(experimental_freesync_video, amdgpu_exp_freesync_vid_mode, 
uint, 0444);
+
  /**
   * DOC: reset_method (int)
   * GPU reset method (-1 = auto (default), 0 = legacy, 1 = mode0, 2 = mode1, 3 
= mode2, 4 = baco)



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

Re: [PATCH v2 2/3] drm/amd/display: Add freesync video modes based on preferred modes

[Kazlauskas, Nicholas]

On 2020-12-11 12:54 a.m., Shashank Sharma wrote:


On 11/12/20 12:18 am, Aurabindo Pillai wrote:

[Why&How]
If experimental freesync video mode module parameter is enabled, add
few extra display modes into the driver's mode list corresponding to common
video frame rates. When userspace sets these modes, no modeset will be
performed (if current mode was one of freesync modes or the base freesync mode
based off which timings have been generated for the rest of the freesync modes)
since these modes only differ from the base mode with front porch timing.

Signed-off-by: Aurabindo Pillai 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 167 ++
  1 file changed, 167 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 fbff8d693e03..d15453b400d2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5178,6 +5178,54 @@ static void dm_enable_per_frame_crtc_master_sync(struct 
dc_state *context)
set_master_stream(context->streams, context->stream_count);
  }
  
+static struct drm_display_mode *

+get_highest_refresh_rate_mode(struct amdgpu_dm_connector *aconnector,
+ bool use_probed_modes)
+{
+   struct drm_display_mode *m, *m_high = NULL;

I would prefer m_high to be renamed as m_pref, indicating it's the preferred 
mode

+   u16 current_refresh, highest_refresh;
+   struct list_head *list_head = use_probed_modes ?
+   
&aconnector->base.probed_modes :
+   &aconnector->base.modes;
+   /* Find the preferred mode */
+   list_for_each_entry (m, list_head, head) {
+   if (!(m->type & DRM_MODE_TYPE_PREFERRED))
+   continue;
+
+   m_high = m;
+   highest_refresh = drm_mode_vrefresh(m_high);
+   break;
+   }
+
+   if (!m_high) {
+   /* Probably an EDID with no preferred mode. Fallback to first 
entry */
+   m_high = list_first_entry_or_null(&aconnector->base.modes,
+ struct drm_display_mode, 
head);
+   if (!m_high)
+   return NULL;
+   else
+   highest_refresh = drm_mode_vrefresh(m_high);
+   }
+


Optional cleanup suggested below makes code more readable:


/* Find the preferred mode */

list_for_each_entry (m, list_head, head) {
     if (m->type & DRM_MODE_TYPE_PREFERRED) {
         m_pref = m;
         break;
     }
}

if (!m_pref) {
     /* Probably an EDID with no preferred mode. Fallback to first entry */
     m_pref = list_first_entry_or_null(&aconnector->base.modes,
                                       struct drm_display_mode, head);
     if (!m_pref) {
         DRM_DEBUG_DRIVER("No preferred mode found in EDID\n");
         return NULL;
     }
}

highest_refresh = drm_mode_vrefresh(m_pref);


Agreed with this cleanup - naming is confusing as is.


+   /*
+* Find the mode with highest refresh rate with same resolution.
+* For some monitors, preferred mode is not the mode with highest
+* supported refresh rate.
+*/
+   list_for_each_entry (m, list_head, head) {
+   current_refresh  = drm_mode_vrefresh(m);
+
+   if (m->hdisplay == m_high->hdisplay &&
+   m->vdisplay == m_high->vdisplay &&
+   highest_refresh < current_refresh) {
+   highest_refresh = current_refresh;
+   m_high = m;
+   }
+   }
+
+   return m_high;
+}
+
  static struct dc_stream_state *
  create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
   const struct drm_display_mode *drm_mode,
@@ -7006,6 +7054,124 @@ static void amdgpu_dm_connector_ddc_get_modes(struct 
drm_connector *connector,
}
  }
  
+static bool is_duplicate_mode(struct amdgpu_dm_connector *aconnector,

+ struct drm_display_mode *mode)
+{
+   struct drm_display_mode *m;
+
+   list_for_each_entry (m, &aconnector->base.probed_modes, head) {
+   if (drm_mode_equal(m, mode))
+   return true;
+   }
+
+   return false;
+}
+
+static uint add_fs_modes(struct amdgpu_dm_connector *aconnector,
+struct detailed_data_monitor_range *range)
+{
+   const struct drm_display_mode *m, *m_save;
+   struct drm_display_mode *new_mode;
+   uint i;
+   uint64_t target_vtotal, target_vtotal_diff;
+   uint32_t new_modes_count = 0;
+   uint64_t num, den;

num, den, target_vtotal, target_vtotal_diff can go inside the 
list_for_each_entry() loop;

+
+   /* Standard FPS values
+*
+* 23.976 - TV/NTSC
+* 24 - Cinema
+* 25 - TV/PAL
+ 

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

[Kazlauskas, Nicholas]

On 2020-12-09 9:45 p.m., Aurabindo Pillai wrote:

[Why&How]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes for common freesync frame rates.
When commiting these mode changes, a full modeset is not needed.
If the change in only in the front porch timing value, skip full
modeset and continue using the same stream.

Signed-off-by: Aurabindo Pillai 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 169 --
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
  2 files changed, 153 insertions(+), 17 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 f699a3d41cad..c8c72887906a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -217,6 +217,9 @@ static bool amdgpu_dm_psr_disable_all(struct 
amdgpu_display_manager *dm);
  static const struct drm_format_info *
  amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
  
+static bool

+is_timing_unchanged_for_freesync(struct drm_crtc_state *old_crtc_state,
+struct drm_crtc_state *new_crtc_state);
  /*
   * dm_vblank_get_counter
   *
@@ -5096,8 +5099,11 @@ copy_crtc_timing_for_drm_display_mode(const struct 
drm_display_mode *src_mode,
  static void
  decide_crtc_timing_for_drm_display_mode(struct drm_display_mode *drm_mode,
const struct drm_display_mode 
*native_mode,
-   bool scale_enabled)
+   bool scale_enabled, bool fs_mode)
  {
+   if (fs_mode)
+   return;
+
if (scale_enabled) {
copy_crtc_timing_for_drm_display_mode(native_mode, drm_mode);
} else if (native_mode->clock == drm_mode->clock &&
@@ -5241,6 +5247,24 @@ get_highest_freesync_mode(struct amdgpu_dm_connector 
*aconnector,
return m_high;
  }
  
+static bool is_freesync_video_mode(struct drm_display_mode *mode,

+  struct amdgpu_dm_connector *aconnector)
+{
+   struct drm_display_mode *high_mode;
+
+   high_mode = get_highest_freesync_mode(aconnector, false);
+   if (!high_mode)
+   return false;
+
+   if (high_mode->clock == 0 ||
+   high_mode->hdisplay != mode->hdisplay ||
+   high_mode->clock != mode->clock ||
+   !mode)
+   return false;
+   else
+   return true;
+}
+


Need to check that the other parameters are the same:
- hsync_start
- hsync_end
- htotal
- hskew
- vdisplay
- vscan

etc.


  static struct dc_stream_state *
  create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
   const struct drm_display_mode *drm_mode,
@@ -5253,17 +5277,21 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
const struct drm_connector_state *con_state =
dm_state ? &dm_state->base : NULL;
struct dc_stream_state *stream = NULL;
-   struct drm_display_mode mode = *drm_mode;
+   struct drm_display_mode saved_mode, mode = *drm_mode;
+   struct drm_display_mode *freesync_mode = NULL;
bool native_mode_found = false;
bool scale = dm_state ? (dm_state->scaling != RMX_OFF) : false;
int mode_refresh;
int preferred_refresh = 0;
+   bool is_fs_vid_mode = 0;
  #if defined(CONFIG_DRM_AMD_DC_DCN)
struct dsc_dec_dpcd_caps dsc_caps;
  #endif
uint32_t link_bandwidth_kbps;
-
struct dc_sink *sink = NULL;
+
+   memset(&saved_mode, 0, sizeof(struct drm_display_mode));
+
if (aconnector == NULL) {
DRM_ERROR("aconnector is NULL!\n");
return stream;
@@ -5316,20 +5344,33 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
 */
DRM_DEBUG_DRIVER("No preferred mode found\n");
} else {
+   is_fs_vid_mode = is_freesync_video_mode(&mode, aconnector);
+   if (is_fs_vid_mode) {
+   freesync_mode = get_highest_freesync_mode(aconnector, 
false);
+   if (freesync_mode) {
+   saved_mode = mode;
+   mode = *freesync_mode;
+   }
+   }
+
decide_crtc_timing_for_drm_display_mode(
&mode, preferred_mode,
-   dm_state ? (dm_state->scaling != RMX_OFF) : 
false);
+   dm_state ? (dm_state->scaling != RMX_OFF) : 
false,
+   freesync_mode ? true : false);


I don't think we need an additional flag here - scaling/freesync behave 
the same, maybe just rename the variable in the function.


Regards,
Nicholas Kazlauskas


preferred_refresh = drm_mode_vrefresh(preferred_mode);
}
  
  	if (!dm_state)