Patch "drm/tidss: Fix sync-lost issue with two displays" has been added to the 6.6-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    drm/tidss: Fix sync-lost issue with two displays

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-tidss-fix-sync-lost-issue-with-two-displays.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 19180ffd5e21fd5967f31c79464f95f7c2af853c
Author: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>
Date:   Tue Feb 13 10:16:37 2024 +0200

    drm/tidss: Fix sync-lost issue with two displays
    
    [ Upstream commit c079e2e113f2ec2803ba859bbb442a6ab82c96bd ]
    
    A sync lost issue can be observed with two displays, when moving a plane
    from one disabled display to an another disabled display, and then
    enabling the display to which the plane was moved to. The exact
    requirements for this to trigger are not clear.
    
    It looks like the issue is that the layers are left enabled in the first
    display's OVR registers. Even if the corresponding VP is disabled, it
    still causes an issue, as if the disabled VP and its OVR would still be
    in use, leading to the same VID being used by two OVRs. However, this is
    just speculation based on testing the DSS behavior.
    
    Experimentation shows that as a workaround, we can disable all the
    layers in the OVR when disabling a VP. There should be no downside to
    this, as the OVR is anyway effectively disabled if its VP is disabled,
    and it seems to solve the sync lost issue.
    
    However, there may be a bigger issue in play here, related to J721e
    erratum i2097 ("DSS: Disabling a Layer Connected to Overlay May Result
    in Synclost During the Next Frame"). Experimentation also shows that the
    OVR's CHANNELIN field has similar issue. So we may need to revisit this
    when we find out more about the core issue.
    
    Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
    Reviewed-by: Aradhya Bhatia <a-bhatia1@xxxxxx>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240213-tidss-fixes-v1-2-d709e8dfa505@xxxxxxxxxxxxxxxx
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
index 7c78c074e3a2e..1baa4ace12e15 100644
--- a/drivers/gpu/drm/tidss/tidss_crtc.c
+++ b/drivers/gpu/drm/tidss/tidss_crtc.c
@@ -269,6 +269,16 @@ static void tidss_crtc_atomic_disable(struct drm_crtc *crtc,
 
 	reinit_completion(&tcrtc->framedone_completion);
 
+	/*
+	 * If a layer is left enabled when the videoport is disabled, and the
+	 * vid pipeline that was used for the layer is taken into use on
+	 * another videoport, the DSS will report sync lost issues. Disable all
+	 * the layers here as a work-around.
+	 */
+	for (u32 layer = 0; layer < tidss->feat->num_planes; layer++)
+		dispc_ovr_enable_layer(tidss->dispc, tcrtc->hw_videoport, layer,
+				       false);
+
 	dispc_vp_disable(tidss->dispc, tcrtc->hw_videoport);
 
 	if (!wait_for_completion_timeout(&tcrtc->framedone_completion,




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux