From: Mahadevan P <mahadevan.p@oss.qualcomm.com>
To: Rob Clark <robin.clark@oss.qualcomm.com>,
Dmitry Baryshkov <lumag@kernel.org>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Jessica Zhang <jesszhan0024@gmail.com>,
Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Xilin Wu <sophon@radxa.com>
Cc: linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Mahadevan P <mahadevan.p@oss.qualcomm.com>
Subject: [PATCH v4 1/6] drm/msm/dpu: split modes a single layer mixer cannot clock
Date: Thu, 08 Oct 2026 22:53:47 +0530 [thread overview]
Message-ID: <20261008-lm_fixes_final-v4-1-fa986071c3c1@oss.qualcomm.com> (raw)
In-Reply-To: <20261008-lm_fixes_final-v4-0-fa986071c3c1@oss.qualcomm.com>
The layer mixer count is picked purely from the mode width, via the
MAX_HDISPLAY_SPLIT threshold. Width is only half of what constrains a
mixer: it also processes one pixel per core clock cycle, so a mode narrow
enough to stay under the width threshold can still demand a higher pixel
rate than one mixer sustains. A 1080 wide panel at a few hundred Hz is
enough to get there.
Such a mode is currently given a single mixer and then has to be clocked
past the maximum core clock rate, which that mixer cannot do.
Factor the decision out into dpu_crtc_num_lm_for_mode() and have it ask
for a second mixer when the adjusted mode clock does not fit the maximum
core clock rate, in addition to the existing width test. Modes that
already fit within one mixer are unaffected, so the only decisions that
change are the ones that could not be driven as they were.
Assisted-by: LLM
Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 25 ++++++++++++++++++++++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 77a2d1f6700d..0b51a4c5db57 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1376,6 +1376,25 @@ static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct drm_crtc_state
#define MAX_CHANNELS_PER_CRTC PIPES_PER_PLANE
#define MAX_HDISPLAY_SPLIT 1080
+static u32 dpu_crtc_num_lm_for_mode(struct dpu_kms *dpu_kms,
+ const struct drm_display_mode *mode)
+{
+ u64 mode_clk;
+
+ if (!dpu_kms->catalog->caps->has_3d_merge)
+ return 1;
+
+ if (mode->hdisplay > MAX_HDISPLAY_SPLIT)
+ return 2;
+
+ mode_clk = dpu_core_perf_adjusted_mode_clk(mode->clock,
+ dpu_kms->perf.perf_cfg);
+ if (mode_clk * 1000 > dpu_kms->perf.max_core_clk_rate)
+ return 2;
+
+ return 1;
+}
+
static struct msm_display_topology dpu_crtc_get_topology(
struct drm_crtc *crtc,
struct dpu_kms *dpu_kms,
@@ -1409,8 +1428,8 @@ static struct msm_display_topology dpu_crtc_get_topology(
* enabled. This is because in cases where CWB is enabled, num_intf will
* count both the WB and real-time phys encoders.
*
- * For non-DSC CWB usecases, have the num_lm be decided by the
- * (mode->hdisplay > MAX_HDISPLAY_SPLIT) check.
+ * For non-DSC CWB usecases, have the num_lm be decided by
+ * dpu_crtc_num_lm_for_mode().
*/
if (topology.num_intf == 2 && !topology.cwb_enabled)
@@ -1419,7 +1438,7 @@ static struct msm_display_topology dpu_crtc_get_topology(
topology.num_lm = 2;
else if (dpu_kms->catalog->caps->has_3d_merge &&
topology.num_dsc == 0)
- topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
+ topology.num_lm = dpu_crtc_num_lm_for_mode(dpu_kms, mode);
else
topology.num_lm = 1;
--
2.34.1
next prev parent reply other threads:[~2026-10-08 17:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 17:23 [PATCH v4 0/6] drm/msm/dpu: rework layer mixer allocation and mode limits Mahadevan P
2026-10-08 17:23 ` Mahadevan P [this message]
2026-10-08 17:23 ` [PATCH v4 2/6] drm/msm/dpu: do not assume a merged datapath when validating mode clock Mahadevan P
2026-10-12 12:09 ` Dmitry Baryshkov
2026-10-12 18:13 ` Mahadevan P
2026-10-08 17:23 ` [PATCH v4 3/6] drm/msm/dpu: check mode against PINGPONG or DSC max width Mahadevan P
2026-10-12 12:14 ` Dmitry Baryshkov
2026-10-12 18:38 ` Mahadevan P
2026-10-08 17:23 ` [PATCH v4 4/6] drm/msm/dpu: filter writeback modes using writeback maxlinewidth Mahadevan P
2026-10-12 12:15 ` Dmitry Baryshkov
2026-10-08 17:23 ` [PATCH v4 5/6] drm/msm/dpu: remove max_mixer_width from catalog Mahadevan P
2026-10-08 17:23 ` [PATCH v4 6/6] drm/msm/dpu: limit the mode width to a pipe if the LM has no source split Mahadevan P
2026-10-12 12:21 ` Dmitry Baryshkov
2026-10-10 19:52 ` [PATCH v4 0/6] drm/msm/dpu: rework layer mixer allocation and mode limits Mahadevan P
2026-10-12 12:05 ` Dmitry Baryshkov
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=20261008-lm_fixes_final-v4-1-fa986071c3c1@oss.qualcomm.com \
--to=mahadevan.p@oss.qualcomm.com \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jesszhan0024@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--cc=sophon@radxa.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®