drm/amd/display: Update 128b/132b downspread factor to 0.3%

[Why]
Updating downspread factor to 0.3% to add additional margin to account
for potential link rate deviations (up to 300ppm as per the D

drm/amd/display: Update 128b/132b downspread factor to 0.3%

[Why]
Updating downspread factor to 0.3% to add additional margin to account
for potential link rate deviations (up to 300ppm as per the DP spec).

Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Acked-by: Alan Liu <haoping.liu@amd.com>
Signed-off-by: George Shen <george.shen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: merge dc_link.h into dc.h and dc_types.h

[why]
Remove the need to include dc_link.h separately. dc.h should contain
everything needed on DM side.

[How]
Merge dc_link.h into dc.h an

drm/amd/display: merge dc_link.h into dc.h and dc_types.h

[why]
Remove the need to include dc_link.h separately. dc.h should contain
everything needed on DM side.

[How]
Merge dc_link.h into dc.h and dc_types.h so DM only needs to include
dc.h to use all link public functions.

Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: add support for three new square pattern variants from DP2.1 specs

[why]
DP2.1 specs has brought 3 new variants of sqaure patterns with different
pre-shoot and de-emphasis equalizat

drm/amd/display: add support for three new square pattern variants from DP2.1 specs

[why]
DP2.1 specs has brought 3 new variants of sqaure patterns with different
pre-shoot and de-emphasis equalization requirements. The commit adds
logic to identify these variants and apply corresponding eqaulization
requirements into hardware lane settings.

Reviewed-by: George Shen <George.Shen@amd.com>
Acked-by: Jasdeep Dhillon <jdhillon@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Refactor LTTPR mode selection

[WHY]
Previously, LTTPR mode was decided during detection which makes
link training inflexible as mode can't be dynamically changed.

[HOW]
-Remove ltt

drm/amd/display: Refactor LTTPR mode selection

[WHY]
Previously, LTTPR mode was decided during detection which makes
link training inflexible as mode can't be dynamically changed.

[HOW]
-Remove lttpr_mode from link struct, and move to link training settings
-Defer choosing LTTPR mode until link training

Other DP changes included:
-Only use fixed vs/pe link training sequence for 8b/10b encoding
-Restrict fixed vs aux timeout workaround to Yellow Carp family

Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Signed-off-by: Michael Strauss <michael.strauss@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/display/dp_mst: Move all payload info into the atomic state

Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payl

drm/display/dp_mst: Move all payload info into the atomic state

Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on, as there's a lot of duplicated logic that doesn't really need to be
here. As well, this should make introducing features like fallback link
retraining and DSC support far easier.

Since the old payload code was pretty gnarly and there's a Lot of changes
here, I expect this might be a bit difficult to review. So to make things
as easy as possible for reviewers, I'll sum up how both the old and new
code worked here (it took me a while to figure this out too!).

The old MST code basically worked by maintaining two different payload
tables - proposed_vcpis, and payloads. proposed_vcpis would hold the
modified payload we wanted to push to the topology, while payloads held the
payload table that was currently programmed in hardware. Modifications to
proposed_vcpis would be handled through drm_dp_allocate_vcpi(),
drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then, they
would be pushed via drm_dp_mst_update_payload_step1() and
drm_dp_mst_update_payload_step2().

Furthermore, it's important to note how adding and removing VC payloads
actually worked with drm_dp_mst_update_payload_step1(). When a VC payload
is removed from the VC table, all VC payloads which come after the removed
VC payload's slots must have their time slots shifted towards the start of
the table. The old code handles this by looping through the entire payload
table and recomputing the start slot for every payload in the topology from
scratch. While very much overkill, this ends up doing the right thing
because we always order the VCPIs for payloads from first to last starting
timeslot.

It's important to also note that drm_dp_mst_update_payload_step2() isn't
actually limited to updating a single payload - the driver can use it to
queue up multiple payload changes so that as many of them can be sent as
possible before waiting for the ACT. This is -technically- not against
spec, but as Wayne Lin has pointed out it's not consistently implemented
correctly in hubs - so it might as well be.

drm_dp_mst_update_payload_step2() is pretty self explanatory and basically
the same between the old and new code, save for the fact we don't have a
second step for deleting payloads anymore -and thus rename it to
drm_dp_mst_add_payload_step2().

The new payload code stores all of the current payload info within the MST
atomic state and computes as much of the state as possible ahead of time.
This has the one exception of the starting timeslots for payloads, which
can't be determined at atomic check time since the starting time slots will
vary depending on what order CRTCs are enabled in the atomic state - which
varies from driver to driver. These are still stored in the atomic MST
state, but are only copied from the old MST state during atomic commit
time. Likewise, this is when new start slots are determined.

Adding/removing payloads now works much more closely to how things are
described in the spec. When we delete a payload, we loop through the
current list of payloads and update the start slots for any payloads whose
time slots came after the payload we just deleted. Determining the starting
time slots for new payloads being added is done by simply keeping track of
where the end of the VC table is in
drm_dp_mst_topology_mgr->next_start_slot. Additionally, it's worth noting
that we no longer have a single update_payload() function. Instead, we now
have drm_dp_mst_add_payload_step1|2() and drm_dp_mst_remove_payload(). As
such, it's now left it up to the driver to figure out when to add or remove
payloads. The driver already knows when it's disabling/enabling CRTCs, so
it also already knows when payloads should be added or removed.

Changes since v1:
* Refactor around all of the completely dead code changes that are
happening in amdgpu for some reason when they really shouldn't even be
there in the first place… :\
* Remove mention of sending one ACT per series of payload updates. As Wayne
Lin pointed out, there are apparently hubs on the market that don't work
correctly with this scheme and require a separate ACT per payload update.
* Fix accidental drop of mst_mgr.lock - Wayne Lin
* Remove mentions of allowing multiple ACT updates per payload change,
mention that this is a result of vendors not consistently supporting this
part of the spec and requiring a unique ACT for each payload change.
* Get rid of reference to drm_dp_mst_port in DC - turns out I just got
myself confused by DC and we don't actually need this.
Changes since v2:
* Get rid of fix for not sending payload deallocations if ddps=0 and just
go back to wayne's fix

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-18-lyude@redhat.com

show more ...

drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)

Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of time

drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)

Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-2-lyude@redhat.com

show more ...

drm/amd/display: rename lane_settings to hw_lane_settings

[why]
This is one of the major steps to decouple hw lane settings
from dpcd lane settings.

Tested-by: Daniel Wheeler <daniel.wheeler@amd.co

drm/amd/display: rename lane_settings to hw_lane_settings

[why]
This is one of the major steps to decouple hw lane settings
from dpcd lane settings.

Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Alan Liu <HaoPing.Liu@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: lower lane count first when CR done partially fails in EQ

[why]
According to DP specs, in EQ DONE phase of link training, we
should lower lane count when at least one CR DONE bit is

drm/amd/display: lower lane count first when CR done partially fails in EQ

[why]
According to DP specs, in EQ DONE phase of link training, we
should lower lane count when at least one CR DONE bit is set to 1, while
lower link rate when all CR DONE bits are 0s. However in our code, we will
treat both cases as latter. This is not exactly correct based on the specs
expectation.

[how]
Check lane0 CR DONE bit when it is still set but CR DONE fails,
we treat it as a partial CR DONE failure in EQ DONE phase, we
will follow the same fallback flow as when ED DONE fails in EQ
DONE phase.

Reviewed-by: George Shen <George.Shen@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

Revert "drm/amd/display: Refactor LTTPR cap retrieval"

This reverts commit 3b90318d44f87a3582f876802253a7748d270385.

[WHY]
Regressions unintentionally caused by change,
reverting until this can be

Revert "drm/amd/display: Refactor LTTPR cap retrieval"

This reverts commit 3b90318d44f87a3582f876802253a7748d270385.

