linux/include/drm/display, branch v6.3

drm/display/dp_mst: Add drm_atomic_get_old_mst_topology_state()

2023-02-13T19:37:49Z

Add a function to get the old MST topology state, required by a follow-up i915 patch. While at it clarify the code comment of drm_atomic_get_new_mst_topology_state() and add _new prefix to the new state pointer to remind about its difference from the old state. v2: Use old_/new_ prefixes for the state pointers. (Ville) Cc: Lyude Paul Cc: Ville Syrjälä Cc: stable@vger.kernel.org # 6.1 Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä Reviewed-by: Lyude Paul Acked-by: Lyude Paul Acked-by: Daniel Vetter Acked-by: Wayne Lin Acked-by: Jani Nikula Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-3-imre.deak@intel.com

drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()

2023-02-13T19:37:29Z

Atm, drm_dp_remove_payload() uses the same payload state to both get the vc_start_slot required for the payload removal DPCD message and to deduct time_slots from vc_start_slot of all payloads after the one being removed. The above isn't always correct, as vc_start_slot must be the up-to-date version contained in the new payload state, but time_slots must be the one used when the payload was previously added, contained in the old payload state. The new payload's time_slots can change vs. the old one if the current atomic commit changes the corresponding mode. This patch let's drivers pass the old and new payload states to drm_dp_remove_payload(), but keeps these the same for now in all drivers not to change the behavior. A follow-up i915 patch will pass in that driver the correct old and new states to the function. Cc: Lyude Paul Cc: Ville Syrjälä Cc: Ben Skeggs Cc: Karol Herbst Cc: Harry Wentland Cc: Alex Deucher Cc: Wayne Lin Cc: stable@vger.kernel.org # 6.1 Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä Reviewed-by: Lyude Paul Acked-by: Lyude Paul Acked-by: Daniel Vetter Acked-by: Wayne Lin Acked-by: Jani Nikula Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-2-imre.deak@intel.com

Merge tag 'drm-intel-next-2023-01-12' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

2023-01-16T19:23:08Z

drm/i915 feature pull #1 for v6.3: Features and functionality: - Meteorlake display enabling (Animesh, Luca, Stan, Jouni, Anusha) - DP MST DSC support (Stan) - Gamma/degamma readout support for the state checker (Ville) - Enable SDP split support for DP 2.0 (Vinod) - Add probe blocking support to i915.force_probe parameter (Rodrigo) - Enable Xe HP 4tile support (Jonathan) Refactoring and cleanups: - Color refactoring, especially related to DSB usage (Ville) - DSB refactoring (Ville) - DVO refactoring (Ville) - Backlight register and logging cleanups (Jani) - Avoid display direct calls to uncore (Maarten, Jani) - Add new "soc" sub-directory (Jani) - Refactor DSC platform support checks (Swati) Fixes: - Interlace modes are no longer supported starting at display version 12 (Ankit) - Use polling read for aux control (Arun) - DMC firmware no longer requires specific versions (Gustavo) - Fix PSR flickering and freeze issues (Jouni) - Fix ICL+ DSI GPIO handling (Jani) - Ratelimit errors in display engine irqs (Lucas) - Fix DP MST DSC bpp and timeslot calculations (Stan) - Fix CDCLK squash and crawl sequences (Ville, Anusha) - Fix bigjoiner checks for fused pipes (Ville) - Fix ADP+ degamma LUT size (Ville) - Fix DVO ch7xxx and sil164 suspend/resume (Ville) - Fix memory leak in VBT parsing (Xia Fukun) - Fix VBT packet port selection for dual link DSI (Mikko Kovanen) - Fix SDP infoframe product string for discrete graphics (Clint) - Fix VLV/CHV HDMI/DP audio enable (Ville) - Fix VRR delays and calculations (Ville) - No longer disable transcoder for PHY test pattern change (Khaled) - Fix dual PPS handling (Ville) - Fix timeout and wait for DDI BUF CTL active after enabling (Ankit) Merges: - Backmerge drm-next to sync up with v6.2-rc1 (Jani) Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/87tu0wez34.fsf@intel.com

drm/display: Add missing Adaptive Sync DPCD definitions

2022-12-15T17:18:20Z

