[PATCH 00/16] DC Patches March 25, 2022

[PATCH 00/16] DC Patches March 25, 2022

[Alex Hung]

This DC patchset brings improvements in multiple areas. In summary, we highlight:

* Fix allocate_mst_payload assert on resume
* [FW Promotion] Release 0.0.110.0
* Revert FEC check in validation
* Update LTTPR UHBR link rate support struct
* Add support for USBC connector
* Add work around for AUX failure on wake
* Clear optc false state when disable otg
* Enable power gating before init_pipes
* Remove redundant dsc power gating from init_hw
* Power down hardware if timer not trigger
* Correct Slice reset calculation
* Enable 3-plane MPO for DCN31
* Set fec register init value
* Remove SW w/a for HDCP 1.4 1A-07 failure based on ECO fix
* Create underflow interrupt IRQ type

Angus Wang (1):
  drm/amd/display: Create underflow interrupt IRQ type

Anthony Koo (1):
  drm/amd/display: [FW Promotion] Release 0.0.110.0

Aric Cyr (1):
  drm/amd/display: 3.2.179

Charlene Liu (1):
  drm/amd/display: Clear optc false state when disable otg

Chris Park (1):
  drm/amd/display: Correct Slice reset calculation

Jimmy Kizito (1):
  drm/amd/display: Add work around for AUX failure on wake.

Jingwen Zhu (1):
  drm/amd/display: Set fec register init value

Krunoslav Kovac (1):
  drm/amd/display: Enable 3-plane MPO for DCN31

Martin Leung (1):
  drm/amd/display: Revert FEC check in validation

Michael Strauss (1):
  drm/amd/display: Update LTTPR UHBR link rate support struct

Oliver Logush (1):
  drm/amd/display: Remove SW w/a for HDCP 1.4 1A-07 failure based on ECO
    fix

Paul Hsieh (1):
  drm/amd/display: Power down hardware if timer not trigger

Roman Li (3):
  drm/amd/display: Remove redundant dsc power gating from init_hw
  drm/amd/display: Enable power gating before init_pipes
  drm/amd/display: Fix allocate_mst_payload assert on resume

Samson Tam (1):
  drm/amd/display: Add support for USBC connector

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +-
 .../amd/display/dc/bios/bios_parser_common.c  |  3 +
 .../drm/amd/display/dc/bios/command_table.c   |  3 +-
 .../display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c  | 26 +++++-
 drivers/gpu/drm/amd/display/dc/core/dc.c      |  4 -
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 34 +++----
 .../gpu/drm/amd/display/dc/core/dc_link_dp.c  | 59 ++++++++++++
 drivers/gpu/drm/amd/display/dc/dc.h           |  2 +-
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h  |  2 +-
 .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 18 ++--
 .../drm/amd/display/dc/dcn30/dcn30_hwseq.c    |  5 +-
 .../drm/amd/display/dc/dcn31/dcn31_hwseq.c    | 25 +++---
 .../gpu/drm/amd/display/dc/dcn31/dcn31_optc.c |  5 +-
 .../drm/amd/display/dc/dcn31/dcn31_resource.c |  6 +-
 .../amd/display/dc/dcn315/dcn315_resource.c   |  3 +-
 .../amd/display/dc/dcn316/dcn316_resource.c   |  3 +-
 drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c   |  4 +-
 .../gpu/drm/amd/display/dc/inc/dc_link_dp.h   |  1 +
 drivers/gpu/drm/amd/display/dc/irq_types.h    |  1 +
 .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h   | 90 +------------------
 .../drm/amd/display/include/grph_object_id.h  |  1 +
 21 files changed, 155 insertions(+), 143 deletions(-)

-- 
2.35.1

[PATCH 01/16] drm/amd/display: Create underflow interrupt IRQ type

[Alex Hung]

From: Angus Wang <Angus.Wang@amd.com>

[WHY]
We want another entry in IRQ type that can be used to
help find the underflow interrupt source.

[HOW]
Added another mapping in IRQ type enum.

Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Angus Wang <Angus.Wang@amd.com>
---
 drivers/gpu/drm/amd/display/dc/irq_types.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/dc/irq_types.h b/drivers/gpu/drm/amd/display/dc/irq_types.h
index 530c2578db40..36d8243cfbff 100644
--- a/drivers/gpu/drm/amd/display/dc/irq_types.h
+++ b/drivers/gpu/drm/amd/display/dc/irq_types.h
@@ -162,6 +162,7 @@ enum irq_type
 	IRQ_TYPE_VUPDATE = DC_IRQ_SOURCE_VUPDATE1,
 	IRQ_TYPE_VBLANK = DC_IRQ_SOURCE_VBLANK1,
 	IRQ_TYPE_VLINE0 = DC_IRQ_SOURCE_DC1_VLINE0,
+	IRQ_TYPE_DCUNDERFLOW = DC_IRQ_SOURCE_DC1UNDERFLOW,
 };
 
 #define DAL_VALID_IRQ_SRC_NUM(src) \
-- 
2.35.1

[PATCH 02/16] drm/amd/display: Remove SW w/a for HDCP 1.4 1A-07 failure based on ECO fix

[Alex Hung]

From: Oliver Logush <oliver.logush@amd.com>

[why]
W/a no longer needed

Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Oliver Logush <oliver.logush@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c | 3 +--
 drivers/gpu/drm/amd/display/dc/dcn316/dcn316_resource.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c b/drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c