[WHY]
Regressions unintentionally caused by change,
reverting until this can be resolved.

Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Michael Strauss <michael.strauss@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Refactor LTTPR cap retrieval

[WHY]
Split LTTPR mode selection between platform support and downstream link support

Reviewed-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Acked-by:

drm/amd/display: Refactor LTTPR cap retrieval

[WHY]
Split LTTPR mode selection between platform support and downstream link support

Reviewed-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Acked-by: Stylon Wang <stylon.wang@amd.com>
Signed-off-by: Michael Strauss <michael.strauss@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Drop DCN for DP2.x logic

[Why & How]
DCN guard is not necessary for DP2.x relevant logic.
Drop them.

v2: squash in fix for misplaced #endif (Alex)

Tested-by: Daniel Wheeler <danie

drm/amd/display: Drop DCN for DP2.x logic

[Why & How]
DCN guard is not necessary for DP2.x relevant logic.
Drop them.

v2: squash in fix for misplaced #endif (Alex)

Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Jerry Zuo <Jerry.Zuo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: add two lane settings training options

[why]
option 1: disallow different lanes to have different lane settings
option 2: dpcd lane settings will always use the same hw lane setting

drm/amd/display: add two lane settings training options

[why]
option 1: disallow different lanes to have different lane settings
option 2: dpcd lane settings will always use the same hw lane settings
even if it doesn't match requested lane adjust

Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: decouple hw_lane_settings from dpcd_lane_settings

[why]
As DP features expands, we have encountered many situations where we
must configure a different DPCD lane setting from hw lan

drm/amd/display: decouple hw_lane_settings from dpcd_lane_settings

[why]
As DP features expands, we have encountered many situations where we
must configure a different DPCD lane setting from hw lane settings we
output. The change is to decouple hw lane settings from dpcd lane
settings to provide flexibility to configure dpcd and hw individually.

Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: implement decide lane settings

[why]
Decouple lane settings decision logic all to its own function. The
function takes in lane adjust array and link training settings and
decide wha

drm/amd/display: implement decide lane settings

[why]
Decouple lane settings decision logic all to its own function. The
function takes in lane adjust array and link training settings and
decide what hw lane setting and dpcd lane setting should be used.

Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Implement fixed DP drive settings

[Why]
Currently there are use cases that require DP link to maintain fixed VS
and PE in HW regardless of what the sink requests. BIOS integrated in

drm/amd/display: Implement fixed DP drive settings

[Why]
Currently there are use cases that require DP link to maintain fixed VS
and PE in HW regardless of what the sink requests. BIOS integrated info
table will specify whether we need to use the fixed drive settings, and
the drive settings to use.

[How]
Implement changes to parse the integrated info table and set the fixed
drive settings accordingly.

Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Acked-by: Agustin Gutierrez <agustin.gutierrez@amd.com>
Signed-off-by: George Shen <george.shen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add DPCD writes at key points

This reverts commit "Revert "Add DPCD writes at key points" ".
The following patch will fix the system hang issue.

v2: squash in indentation warning f

drm/amd/display: Add DPCD writes at key points

This reverts commit "Revert "Add DPCD writes at key points" ".
The following patch will fix the system hang issue.

v2: squash in indentation warning fix

Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
Acked-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add DP 2.0 SST DC Support

1. Retrieve 128/132b link cap.
2. 128/132b link training and payload allocation.
3. UHBR10 link rate support.

[squash in warning fixes - Alex]

Signed-off

drm/amd/display: Add DP 2.0 SST DC Support

1. Retrieve 128/132b link cap.
2. 128/132b link training and payload allocation.
3. UHBR10 link rate support.

[squash in warning fixes - Alex]

Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add DP 2.0 HPO Link Encoder

HW Blocks:

+--------+ +-----+ +------+
| OPTC | | HDA | | HUBP |
+--------+ +-----+ +------+
| |

drm/amd/display: Add DP 2.0 HPO Link Encoder

