[Why]
When assert in dp_retrieve_lttpr_cap() is hit, dmesg has traces like:
RIP: 0010:dp_retrieve_lttpr_cap+0xcc/0x1a0 [amdgpu]
Call Trace:
<TASK>
dp_retrieve_lttpr_cap+0xcc/0x1a0 [amdgpu]
report_bug+0x1e8/0x240
handle_bug+0x46/0x80
link_detect+0x35/0x580 [amdgpu]
It happens when LTTPRs fail to increment dpcd repeater count.
We have a recovery action in place for such cases.
Assert is misleading, an indicative error in dmesg is more useful.
[How]
Remove ASSERT and use DC_LOG_ERROR instead.
Reviewed-by: Michael Strauss <michael.strauss@amd.com>
Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
Signed-off-by: Roman Li <roman.li@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* Override count to 1 if we receive a known bad count (0 or an invalid value) */
if ((link->chip_caps & EXT_DISPLAY_PATH_CAPS__DP_FIXED_VS_EN) &&
(dp_parse_lttpr_repeater_count(link->dpcd_caps.lttpr_caps.phy_repeater_cnt) == 0)) {
- ASSERT(0);
+ /* If you see this message consistently, either the host platform has FIXED_VS flag
+ * incorrectly configured or the sink device is returning an invalid count.
+ */
+ DC_LOG_ERROR("lttpr_caps phy_repeater_cnt is 0x%x, forcing it to 0x80.",
+ link->dpcd_caps.lttpr_caps.phy_repeater_cnt);
link->dpcd_caps.lttpr_caps.phy_repeater_cnt = 0x80;
DC_LOG_DC("lttpr_caps forced phy_repeater_cnt = %d\n", link->dpcd_caps.lttpr_caps.phy_repeater_cnt);
}