index fadb89326999..e6f9312e3a48 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c
@@ -1758,11 +1758,10 @@ static bool dcn315_resource_construct(
 	pool->base.mpcc_count = pool->base.res_cap->num_timing_generator;
 	dc->caps.max_downscale_ratio = 600;
 	dc->caps.i2c_speed_in_khz = 100;
-	dc->caps.i2c_speed_in_khz_hdcp = 5; /*1.4 w/a applied by default*/
+	dc->caps.i2c_speed_in_khz_hdcp = 100;
 	dc->caps.max_cursor_size = 256;
 	dc->caps.min_horizontal_blanking_period = 80;
 	dc->caps.dmdata_alloc_size = 2048;
-
 	dc->caps.max_slave_planes = 1;
 	dc->caps.max_slave_yuv_planes = 1;
 	dc->caps.max_slave_rgb_planes = 1;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/dcn316_resource.c b/drivers/gpu/drm/amd/display/dc/dcn316/dcn316_resource.c
index d73145dab173..d5c195749a81 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn316/dcn316_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn316/dcn316_resource.c
@@ -1760,11 +1760,10 @@ static bool dcn316_resource_construct(
 	pool->base.mpcc_count = pool->base.res_cap->num_timing_generator;
 	dc->caps.max_downscale_ratio = 600;
 	dc->caps.i2c_speed_in_khz = 100;
-	dc->caps.i2c_speed_in_khz_hdcp = 5; /*1.4 w/a applied by default*/
+	dc->caps.i2c_speed_in_khz_hdcp = 100;
 	dc->caps.max_cursor_size = 256;
 	dc->caps.min_horizontal_blanking_period = 80;
 	dc->caps.dmdata_alloc_size = 2048;
-
 	dc->caps.max_slave_planes = 1;
 	dc->caps.max_slave_yuv_planes = 1;
 	dc->caps.max_slave_rgb_planes = 1;
-- 
2.35.1

[PATCH 03/16] drm/amd/display: Set fec register init value

[Alex Hung]

From: Jingwen Zhu <Jingwen.Zhu@amd.com>

[Why]
We don't include this eDP FEC init on fastboot.

[How]
Set the fec to init value when stopping driver &get the fec register value to check should enable FEC.

Co-authored-by: Jingwen Zhu <Jingwen.Zhu@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Jingwen Zhu <Jingwen.Zhu@amd.com>
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 26 +++++++++----------
 .../amd/display/dc/dcn10/dcn10_hw_sequencer.c |  6 ++++-
 .../drm/amd/display/dc/dcn31/dcn31_hwseq.c    |  6 ++++-
 3 files changed, 22 insertions(+), 16 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 bbaa5abdf888..c7c4d9867c52 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -4683,22 +4683,20 @@ bool dc_link_is_fec_supported(const struct dc_link *link)
 
 bool dc_link_should_enable_fec(const struct dc_link *link)
 {
-	bool is_fec_disable = false;
-	bool ret = false;
+	bool force_disable = false;
 
-	if ((link->connector_signal != SIGNAL_TYPE_DISPLAY_PORT_MST &&
+	if (link->fec_state == dc_link_fec_enabled)
+		force_disable = false;
+	else if (link->connector_signal != SIGNAL_TYPE_DISPLAY_PORT_MST &&
 			link->local_sink &&
-			link->local_sink->edid_caps.panel_patch.disable_fec) ||
-			(link->connector_signal == SIGNAL_TYPE_EDP
-				// enable FEC for EDP if DSC is supported
-				&& link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT == false
-				))
-		is_fec_disable = true;
-
-	if (dc_link_is_fec_supported(link) && !link->dc->debug.disable_fec && !is_fec_disable)
-		ret = true;
-
-	return ret;
+			link->local_sink->edid_caps.panel_patch.disable_fec)
+		force_disable = true;
+	else if (link->connector_signal == SIGNAL_TYPE_EDP
+			&& link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.
+			 dsc_support.DSC_SUPPORT == false)
+		force_disable = true;
+
+	return !force_disable && dc_link_is_fec_supported(link);
 }
 
 uint32_t dc_bandwidth_in_kbps_from_timing(
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index ad757b59e00e..911c5d103c64 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1493,8 +1493,12 @@ void dcn10_init_hw(struct dc *dc)
 
 		/* Check for enabled DIG to identify enabled display */
 		if (link->link_enc->funcs->is_dig_enabled &&
-			link->link_enc->funcs->is_dig_enabled(link->link_enc))
+			link->link_enc->funcs->is_dig_enabled(link->link_enc)) {
 			link->link_status.link_active = true;
+			if (link->link_enc->funcs->fec_is_active &&
+					link->link_enc->funcs->fec_is_active(link->link_enc))
+				link->fec_state = dc_link_fec_enabled;
+		}
 	}
 
 	/* Power gate DSCs */
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
index 4be228680909..b57f657c4e44 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
@@ -188,8 +188,12 @@ void dcn31_init_hw(struct dc *dc)
 
 		/* Check for enabled DIG to identify enabled display */
 		if (link->link_enc->funcs->is_dig_enabled &&
-			link->link_enc->funcs->is_dig_enabled(link->link_enc))
+			link->link_enc->funcs->is_dig_enabled(link->link_enc)) {
 			link->link_status.link_active = true;
+			if (link->link_enc->funcs->fec_is_active &&
+					link->link_enc->funcs->fec_is_active(link->link_enc))
+				link->fec_state = dc_link_fec_enabled;
+		}
 	}
 
 	/* Enables outbox notifications for usb4 dpia */
-- 
2.35.1

[PATCH 04/16] drm/amd/display: Enable 3-plane MPO for DCN31

[Alex Hung]

From: Krunoslav Kovac <Krunoslav.Kovac@amd.com>

[WHY&HOW]
It can be enabled by users, but proper way is to report max_slave_planes
in DC caps for each ASIC.
Some structures use hardcoded max_plane=2, this is also addressed here.

Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

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 bf130b2435ab..826970f2bd0a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -1868,9 +1868,9 @@ static bool dcn31_resource_construct(
 	dc->caps.min_horizontal_blanking_period = 80;
 	dc->caps.dmdata_alloc_size = 2048;
 
-	dc->caps.max_slave_planes = 1;
-	dc->caps.max_slave_yuv_planes = 1;
-	dc->caps.max_slave_rgb_planes = 1;
+	dc->caps.max_slave_planes = 2;
+	dc->caps.max_slave_yuv_planes = 2;
+	dc->caps.max_slave_rgb_planes = 2;
 	dc->caps.post_blend_color_processing = true;
 	dc->caps.force_dp_tps4_for_cp2520 = true;
 	dc->caps.dp_hpo = true;
-- 
2.35.1

[PATCH 05/16] drm/amd/display: Correct Slice reset calculation

[Alex Hung]

From: Chris Park <Chris.Park@amd.com>

[Why]
Once DSC slice cannot fit pixel clock, we incorrectly
reset min slices to 0 and allow max slice to operate,
even when max slice itself cannot fit the pixel clock
properly.

[How]
Change the sequence such that we correctly determine
DSC is not possible when both min slices and max
slices cannot fit pixel clock per slice.

Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Chris Park <Chris.Park@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
index 9c74564cbd8d..8973d3a38f9c 100644
--- a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
@@ -864,11 +864,11 @@ static bool setup_dsc_config(
 		min_slices_h = inc_num_slices(dsc_common_caps.slice_caps, min_slices_h);
 	}
 
+	is_dsc_possible = (min_slices_h <= max_slices_h);
+
 	if (pic_width % min_slices_h != 0)
 		min_slices_h = 0; // DSC TODO: Maybe try increasing the number of slices first?
 
-	is_dsc_possible = (min_slices_h <= max_slices_h);
-
 	if (min_slices_h == 0 && max_slices_h == 0)
 		is_dsc_possible = false;
 
-- 
2.35.1

[PATCH 06/16] drm/amd/display: Power down hardware if timer not trigger

[Alex Hung]

From: Paul Hsieh <paul.hsieh@amd.com>

[WHY]
In headless systems, if SetMode/Power down timer
is not called, hardware will not be powered down
causing HW/SW discrepancies. Powering down hardware
on SetPowerState to D3 will ensure SW/HW state is accurate.

[HOW]
If PowerDownThread timer is not trigger but OS call
SetPowerState to D3, power down hardware.

Reviewed-by: Eric Yang <Eric.Yang2@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Paul Hsieh <paul.hsieh@amd.com>
---
 .../display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c  | 26 ++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c
index 59fdd7f0d609..969b40250434 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c
@@ -615,13 +615,37 @@ static void dcn31_clk_mgr_helper_populate_bw_params(struct clk_mgr_internal *clk
 	}
 }
 
