From: "Peng Hongchi/彭洪驰" <hongchi.peng@siengine.com>
To: "Peng Hongchi/彭洪驰" <hongchi.peng@siengine.com>,
"liviu.dudau@arm.com" <liviu.dudau@arm.com>
Cc: "maarten.lankhorst@linux.intel.com"
<maarten.lankhorst@linux.intel.com>,
"mripard@kernel.org" <mripard@kernel.org>,
"tzimmermann@suse.de" <tzimmermann@suse.de>,
"airlied@gmail.com" <airlied@gmail.com>,
"daniel@ffwll.ch" <daniel@ffwll.ch>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: 回复: [PATCH] drm: komeda: Fix an issue related to normalized zpos
Date: Wed, 21 Aug 2024 08:41:46 +0000 [thread overview]
Message-ID: <01446fc98394446eb82a6346953f4fd0@siengine.com> (raw)
In-Reply-To: <20240821081910.5062-1-hongchi.peng@siengine.com>
Hi, all:
I'm sorry that I forgot to add a pair of brackets, and I'll send it again soon.
Best Regards,
Hongchi Peng
-----邮件原件-----
发件人: hongchi.peng <hongchi.peng@siengine.com>
发送时间: 2024年8月21日 16:19
收件人: liviu.dudau@arm.com
抄送: maarten.lankhorst@linux.intel.com; mripard@kernel.org; tzimmermann@suse.de; airlied@gmail.com; daniel@ffwll.ch; dri-devel@lists.freedesktop.org; Peng Hongchi/彭洪驰 <hongchi.peng@siengine.com>
主题: [PATCH] drm: komeda: Fix an issue related to normalized zpos
We use komeda_crtc_normalize_zpos to normalize zpos of affected planes to their blending zorder in CU. If there's only one slave plane in affected planes and its layer_split property is enabled, order++ for its split layer, so that when calculating the normalized_zpos of master planes, the split layer of the slave plane is included, but the max_slave_zorder does not include the split layer and keep zero because there's only one slave plane in affacted planes, although we actually use two slave layers in this commit.
In most cases, this bug does not result in a commit failure, but assume the following situation:
slave_layer 0: zpos = 0, layer split enabled, normalized_zpos =
0;(use slave_layer 2 as its split layer)
master_layer 0: zpos = 2, layer_split enabled, normalized_zpos =
2;(use master_layer 2 as its split layer)
master_layer 1: zpos = 4, normalized_zpos = 4;
master_layer 3: zpos = 5, normalized_zpos = 5;
kcrtc_st->max_slave_zorder = 0;
When we use master_layer 3 as a input of CU in function komeda_compiz_set_input and check it with function komeda_component_check_input, the parameter idx is equal to normailzed_zpos minus max_slave_zorder, the value of idx is 5 and is euqal to CU's max_active_inputs, so that komeda_component_check_input returns a -EINVAL value.
To fix the bug described above, when calculating the max_slave_zorder with the layer_split enabled, count the split layer in this calculation directly.
Signed-off-by: hongchi.peng <hongchi.peng@siengine.com>
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index fe46b0ebefea..0554954c8cea 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -159,7 +159,7 @@ static int komeda_crtc_normalize_zpos(struct drm_crtc *crtc,
struct drm_plane_state *plane_st;
struct drm_plane *plane;
struct list_head zorder_list;
- int order = 0, err;
+ int order = 0, slave_zpos, err;
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] calculating normalized zpos values\n",
crtc->base.id, crtc->name);
@@ -200,9 +200,11 @@ static int komeda_crtc_normalize_zpos(struct drm_crtc *crtc,
/* calculate max slave zorder */
if (has_bit(drm_plane_index(plane), kcrtc->slave_planes))
+ slave_zpos = plane_st->normalized_zpos;
+ if (to_kplane_st(plane_st)->layer_split)
+ slave_zpos++;
kcrtc_st->max_slave_zorder =
- max(plane_st->normalized_zpos,
- kcrtc_st->max_slave_zorder);
+ max(slave_zpos, kcrtc_st->max_slave_zorder);
}
crtc_st->zpos_changed = true;
--
2.34.1
next prev parent reply other threads:[~2024-08-21 20:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-21 8:19 [PATCH] drm: komeda: Fix an issue related to normalized zpos hongchi.peng
2024-08-21 8:41 ` Peng Hongchi/彭洪驰 [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-08-21 8:56 hongchi.peng
2024-08-22 14:05 ` Liviu Dudau
2024-08-23 2:53 ` 回复: " Peng Hongchi/彭洪驰
2024-08-24 12:32 ` Liviu Dudau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01446fc98394446eb82a6346953f4fd0@siengine.com \
--to=hongchi.peng@siengine.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.