linux-dev/drivers/gpu/drm/amd/display/include, branch master

drm/amd/display: Refactor LTTPR mode selection

2022-09-29T13:41:46Z

[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 Signed-off-by: Michael Strauss Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Revise Sink device string ID

2022-09-19T19:16:26Z

[Why] The Sink device string ID1/ID2 use 5 bytes instead of 6 bytes, so the driver should compare the first 5 bytes only. Reviewed-by: Anthony Koo Acked-by: Wayne Lin Signed-off-by: Robin Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Added new DCN301 Asic Id

2022-09-19T19:14:05Z

[WHY] Adding new asic id for dcn301 Reviewed-by: Charlene Liu Acked-by: Wayne Lin Signed-off-by: Pavle Kotarac Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

Merge tag 'drm-misc-next-2022-09-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2022-09-11T12:03:07Z

drm-misc-next for v6.1-rc1: [airlied - fix sun4i_tv build] UAPI Changes: - Hide unregistered connectors from GETCONNECTOR ioctl. - drm/virtio no longer advertises LINEAR modifier, as it doesn't work. - Cross-subsystem Changes: - Fix GPF in udmabuf failure path. Core Changes: - Rework TTM placement to use intersect/compatible functions. - Drop legacy DP-MST support. - More DP-MST related fixes, and move all state into atomic. - Make DRM_MIPI_DBI select DRM_KMS_HELPER. - Add audio_infoframe packing for DP. - Add logging when some atomic check functions fail. - Assorted documentation updates and fixes. Driver Changes: - Assorted cleanups and fixes in msm, lcdif, nouveau, virtio, panel/ilitek, bridge/icn6211, tve200, gma500, bridge/*, panfrost, via, bochs, qxl, sun4i. - Add add AUO B133UAN02.1, IVO M133NW4J-R3, Innolux N120ACA-EA1 eDP panels. - Improve DP-MST modeset state handling in amdgpu, nouveau, i915. - Drop DP-MST from radeon driver, it was broken and only user of legacy DP-MST. - Handle unplugging better in vc4. - Simplify drm cmdparser tests. - Add DP support to ti-sn65dsi86. - Add MT8195 DP support to mediatek. - Support RGB565, XRGB64, and ARGB64 formats in vkms. - Convert sun4i tv support to atomic. - Refactor vc4/vec TV Modesetting, and fix timings. - Use atomic helpers instead of simple display helpers in ssd130x. Maintainer changes: - Add Douglas Anderson as reviewer for panel-edp. Signed-off-by: Dave Airlie From: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/a489485b-3ebc-c734-0f80-aed963d89efe@linux.intel.com

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

2022-08-23T20:54:09Z

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 Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: Sean Paul Acked-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-18-lyude@redhat.com

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

2022-08-23T20:53:33Z

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 Cc: Wayne Lin Cc: Fangzhi Zuo Acked-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-2-lyude@redhat.com

drm/amd/display: add chip revision to DCN32

2022-08-16T22:09:25Z

[Why & How] Add GC_11_0_3_A0 as a chip revision to the DCN32 family Reviewed-by: Rodrigo Siqueira Acked-by: Brian Chang Signed-off-by: Samson Tam Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Add reserved dc_log_type.

2022-08-16T22:07:28Z

Reviewed-by: Anthony Koo Acked-by: Brian Chang Signed-off-by: Ian Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: change family id name for DCN314

2022-08-10T19:10:12Z

GC version is 11.0.1 rather than 11.0.2 Signed-off-by: Yifan Zhang Reviewed-by: Roman Li Signed-off-by: Alex Deucher

drm/amd/display: Add DCN314 version identifiers

2022-07-14T00:57:05Z

DCN 3.1.4 version and family ids Signed-off-by: Roman Li Signed-off-by: Alex Deucher