+void dcn31_set_low_power_state(struct clk_mgr *clk_mgr_base)
+{
+	int display_count;
+	struct clk_mgr_internal *clk_mgr = TO_CLK_MGR_INTERNAL(clk_mgr_base);
+	struct dc *dc = clk_mgr_base->ctx->dc;
+	struct dc_state *context = dc->current_state;
+
+	if (clk_mgr_base->clks.pwr_state != DCN_PWR_STATE_LOW_POWER) {
+		display_count = dcn31_get_active_display_cnt_wa(dc, context);
+		/* if we can go lower, go lower */
+		if (display_count == 0) {
+			union display_idle_optimization_u idle_info = { 0 };
+
+			idle_info.idle_info.df_request_disabled = 1;
+			idle_info.idle_info.phy_ref_clk_off = 1;
+			idle_info.idle_info.s0i2_rdy = 1;
+			dcn31_smu_set_display_idle_optimization(clk_mgr, idle_info.data);
+			/* update power state */
+			clk_mgr_base->clks.pwr_state = DCN_PWR_STATE_LOW_POWER;
+		}
+	}
+}
+
 static struct clk_mgr_funcs dcn31_funcs = {
 	.get_dp_ref_clk_frequency = dce12_get_dp_ref_freq_khz,
 	.update_clocks = dcn31_update_clocks,
 	.init_clocks = dcn31_init_clocks,
 	.enable_pme_wa = dcn31_enable_pme_wa,
 	.are_clock_states_equal = dcn31_are_clock_states_equal,
-	.notify_wm_ranges = dcn31_notify_wm_ranges
+	.notify_wm_ranges = dcn31_notify_wm_ranges,
+	.set_low_power_state = dcn31_set_low_power_state
 };
 extern struct clk_mgr_funcs dcn3_fpga_funcs;
 
-- 
2.35.1

[PATCH 07/16] drm/amd/display: Remove redundant dsc power gating from init_hw

[Alex Hung]

From: Roman Li <Roman.Li@amd.com>

[Why]
DSC Power down code has been moved from dcn31_init_hw into init_pipes()
Need to remove it from dcn10_init_hw() as well to avoid duplicated action
on dcn1.x/2.x

[How]
Remove DSC power down code from dcn10_init_hw()

Fixes: 8fa6f4c5715c ("drm/amd/display: fixed the DSC power off sequence during Driver PnP")

Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Eric Yang <Eric.Yang2@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 911c5d103c64..bb309ccee3e4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1501,13 +1501,6 @@ void dcn10_init_hw(struct dc *dc)
 		}
 	}
 
-	/* Power gate DSCs */
-	if (!is_optimized_init_done) {
-		for (i = 0; i < res_pool->res_cap->num_dsc; i++)
-			if (hws->funcs.dsc_pg_control != NULL)
-				hws->funcs.dsc_pg_control(hws, res_pool->dscs[i]->inst, false);
-	}
-
 	/* we want to turn off all dp displays before doing detection */
 	dc_link_blank_all_dp_displays(dc);
 
-- 
2.35.1

[PATCH 08/16] drm/amd/display: Enable power gating before init_pipes

[Alex Hung]

From: Roman Li <Roman.Li@amd.com>

[Why]
In init_hw() we call init_pipes() before enabling power gating.
init_pipes() tries to power gate dsc but it may fail because
required force-ons are not released yet.
As a result with dsc config the following errors observed on resume:
"REG_WAIT timeout 1us * 1000 tries - dcn20_dsc_pg_control"
"REG_WAIT timeout 1us * 1000 tries - dcn20_dpp_pg_control"
"REG_WAIT timeout 1us * 1000 tries - dcn20_hubp_pg_control"

[How]
Move enable_power_gating_plane() before init_pipes() in init_hw()

Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Eric Yang <Eric.Yang2@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 5 +++--
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c        | 5 +++--
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c        | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index bb309ccee3e4..e4247740ac12 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1504,6 +1504,9 @@ void dcn10_init_hw(struct dc *dc)
 	/* we want to turn off all dp displays before doing detection */
 	dc_link_blank_all_dp_displays(dc);
 
+	if (hws->funcs.enable_power_gating_plane)
+		hws->funcs.enable_power_gating_plane(dc->hwseq, true);
+
 	/* If taking control over from VBIOS, we may want to optimize our first
 	 * mode set, so we need to skip powering down pipes until we know which
 	 * pipes we want to use.
@@ -1556,8 +1559,6 @@ void dcn10_init_hw(struct dc *dc)
 
 		REG_UPDATE(DCFCLK_CNTL, DCFCLK_GATE_DIS, 0);
 	}
-	if (hws->funcs.enable_power_gating_plane)
-		hws->funcs.enable_power_gating_plane(dc->hwseq, true);
 
 	if (dc->clk_mgr->funcs->notify_wm_ranges)
 		dc->clk_mgr->funcs->notify_wm_ranges(dc->clk_mgr);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index ed0a0e5fd805..f61ec8763844 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -547,6 +547,9 @@ void dcn30_init_hw(struct dc *dc)
 	/* we want to turn off all dp displays before doing detection */
 	dc_link_blank_all_dp_displays(dc);
 
+	if (hws->funcs.enable_power_gating_plane)
+		hws->funcs.enable_power_gating_plane(dc->hwseq, true);
+
 	/* If taking control over from VBIOS, we may want to optimize our first
 	 * mode set, so we need to skip powering down pipes until we know which
 	 * pipes we want to use.
@@ -624,8 +627,6 @@ void dcn30_init_hw(struct dc *dc)
 
 		REG_UPDATE(DCFCLK_CNTL, DCFCLK_GATE_DIS, 0);
 	}
-	if (hws->funcs.enable_power_gating_plane)
-		hws->funcs.enable_power_gating_plane(dc->hwseq, true);
 
 	if (!dcb->funcs->is_accelerated_mode(dcb) && dc->res_pool->hubbub->funcs->init_watermarks)
 		dc->res_pool->hubbub->funcs->init_watermarks(dc->res_pool->hubbub);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
index b57f657c4e44..67c13654ab99 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
@@ -203,6 +203,9 @@ void dcn31_init_hw(struct dc *dc)
 	/* we want to turn off all dp displays before doing detection */
 	dc_link_blank_all_dp_displays(dc);
 
+	if (hws->funcs.enable_power_gating_plane)
+		hws->funcs.enable_power_gating_plane(dc->hwseq, true);
+
 	/* If taking control over from VBIOS, we may want to optimize our first
 	 * mode set, so we need to skip powering down pipes until we know which
 	 * pipes we want to use.
@@ -252,8 +255,6 @@ void dcn31_init_hw(struct dc *dc)
 
 		REG_UPDATE(DCFCLK_CNTL, DCFCLK_GATE_DIS, 0);
 	}
-	if (hws->funcs.enable_power_gating_plane)
-		hws->funcs.enable_power_gating_plane(dc->hwseq, true);
 
 	if (!dcb->funcs->is_accelerated_mode(dcb) && dc->res_pool->hubbub->funcs->init_watermarks)
 		dc->res_pool->hubbub->funcs->init_watermarks(dc->res_pool->hubbub);
-- 
2.35.1

[PATCH 09/16] drm/amd/display: Clear optc false state when disable otg

[Alex Hung]

From: Charlene Liu <Charlene.Liu@amd.com>

[why]
when disable optc, need to clear the underflow status as well.

Reviewed-by: Chris Park <Chris.Park@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c | 14 +++++++-------
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_optc.c  |  5 ++++-
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
index 67c13654ab99..531dd2c65007 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
@@ -343,20 +343,20 @@ void dcn31_enable_power_gating_plane(
 	bool enable)
 {
 	bool force_on = true; /* disable power gating */