The missing DPCD definitions from DP2.0 spec is as follows: DOWNSPREAD_CTRL (107h): FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE (bit 6) For sink devices that support Adaptive-Sync operation and Panel Replay DPRX_FEATURE_ENUMERATION_LIST_CONT_1 (2214h): ADAPTIVE_SYNC_SDP_SUPPORTED (bit 0) Bit to check sink device has Adaptive-Sync capability AS_SDP_FIRST_HALF_LINE_OR_3840_PIXEL_CYCLE_WINDOW_NOT_SUPPORTED (bit 1) A sink device that clears this bit will generate VSync pulse leading edge of the HDMI output on the line count at which Adaptive-Sync SDP is received as long as source device transmits Adaptive-Sync SDP either in first line or first 3840 pixel cycles of the line whichever occurs first. VSC_EXT_SDP_FRAMEWORK_VERSION_1_SUPPORTED (bit 4) Bit to check sink device has SDP framework version 1 capability Signed-off-by: Sung Joon Kim Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher

drm: Add missing DP DSC extended capability definitions.

2022-12-13T16:17:52Z

Adding DP DSC register definitions, we might need for further DSC implementation, supporting MST and DP branch pass-through mode. v2: - Fixed checkpatch comment warning v3: - Removed function which is not yet used(Jani Nikula) Reviewed-by: Vinod Govindapillai Acked-by: Maarten Lankhorst Signed-off-by: Stanislav Lisovskiy Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-2-stanislav.lisovskiy@intel.com

Merge tag 'amd-drm-next-6.1-2022-09-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-next

2022-09-12T09:17:41Z

amd-drm-next-6.1-2022-09-08: amdgpu: - Mode2 reset for RDNA2 - Lots of new DC documentation - Add documentation about different asic families - DSC improvements - Aldebaran fixes - Misc spelling and grammar fixes - GFXOFF stats support for vangogh - DC frame size fixes - NBIO 7.7 updates - DCN 3.2 updates - DCN 3.1.4 Updates - SMU 13.x updates - Misc bug fixes - Rework DC register offset handling - GC 11.x updates - PSP 13.x updates - SDMA 6.x updates - GMC 11.x updates - SR-IOV updates - PSP fixes for TA unloading - DSC passthrough support - Misc code cleanups amdkfd: - ISA fixes for some GC 10.3 IPs - Misc code cleanups radeon: - Delayed work flush fix - Use time_after for some jiffies calculations drm: - DSC passthrough aux support Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20220908155202.57862-1-alexander.deucher@amd.com

video/hdmi: Add audio_infoframe packing for DP

2022-09-04T12:31:59Z

Similar to HDMI, DP uses audio infoframes as well which are structured very similar to the HDMI ones. This patch adds a helper function to pack the HDMI audio infoframe for DP, called hdmi_audio_infoframe_pack_for_dp(). hdmi_audio_infoframe_pack_only() is split into two parts. One of them packs the payload only and can be used for HDMI and DP. Also constify the frame parameter in hdmi_audio_infoframe_check() as it is passed to hdmi_audio_infoframe_check_only() which expects a const. Signed-off-by: Markus Schneider-Pargmann Signed-off-by: Guillaume Ranquet Signed-off-by: Bo-Chen Chen Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-3-rex-bc.chen@mediatek.com

drm/dp: add drm_dp_phy_name() for getting DP PHY name

2022-08-30T08:02:42Z

Add a helper for getting the DP PHY name. In the interest of caller simplicity and to avoid allocations and passing in of buffers, duplicate the const strings to return. It's a minor penalty to pay for simplicity in all the call sites. v2: Rebase, add kernel-doc, ensure non-NULL always Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/b08dc12a7e621a48ec35546d6cd1ed4b1434810d.1660553850.git.jani.nikula@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/display/dp_mst: Maintain time slot allocations when deleting payloads

2022-08-23T20:53:42Z

Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to indicate that we're about to delete a payload in the current atomic state. Since we're going to be dropping all of the legacy code for handling the payload table however, we need to be able to ensure that we still keep track of the current time slot allocations for each payload so we can reuse this info when asking the root MST hub to delete payloads. We'll also be using it to recalculate the start slots of each VC. So, let's keep track of the intent of a payload in drm_dp_atomic_payload by adding ->delete, which we set whenever we're planning on deleting a payload during the current atomic commit. 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-16-lyude@redhat.com