Patch "drm/tidss: Fix initial plane zpos values" has been added to the 6.1-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 initial plane zpos values

to the 6.1-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-initial-plane-zpos-values.patch
and it can be found in the queue-6.1 subdirectory.

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



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

    drm/tidss: Fix initial plane zpos values
    
    [ Upstream commit 3ec948ccb2c4b99e8fbfdd950adbe92ea577b395 ]
    
    When the driver sets up the zpos property it sets the default zpos value
    to the HW id of the plane. That is fine as such, but as on many DSS
    versions the driver arranges the DRM planes in a different order than
    the HW planes (to keep the non-scalable planes first), this leads to odd
    initial zpos values. An example is J721e, where the initial zpos values
    for DRM planes are 1, 3, 0, 2.
    
    In theory the userspace should configure the zpos values properly when
    using multiple planes, and in that sense the initial zpos values
    shouldn't matter, but there's really no reason not to fix this and help
    the userspace apps which don't handle zpos perfectly. In particular,
    some versions of Weston seem to have issues dealing with the planes
    with the current default zpos values.
    
    So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
    
    Another option would be to configure the planes marked as primary planes
    to zpos 0. On a two display system this would give us plane zpos values
    of 0, 0, 1, 2. The end result and behavior would be very similar in this
    option, and I'm not aware that this would actually help us in any way.
    So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
    
    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-1-d709e8dfa505@xxxxxxxxxxxxxxxx
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
index 42d50ec5526d7..435b3b66ae632 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -211,7 +211,7 @@ struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
 
 	drm_plane_helper_add(&tplane->plane, &tidss_plane_helper_funcs);
 
-	drm_plane_create_zpos_property(&tplane->plane, hw_plane_id, 0,
+	drm_plane_create_zpos_property(&tplane->plane, tidss->num_planes, 0,
 				       num_planes - 1);
 
 	ret = drm_plane_create_color_properties(&tplane->plane,




[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