+	uint32_t org_ip_request_cntl = 0;
 
 	if (enable && !hws->ctx->dc->debug.disable_hubp_power_gate)
 		force_on = false;
 
+	REG_GET(DC_IP_REQUEST_CNTL, IP_REQUEST_EN, &org_ip_request_cntl);
+	if (org_ip_request_cntl == 0)
+		REG_SET(DC_IP_REQUEST_CNTL, 0, IP_REQUEST_EN, 1);
 	/* DCHUBP0/1/2/3/4/5 */
 	REG_UPDATE(DOMAIN0_PG_CONFIG, DOMAIN_POWER_FORCEON, force_on);
-	REG_WAIT(DOMAIN0_PG_STATUS, DOMAIN_PGFSM_PWR_STATUS, force_on, 1, 1000);
 	REG_UPDATE(DOMAIN2_PG_CONFIG, DOMAIN_POWER_FORCEON, force_on);
-	REG_WAIT(DOMAIN2_PG_STATUS, DOMAIN_PGFSM_PWR_STATUS, force_on, 1, 1000);
 	/* DPP0/1/2/3/4/5 */
 	REG_UPDATE(DOMAIN1_PG_CONFIG, DOMAIN_POWER_FORCEON, force_on);
-	REG_WAIT(DOMAIN1_PG_STATUS, DOMAIN_PGFSM_PWR_STATUS, force_on, 1, 1000);
 	REG_UPDATE(DOMAIN3_PG_CONFIG, DOMAIN_POWER_FORCEON, force_on);
-	REG_WAIT(DOMAIN3_PG_STATUS, DOMAIN_PGFSM_PWR_STATUS, force_on, 1, 1000);
 
 	force_on = true; /* disable power gating */
 	if (enable && !hws->ctx->dc->debug.disable_dsc_power_gate)
@@ -364,11 +364,11 @@ void dcn31_enable_power_gating_plane(
 
 	/* DCS0/1/2/3/4/5 */
 	REG_UPDATE(DOMAIN16_PG_CONFIG, DOMAIN_POWER_FORCEON, force_on);
-	REG_WAIT(DOMAIN16_PG_STATUS, DOMAIN_PGFSM_PWR_STATUS, force_on, 1, 1000);
 	REG_UPDATE(DOMAIN17_PG_CONFIG, DOMAIN_POWER_FORCEON, force_on);
-	REG_WAIT(DOMAIN17_PG_STATUS, DOMAIN_PGFSM_PWR_STATUS, force_on, 1, 1000);
 	REG_UPDATE(DOMAIN18_PG_CONFIG, DOMAIN_POWER_FORCEON, force_on);
-	REG_WAIT(DOMAIN18_PG_STATUS, DOMAIN_PGFSM_PWR_STATUS, force_on, 1, 1000);
+
+	if (org_ip_request_cntl == 0)
+		REG_SET(DC_IP_REQUEST_CNTL, 0, IP_REQUEST_EN, 0);
 }
 
 void dcn31_update_info_frame(struct pipe_ctx *pipe_ctx)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_optc.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_optc.c
index 8afe2130d7c5..e05527a3a8ba 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_optc.c
@@ -124,7 +124,6 @@ static bool optc31_enable_crtc(struct timing_generator *optc)
 static bool optc31_disable_crtc(struct timing_generator *optc)
 {
 	struct optc *optc1 = DCN10TG_FROM_TG(optc);
-
 	/* disable otg request until end of the first line
 	 * in the vertical blank region
 	 */
@@ -138,6 +137,7 @@ static bool optc31_disable_crtc(struct timing_generator *optc)
 	REG_WAIT(OTG_CLOCK_CONTROL,
 			OTG_BUSY, 0,
 			1, 100000);
+	optc1_clear_optc_underflow(optc);
 
 	return true;
 }
@@ -158,6 +158,9 @@ static bool optc31_immediate_disable_crtc(struct timing_generator *optc)
 			OTG_BUSY, 0,
 			1, 100000);
 
+	/* clear the false state */
+	optc1_clear_optc_underflow(optc);
+
 	return true;
 }
 
-- 
2.35.1

[PATCH 10/16] drm/amd/display: Add work around for AUX failure on wake.

[Alex Hung]

From: Jimmy Kizito <Jimmy.Kizito@amd.com>

[Why]
When waking from low-power states, a DP sink may remain unresponsive to
AUX transactions.

[How]
Try to toggle DPCD SET_POWER register repeatedly (up to a maximum
timeout value) until DP sink becomes responsive.

Reviewed-by: Mustapha Ghaddar <Mustapha.Ghaddar@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com>
---
 .../gpu/drm/amd/display/dc/core/dc_link_dp.c  | 59 +++++++++++++++++++
 .../gpu/drm/amd/display/dc/inc/dc_link_dp.h   |  1 +
 2 files changed, 60 insertions(+)

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 351081f574cb..e4df81dc1dc2 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
@@ -5216,6 +5216,62 @@ static void retrieve_cable_id(struct dc_link *link)
 				&link->dpcd_caps.cable_id, &usbc_cable_id);
 }
 