HW Blocks:

+--------+ +-----+ +------+
| OPTC | | HDA | | HUBP |
+--------+ +-----+ +------+
| | |
| | |
HPO ====|==========|========|====
| | v |
| | +-----+ |
| | | APG | |
| | +-----+ |
| | | |
| v v v
| +---------------------+
| | HPO Stream Encoder |
| +---------------------+
| |
| v
| +--------------------+
| | HPO Link Encoder |
v +--------------------+

[squash in warning fixes - Alex]

Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: add exit training mode and update channel coding in LT

[why]
As recommended by DP specs, source needs to make sure
DPRX exits previous LT mode before configuring new LT params
Nofit

drm/amd/display: add exit training mode and update channel coding in LT

[why]
As recommended by DP specs, source needs to make sure
DPRX exits previous LT mode before configuring new LT params
Nofity what channel coding mode we will use for current link training.

Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: consider channel coding in configure lttpr mode

[why]
Some lttpr configuration steps are exclusive to 8b/10b channel
coding mode. We need to take channel conding into account.

Sign

drm/amd/display: consider channel coding in configure lttpr mode

[why]
Some lttpr configuration steps are exclusive to 8b/10b channel
coding mode. We need to take channel conding into account.

Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Reviewed-by: George Shen <George.Shen@amd.com>
Acked-by: Stylon Wang <stylon.wang@amd.com>
Acked-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: minor dp link training refactor

[how]
The change includes some dp link training refactors:
1. break down is_ch_eq_done to checking individual conditions in
its own function.
2. upda

drm/amd/display: minor dp link training refactor

[how]
The change includes some dp link training refactors:
1. break down is_ch_eq_done to checking individual conditions in
its own function.
2. update dpcd_set_training_pattern to take in dc_dp_training_pattern
as input.
3. moving lttpr mode struct definition into link_service_types.h

Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Reviewed-by: George Shen <George.Shen@amd.com>
Acked-by: Stylon Wang <stylon.wang@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add fallback and abort paths for DP link training.

[Why]
When enabling a DisplayPort stream:
- Optionally reducing link bandwidth between failed link training
attempts should progre

drm/amd/display: Add fallback and abort paths for DP link training.

[Why]
When enabling a DisplayPort stream:
- Optionally reducing link bandwidth between failed link training
attempts should progressively relax training requirements.
- Abandoning link training altogether if a sink is unplugged should
avoid unnecessary training attempts.

[How]
- Add fallback parameter to DP link training function and reduce link
bandwidth between failed training attempts as long as stream bandwidth
requirements are met.
- Add training status for sink unplug and abort training when this
status is reported.

Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Stylon Wang <stylon.wang@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: add option to override cr training pattern

Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexan

drm/amd/display: add option to override cr training pattern

Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Check lane status again after link training done

[Why]
Some monitors could suffer symbol unlock but cannot send HPD IRQ to
notic source device to handle link loss. This makes monito

drm/amd/display: Check lane status again after link training done

[Why]
Some monitors could suffer symbol unlock but cannot send HPD IRQ to
notic source device to handle link loss. This makes monitor stuck in
abnormal status and causes black screen.

[How]
According to the suggestion from scalar vendor, to check lane status
again after link training done. That can improve the comaptibility
from current production monitors.

Signed-off-by: Martin Tsai <martin.tsai@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Eryk Brol <eryk.brol@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Check lane status again after link training done

[Why]
Some monitors could suffer symbol unlock but cannot send HPD IRQ to
notic source device to handle link loss. This makes monito

drm/amd/display: Check lane status again after link training done

[Why]
Some monitors could suffer symbol unlock but cannot send HPD IRQ to
notic source device to handle link loss. This makes monitor stuck in
abnormal status and causes black screen.

[How]
According to the suggestion from scalar vendor, to check lane status
again after link training done. That can improve the comaptibility
from current production monitors.

Signed-off-by: Martin Tsai <martin.tsai@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Eryk Brol <eryk.brol@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...