+/* DPRX may take some time to respond to AUX messages after HPD asserted.
+ * If AUX read unsuccessful, try to wake unresponsive DPRX by toggling DPCD SET_POWER (0x600).
+ */
+static enum dc_status wa_try_to_wake_dprx(struct dc_link *link, uint64_t timeout_ms)
+{
+	enum dc_status status = DC_ERROR_UNEXPECTED;
+	uint8_t dpcd_data = 0;
+	uint64_t start_ts = 0;
+	uint64_t current_ts = 0;
+	uint64_t time_taken_ms = 0;
+	enum dc_connection_type type = dc_connection_none;
+
+	status = core_link_read_dpcd(
+			link,
+			DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV,
+			&dpcd_data,
+			sizeof(dpcd_data));
+
+	if (status != DC_OK) {
+		DC_LOG_WARNING("%s: Read DPCD LTTPR_CAP failed - try to toggle DPCD SET_POWER for %lld ms.",
+				__func__,
+				timeout_ms);
+		start_ts = dm_get_timestamp(link->ctx);
+
+		do {
+			if (!dc_link_detect_sink(link, &type) || type == dc_connection_none)
+				break;
+
+			dpcd_data = DP_SET_POWER_D3;
+			status = core_link_write_dpcd(
+					link,
+					DP_SET_POWER,
+					&dpcd_data,
+					sizeof(dpcd_data));
+
+			dpcd_data = DP_SET_POWER_D0;
+			status = core_link_write_dpcd(
+					link,
+					DP_SET_POWER,
+					&dpcd_data,
+					sizeof(dpcd_data));
+
+			current_ts = dm_get_timestamp(link->ctx);
+			time_taken_ms = div_u64(dm_get_elapse_time_in_ns(link->ctx, current_ts, start_ts), 1000000);
+		} while (status != DC_OK && time_taken_ms < timeout_ms);
+
+		DC_LOG_WARNING("%s: DPCD SET_POWER %s after %lld ms%s",
+				__func__,
+				(status == DC_OK) ? "succeeded" : "failed",
+				time_taken_ms,
+				(type == dc_connection_none) ? ". Unplugged." : ".");
+	}
+
+	return status;
+}
+
 static bool retrieve_link_cap(struct dc_link *link)
 {
 	/* DP_ADAPTER_CAP - DP_DPCD_REV + 1 == 16 and also DP_DSC_BITS_PER_PIXEL_INC - DP_DSC_SUPPORT + 1 == 16,
@@ -5251,6 +5307,9 @@ static bool retrieve_link_cap(struct dc_link *link)
 	dc_link_aux_try_to_configure_timeout(link->ddc,
 			LINK_AUX_DEFAULT_LTTPR_TIMEOUT_PERIOD);
 
+	/* Try to ensure AUX channel active before proceeding. */
+	status = wa_try_to_wake_dprx(link, LINK_AUX_WAKE_TIMEOUT_MS);
+
 	is_lttpr_present = dp_retrieve_lttpr_cap(link);
 	/* Read DP tunneling information. */
 	status = dpcd_get_tunneling_device_data(link);
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 ab9939db8cea..44f167d2584f 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
@@ -33,6 +33,7 @@
 #define MAX_MTP_SLOT_COUNT 64
 #define DP_REPEATER_CONFIGURATION_AND_STATUS_SIZE 0x50
 #define TRAINING_AUX_RD_INTERVAL 100 //us
+#define LINK_AUX_WAKE_TIMEOUT_MS 1500 // Timeout when trying to wake unresponsive DPRX.
 
 struct dc_link;
 struct dc_stream_state;
-- 
2.35.1

[PATCH 11/16] drm/amd/display: Add support for USBC connector

[Alex Hung]

From: Samson Tam <Samson.Tam@amd.com>

[Why]
Add support for CONNECTOR_ID_USBC

Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Samson Tam <Samson.Tam@amd.com>
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser_common.c | 3 +++
 drivers/gpu/drm/amd/display/dc/bios/command_table.c      | 3 ++-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c            | 8 ++++++--
 drivers/gpu/drm/amd/display/include/grph_object_id.h     | 1 +
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_common.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_common.c
index a8cb039d2572..34e3a64f556e 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_common.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_common.c
@@ -213,6 +213,9 @@ static enum connector_id connector_id_from_bios_object_id(
 	case CONNECTOR_OBJECT_ID_MXM:
 		id = CONNECTOR_ID_MXM;
 		break;
+	case CONNECTOR_OBJECT_ID_USBC:
+		id = CONNECTOR_ID_USBC;
+		break;
 	default:
 		id = CONNECTOR_ID_UNKNOWN;
 		break;
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
index 0e36cd800fc9..32efa92422e8 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
@@ -522,7 +522,8 @@ static enum bp_result transmitter_control_v2(
 		 */
 		params.acConfig.ucEncoderSel = 1;
 
-	if (CONNECTOR_ID_DISPLAY_PORT == connector_id)
+	if (CONNECTOR_ID_DISPLAY_PORT == connector_id
+		|| CONNECTOR_ID_USBC == connector_id)
 		/* Bit4: DP connector flag
 		 * =0 connector is none-DP connector
 		 * =1 connector is DP connector
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 c7c4d9867c52..7aede6495e5e 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -345,6 +345,7 @@ static enum signal_type get_basic_signal_type(struct graphics_object_id encoder,
 		case CONNECTOR_ID_LVDS:
 			return SIGNAL_TYPE_LVDS;
 		case CONNECTOR_ID_DISPLAY_PORT:
+		case CONNECTOR_ID_USBC:
 			return SIGNAL_TYPE_DISPLAY_PORT;
 		case CONNECTOR_ID_EDP:
 			return SIGNAL_TYPE_EDP;
@@ -380,7 +381,8 @@ bool dc_link_is_dp_sink_present(struct dc_link *link)
 
 	bool present =
 		((connector_id == CONNECTOR_ID_DISPLAY_PORT) ||
-		(connector_id == CONNECTOR_ID_EDP));
+		(connector_id == CONNECTOR_ID_EDP) ||
+		(connector_id == CONNECTOR_ID_USBC));
 
 	ddc = dal_ddc_service_get_ddc_pin(link->ddc);
 
@@ -476,7 +478,8 @@ static enum signal_type link_detect_sink(struct dc_link *link,
 				result = SIGNAL_TYPE_DVI_SINGLE_LINK;
 	}
 	break;
-	case CONNECTOR_ID_DISPLAY_PORT: {
+	case CONNECTOR_ID_DISPLAY_PORT:
+	case CONNECTOR_ID_USBC: {
 		/* DP HPD short pulse. Passive DP dongle will not
 		 * have short pulse
 		 */
@@ -1591,6 +1594,7 @@ static bool dc_link_construct_legacy(struct dc_link *link,
 		link->connector_signal = SIGNAL_TYPE_DVI_DUAL_LINK;
 		break;
 	case CONNECTOR_ID_DISPLAY_PORT:
+	case CONNECTOR_ID_USBC:
 		link->connector_signal = SIGNAL_TYPE_DISPLAY_PORT;
 
 		if (link->hpd_gpio)
diff --git a/drivers/gpu/drm/amd/display/include/grph_object_id.h b/drivers/gpu/drm/amd/display/include/grph_object_id.h
index fed1edc038d8..c6bbd262f1ac 100644
--- a/drivers/gpu/drm/amd/display/include/grph_object_id.h
+++ b/drivers/gpu/drm/amd/display/include/grph_object_id.h
@@ -162,6 +162,7 @@ enum connector_id {
 	CONNECTOR_ID_MXM = 21,
 	CONNECTOR_ID_WIRELESS = 22,
 	CONNECTOR_ID_MIRACAST = 23,
+	CONNECTOR_ID_USBC = 24,
 
 	CONNECTOR_ID_VIRTUAL = 100
 };
-- 
2.35.1

[PATCH 12/16] drm/amd/display: Update LTTPR UHBR link rate support struct

[Alex Hung]

From: Michael Strauss <michael.strauss@amd.com>

[WHY]
Update field order to match DP2.0 spec SCR

Reviewed-by: George Shen <George.Shen@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Michael Strauss <michael.strauss@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index 36ac2a8746bd..7d4aa99525da 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -993,8 +993,8 @@ union dp_128b_132b_supported_link_rates {
 union dp_128b_132b_supported_lttpr_link_rates {
 	struct {
 		uint8_t UHBR10	:1;
-		uint8_t UHBR13_5:1;
 		uint8_t UHBR20	:1;
+		uint8_t UHBR13_5:1;
 		uint8_t RESERVED:5;
 	} bits;
 	uint8_t raw;
-- 
2.35.1

[PATCH 13/16] drm/amd/display: Revert FEC check in validation

[Alex Hung]

From: Martin Leung <Martin.Leung@amd.com>

why and how:
causes failure on install on certain machines

Reviewed-by: George Shen <George.Shen@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Martin Leung <Martin.Leung@amd.com>
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ----
 1 file changed, 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 f2ad8f58e69c..c436db416708 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1496,10 +1496,6 @@ bool dc_validate_boot_timing(const struct dc *dc,
 	if (!link->link_enc->funcs->is_dig_enabled(link->link_enc))
 		return false;
 
-	/* Check for FEC status*/
-	if (link->link_enc->funcs->fec_is_active(link->link_enc))
-		return false;
-
 	enc_inst = link->link_enc->funcs->get_dig_frontend(link->link_enc);
 
 	if (enc_inst == ENGINE_ID_UNKNOWN)
-- 
2.35.1

[PATCH 14/16] drm/amd/display: [FW Promotion] Release 0.0.110.0

[Alex Hung]

From: Anthony Koo <Anthony.Koo@amd.com>

 - Revert save/restore PANEL_PWRSEQ_REF_DIV2 and
 other psr phy optimizations

Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
---
 .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h   | 90 +------------------
 1 file changed, 4 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
index ce773b56a778..9b5db16b2619 100644
--- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
+++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
@@ -46,10 +46,10 @@
 
 /* Firmware versioning. */
 #ifdef DMUB_EXPOSE_VERSION
-#define DMUB_FW_VERSION_GIT_HASH 0x51b95a35
+#define DMUB_FW_VERSION_GIT_HASH 0x19edd13d
 #define DMUB_FW_VERSION_MAJOR 0
 #define DMUB_FW_VERSION_MINOR 0
-#define DMUB_FW_VERSION_REVISION 109
+#define DMUB_FW_VERSION_REVISION 110
 #define DMUB_FW_VERSION_TEST 0
 #define DMUB_FW_VERSION_VBIOS 0
 #define DMUB_FW_VERSION_HOTFIX 0
@@ -1450,81 +1450,6 @@ enum dmub_cmd_mall_type {
 	DMUB_CMD__MALL_ACTION_NO_DF_REQ = 3,
 };
 
-/**
- * PHY Link rate for DP.
- */
-enum phy_link_rate {
-	/**
-	 * not supported.
-	 */
-	PHY_RATE_UNKNOWN = 0,
-	/**
-	 * Rate_1 (RBR)	- 1.62 Gbps/Lane
-	 */
-	PHY_RATE_162 = 1,
-	/**
-	 * Rate_2		- 2.16 Gbps/Lane
-	 */
-	PHY_RATE_216 = 2,
-	/**
-	 * Rate_3		- 2.43 Gbps/Lane
-	 */
-	PHY_RATE_243 = 3,
-	/**
-	 * Rate_4 (HBR)	- 2.70 Gbps/Lane
-	 */
-	PHY_RATE_270 = 4,
-	/**
-	 * Rate_5 (RBR2)- 3.24 Gbps/Lane
-	 */
-	PHY_RATE_324 = 5,
-	/**
-	 * Rate_6		- 4.32 Gbps/Lane
-	 */
-	PHY_RATE_432 = 6,
-	/**
-	 * Rate_7 (HBR2)- 5.40 Gbps/Lane
-	 */
-	PHY_RATE_540 = 7,
-	/**
-	 * Rate_8 (HBR3)- 8.10 Gbps/Lane
-	 */
-	PHY_RATE_810 = 8,
-	/**
-	 * UHBR10 - 10.0 Gbps/Lane
-	 */
-	PHY_RATE_1000 = 9,
-	/**
-	 * UHBR13.5 - 13.5 Gbps/Lane
-	 */
-	PHY_RATE_1350 = 10,
-	/**
-	 * UHBR10 - 20.0 Gbps/Lane
-	 */
-	PHY_RATE_2000 = 11,
-};
-
-/**
- * enum dmub_phy_fsm_state - PHY FSM states.
- * PHY FSM state to transit to during PSR enable/disable.
- */
-enum dmub_phy_fsm_state {
-	DMUB_PHY_FSM_POWER_UP_DEFAULT = 0,
-	DMUB_PHY_FSM_RESET,
-	DMUB_PHY_FSM_RESET_RELEASED,
-	DMUB_PHY_FSM_SRAM_LOAD_DONE,
-	DMUB_PHY_FSM_INITIALIZED,
-	DMUB_PHY_FSM_CALIBRATED,
-	DMUB_PHY_FSM_CALIBRATED_LP,
-	DMUB_PHY_FSM_CALIBRATED_PG,
-	DMUB_PHY_FSM_POWER_DOWN,
-	DMUB_PHY_FSM_PLL_EN,
-	DMUB_PHY_FSM_TX_EN,
-	DMUB_PHY_FSM_FAST_LP,
-};
-
-
-
 /**
  * Data passed from driver to FW in a DMUB_CMD__PSR_COPY_SETTINGS command.
  */
@@ -1772,16 +1697,9 @@ struct dmub_cmd_psr_force_static_data {
 	 */
 	uint8_t panel_inst;
 	/**
-	 * Phy state to enter.
-	 * Values to use are defined in dmub_phy_fsm_state
-	 */
-	uint8_t phy_fsm_state;
-	/**
-	 * Phy rate for DP - RBR/HBR/HBR2/HBR3.
-	 * Set this using enum phy_link_rate.
-	 * This does not support HDMI/DP2 for now.
+	 * Explicit padding to 4 byte boundary.
 	 */
-	uint8_t phy_rate;
+	uint8_t pad[2];
 };
 
 /**
-- 
2.35.1

[PATCH 15/16] drm/amd/display: 3.2.179

[Alex Hung]

From: Aric Cyr <aric.cyr@amd.com>

- [FW Promotion] Release 0.0.110.0
- Revert FEC check in validation
- Update LTTPR UHBR link rate support struct
- Add support for USBC connector
- Add work around for AUX failure on wake
- Clear optc false state when disable otg
- Enable power gating before init_pipes
- Remove redundant dsc power gating from init_hw
- Power down hardware if timer not trigger
- Correct Slice reset calculation
- Enable 3-plane MPO for DCN31
- Set fec register init value
- Remove SW w/a for HDCP 1.4 1A-07 failure based on ECO fix
- Create underflow interrupt IRQ type

Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h b/drivers/gpu/drm/amd/display/dc/dc.h
index ced40fe218ac..ef286aa30294 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -47,7 +47,7 @@ struct aux_payload;
 struct set_config_cmd_payload;
 struct dmub_notification;
 
-#define DC_VER "3.2.178"
+#define DC_VER "3.2.179"
 
 #define MAX_SURFACES 3
 #define MAX_PLANES 6
-- 
2.35.1

[PATCH 16/16] drm/amd/display: Fix allocate_mst_payload assert on resume

[Alex Hung]

From: Roman Li <Roman.Li@amd.com>

[Why]
On resume we do link detection for all non-MST connectors.
MST is handled separately. However the condition for telling
if connector is on mst branch is not enough for mst hub case.
Link detection for mst branch link leads to mst topology reset.
That causes assert in dc_link_allocate_mst_payload()

[How]
Use link type as indicator for mst link.

Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
---
 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 6633df7682ce..cbeb9db1014b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2714,7 +2714,8 @@ static int dm_resume(void *handle)
 		 * this is the case when traversing through already created
 		 * MST connectors, should be skipped
 		 */
-		if (aconnector->mst_port)
+		if (aconnector->dc_link &&
+		    aconnector->dc_link->type == dc_connection_mst_branch)
 			continue;
 
 		mutex_lock(&aconnector->hpd_lock);
-- 
2.35.1

AMD Display Core (DC) patches (was: [PATCH 13/16] drm/amd/display: Revert FEC check in validation)

[Paul Menzel]

[Cc: +dri-devel@lists.freedesktop.org, +Daniel Vetter, +Alexander 
Deucher, +Greg KH]


Dear Alex,


I am a little confused and upset about how Display Core patches are 
handled in the Linux kernel.


Am 25.03.22 um 23:53 schrieb Alex Hung:
> From: Martin Leung <Martin.Leung@amd.com>

git puts a line “This reverts commit …” into the commit message, when 
something is reverted. Why isn’t this here? Right now, commit 
7d56a154e22f, reverted here, is proposed for the stable series. I guess, 
because these indicators and meta data are missing.

> why and how:
> causes failure on install on certain machines

Why are such kind of commit messages accepted? What does “failure on 
install” even mean? Why can’t the machine configuration be documented so 
it can be reproduced, when necessary.

No less confusing, the date you posted it on amd-gfx is from March 25th, 
2022, but the author date of the commit in agd5f/amd-staging-drm-next is 
`Fri Mar 18 11:12:36 2022 -0400`. Why is the patch missing the Date 
field then?

> Reviewed-by: George Shen <George.Shen@amd.com>
> Acked-by: Alex Hung <alex.hung@amd.com>
> Signed-off-by: Martin Leung <Martin.Leung@amd.com>

Shouldn’t the Signed-off-by line by the author go first?

You committed this on `Mon Mar 28 08:26:48 2022 -0600`, while you posted 
the patch on amd-gfx on Friday. How should *proper* review happen over 
the weekend?

> ---
>   drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ----
>   1 file changed, 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 f2ad8f58e69c..c436db416708 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -1496,10 +1496,6 @@ bool dc_validate_boot_timing(const struct dc *dc,
>   	if (!link->link_enc->funcs->is_dig_enabled(link->link_enc))
>   		return false;
>   
> -	/* Check for FEC status*/
> -	if (link->link_enc->funcs->fec_is_active(link->link_enc))
> -		return false;
> -
>   	enc_inst = link->link_enc->funcs->get_dig_frontend(link->link_enc);
>   
>   	if (enc_inst == ENGINE_ID_UNKNOWN)

The patch reverted here, also lacked proper review, had a to-be desired 
commit message, did not follow the Linux kernel coding style (missing 
space before the comment terminator), so should not have been committed 
in the first place.

Seeing how many people are in the Cc list, I would have hoped, that 
somebody noticed and commented. The current state also makes it really 
hard for non-AMD employees to get the necessary information to do proper 
reviews as the needed documentation and information is non-public. So 
good/excellent commit messages are a must. I think to remember, you 
replied to me once, that Display Core patches are shared also with the 
Microsoft Windows driver, restricting the workflow options. But I think 
the issues I mentioned are unrelated. I know graphics hardware is very 
complex, but if quality of the commits and review would be improved, 
hopefully it saves time for everyone in the end, as less bugs are 
introduced.

Could AMD team please address these issues as soon as possible?


Kind regards,

Paul

AMD Display Core (DC) patches (was: [PATCH 13/16] drm/amd/display: Revert FEC check in validation)

[Paul Menzel]

[Cc: +dri-devel@lists.freedesktop.org, +Daniel Vetter, +Alexander 
Deucher, +Greg KH]


Dear Alex,


I am a little confused and upset about how Display Core patches are 
handled in the Linux kernel.


Am 25.03.22 um 23:53 schrieb Alex Hung:
> From: Martin Leung <Martin.Leung@amd.com>

git puts a line “This reverts commit …” into the commit message, when 
something is reverted. Why isn’t this here? Right now, commit 
7d56a154e22f, reverted here, is proposed for the stable series. I guess, 
because these indicators and meta data are missing.

> why and how:
> causes failure on install on certain machines

Why are such kind of commit messages accepted? What does “failure on 
install” even mean? Why can’t the machine configuration be documented so 
it can be reproduced, when necessary.

No less confusing, the date you posted it on amd-gfx is from March 25th, 
2022, but the author date of the commit in agd5f/amd-staging-drm-next is 
`Fri Mar 18 11:12:36 2022 -0400`. Why is the patch missing the Date 
field then?

> Reviewed-by: George Shen <George.Shen@amd.com>
> Acked-by: Alex Hung <alex.hung@amd.com>
> Signed-off-by: Martin Leung <Martin.Leung@amd.com>

Shouldn’t the Signed-off-by line by the author go first?

You committed this on `Mon Mar 28 08:26:48 2022 -0600`, while you posted 
the patch on amd-gfx on Friday. How should *proper* review happen over 
the weekend?

> ---
>   drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ----
>   1 file changed, 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 f2ad8f58e69c..c436db416708 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -1496,10 +1496,6 @@ bool dc_validate_boot_timing(const struct dc *dc,
>   	if (!link->link_enc->funcs->is_dig_enabled(link->link_enc))
>   		return false;
>   
> -	/* Check for FEC status*/
> -	if (link->link_enc->funcs->fec_is_active(link->link_enc))
> -		return false;
> -
>   	enc_inst = link->link_enc->funcs->get_dig_frontend(link->link_enc);
>   
>   	if (enc_inst == ENGINE_ID_UNKNOWN)

The patch reverted here, also lacked proper review, had a to-be desired 
commit message, did not follow the Linux kernel coding style (missing 
space before the comment terminator), so should not have been committed 
in the first place.

Seeing how many people are in the Cc list, I would have hoped, that 
somebody noticed and commented. The current state also makes it really 
hard for non-AMD employees to get the necessary information to do proper 
reviews as the needed documentation and information is non-public. So 
good/excellent commit messages are a must. I think to remember, you 
replied to me once, that Display Core patches are shared also with the 
Microsoft Windows driver, restricting the workflow options. But I think 
the issues I mentioned are unrelated. I know graphics hardware is very 
complex, but if quality of the commits and review would be improved, 
hopefully it saves time for everyone in the end, as less bugs are 
introduced.

Could AMD team please address these issues as soon as possible?


Kind regards,

Paul

Re: AMD Display Core (DC) patches (was: [PATCH 13/16] drm/amd/display: Revert FEC check in validation)

[Greg KH]

On Tue, Apr 12, 2022 at 08:52:11AM +0200, Paul Menzel wrote:
> > Reviewed-by: George Shen <George.Shen@amd.com>
> > Acked-by: Alex Hung <alex.hung@amd.com>
> > Signed-off-by: Martin Leung <Martin.Leung@amd.com>
> 
> Shouldn’t the Signed-off-by line by the author go first?

No, this is the correct order.

thanks,

greg k-h

Re: AMD Display Core (DC) patches (was: [PATCH 13/16] drm/amd/display: Revert FEC check in validation)

[Greg KH]

On Tue, Apr 12, 2022 at 08:52:11AM +0200, Paul Menzel wrote:
> > Reviewed-by: George Shen <George.Shen@amd.com>
> > Acked-by: Alex Hung <alex.hung@amd.com>
> > Signed-off-by: Martin Leung <Martin.Leung@amd.com>
> 
> Shouldn’t the Signed-off-by line by the author go first?

No, this is the correct order.

thanks,

greg k-h

Re: AMD Display Core (DC) patches (was: [PATCH 13/16] drm/amd/display: Revert FEC check in validation)

[Alex Deucher]

On Tue, Apr 12, 2022 at 2:52 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>
> [Cc: +dri-devel@lists.freedesktop.org, +Daniel Vetter, +Alexander
> Deucher, +Greg KH]
>
>
> Dear Alex,
>
>
> I am a little confused and upset about how Display Core patches are
> handled in the Linux kernel.
>
>
> Am 25.03.22 um 23:53 schrieb Alex Hung:
> > From: Martin Leung <Martin.Leung@amd.com>
>
> git puts a line “This reverts commit …” into the commit message, when
> something is reverted. Why isn’t this here? Right now, commit
> 7d56a154e22f, reverted here, is proposed for the stable series. I guess,
> because these indicators and meta data are missing.

Sasha's tools proposed to pick it up which I often struggle with.
It's very useful, but at the same time, we don't have the bandwidth to
test every combination of patches that Sacha  proposes on every stable
kernel.  The additional metadata would be useful, but I'm not sure if
it would solve this problem.  This patch would likely be picked up by
Sasha as well once it landed.

>
> > why and how:
> > causes failure on install on certain machines
>
> Why are such kind of commit messages accepted? What does “failure on
> install” even mean? Why can’t the machine configuration be documented so
> it can be reproduced, when necessary.
>
> No less confusing, the date you posted it on amd-gfx is from March 25th,
> 2022, but the author date of the commit in agd5f/amd-staging-drm-next is
> `Fri Mar 18 11:12:36 2022 -0400`. Why is the patch missing the Date
> field then?
>
> > Reviewed-by: George Shen <George.Shen@amd.com>
> > Acked-by: Alex Hung <alex.hung@amd.com>
> > Signed-off-by: Martin Leung <Martin.Leung@amd.com>
>
> Shouldn’t the Signed-off-by line by the author go first?
>
> You committed this on `Mon Mar 28 08:26:48 2022 -0600`, while you posted
> the patch on amd-gfx on Friday. How should *proper* review happen over
> the weekend?
>
> > ---
> >   drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ----
> >   1 file changed, 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 f2ad8f58e69c..c436db416708 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > @@ -1496,10 +1496,6 @@ bool dc_validate_boot_timing(const struct dc *dc,
> >       if (!link->link_enc->funcs->is_dig_enabled(link->link_enc))
> >               return false;
> >
> > -     /* Check for FEC status*/
> > -     if (link->link_enc->funcs->fec_is_active(link->link_enc))
> > -             return false;
> > -
> >       enc_inst = link->link_enc->funcs->get_dig_frontend(link->link_enc);
> >
> >       if (enc_inst == ENGINE_ID_UNKNOWN)
>
> The patch reverted here, also lacked proper review, had a to-be desired
> commit message, did not follow the Linux kernel coding style (missing
> space before the comment terminator), so should not have been committed
> in the first place.
>
> Seeing how many people are in the Cc list, I would have hoped, that
> somebody noticed and commented. The current state also makes it really
> hard for non-AMD employees to get the necessary information to do proper
> reviews as the needed documentation and information is non-public. So
> good/excellent commit messages are a must. I think to remember, you
> replied to me once, that Display Core patches are shared also with the
> Microsoft Windows driver, restricting the workflow options. But I think
> the issues I mentioned are unrelated. I know graphics hardware is very
> complex, but if quality of the commits and review would be improved,
> hopefully it saves time for everyone in the end, as less bugs are
> introduced.

I agree that good commit messages are ideal and we should strive for
them, but this is certainly not limited to GPUs.
Subsystems all require a certain amount of assumed knowledge when it
comes to commit messages.

At the same time, I think it would be good to set expectations.  Too
many frivolous review comments and escalations tends to turn
people off even if they are well intentioned.  There are always new
people becoming kernel developers that may not have had
a lot of previous kernel experience.  That said, to the AMD
developers, please try and address every comment.

Alex

Re: AMD Display Core (DC) patches (was: [PATCH 13/16] drm/amd/display: Revert FEC check in validation)

[Alex Deucher]

On Tue, Apr 12, 2022 at 2:52 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>
> [Cc: +dri-devel@lists.freedesktop.org, +Daniel Vetter, +Alexander
> Deucher, +Greg KH]
>
>
> Dear Alex,
>
>
> I am a little confused and upset about how Display Core patches are
> handled in the Linux kernel.
>
>
> Am 25.03.22 um 23:53 schrieb Alex Hung:
> > From: Martin Leung <Martin.Leung@amd.com>
>
> git puts a line “This reverts commit …” into the commit message, when
> something is reverted. Why isn’t this here? Right now, commit
> 7d56a154e22f, reverted here, is proposed for the stable series. I guess,
> because these indicators and meta data are missing.

Sasha's tools proposed to pick it up which I often struggle with.
It's very useful, but at the same time, we don't have the bandwidth to
test every combination of patches that Sacha  proposes on every stable
kernel.  The additional metadata would be useful, but I'm not sure if
it would solve this problem.  This patch would likely be picked up by
Sasha as well once it landed.

>
> > why and how:
> > causes failure on install on certain machines
>
> Why are such kind of commit messages accepted? What does “failure on
> install” even mean? Why can’t the machine configuration be documented so
> it can be reproduced, when necessary.
>
> No less confusing, the date you posted it on amd-gfx is from March 25th,
> 2022, but the author date of the commit in agd5f/amd-staging-drm-next is
> `Fri Mar 18 11:12:36 2022 -0400`. Why is the patch missing the Date
> field then?
>
> > Reviewed-by: George Shen <George.Shen@amd.com>
> > Acked-by: Alex Hung <alex.hung@amd.com>
> > Signed-off-by: Martin Leung <Martin.Leung@amd.com>
>
> Shouldn’t the Signed-off-by line by the author go first?
>
> You committed this on `Mon Mar 28 08:26:48 2022 -0600`, while you posted
> the patch on amd-gfx on Friday. How should *proper* review happen over
> the weekend?
>
> > ---
> >   drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ----
> >   1 file changed, 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 f2ad8f58e69c..c436db416708 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > @@ -1496,10 +1496,6 @@ bool dc_validate_boot_timing(const struct dc *dc,
> >       if (!link->link_enc->funcs->is_dig_enabled(link->link_enc))
> >               return false;
> >
> > -     /* Check for FEC status*/
> > -     if (link->link_enc->funcs->fec_is_active(link->link_enc))
> > -             return false;
> > -
> >       enc_inst = link->link_enc->funcs->get_dig_frontend(link->link_enc);
> >
> >       if (enc_inst == ENGINE_ID_UNKNOWN)
>
> The patch reverted here, also lacked proper review, had a to-be desired
> commit message, did not follow the Linux kernel coding style (missing
> space before the comment terminator), so should not have been committed
> in the first place.
>
> Seeing how many people are in the Cc list, I would have hoped, that
> somebody noticed and commented. The current state also makes it really
> hard for non-AMD employees to get the necessary information to do proper
> reviews as the needed documentation and information is non-public. So
> good/excellent commit messages are a must. I think to remember, you
> replied to me once, that Display Core patches are shared also with the
> Microsoft Windows driver, restricting the workflow options. But I think
> the issues I mentioned are unrelated. I know graphics hardware is very
> complex, but if quality of the commits and review would be improved,
> hopefully it saves time for everyone in the end, as less bugs are
> introduced.

I agree that good commit messages are ideal and we should strive for
them, but this is certainly not limited to GPUs.
Subsystems all require a certain amount of assumed knowledge when it
comes to commit messages.

At the same time, I think it would be good to set expectations.  Too
many frivolous review comments and escalations tends to turn
people off even if they are well intentioned.  There are always new
people becoming kernel developers that may not have had
a lot of previous kernel experience.  That said, to the AMD
developers, please try and address every comment.

Alex