From: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
To: Alexander Koskovich <akoskovich@pm.me>
Cc: Jonathan Marek <jonathan@marek.ca>,
Neil Armstrong <neil.armstrong@linaro.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
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>,
Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org
Subject: Re: [PATCH v3 4/4] drm/msm/dpu: fix video mode DSC INTF timing width calculation
Date: Fri, 20 Mar 2026 09:36:41 +0200 [thread overview]
Message-ID: <7o6ddv23aft3eerc7xz7r5rawe24d6vl3qp33ewnqllv5xkfrf@n3dosrwbvlhf> (raw)
In-Reply-To: <nVcYZQOh7dB65LsiaXejmQP-Cmp-eSxp7fvDiTwS2P5WJc03m4CwXtUP_2w-D2dflxo9rwKPI68FxnfswATouZxK8QhF256JJf3F7BkbmY0=@pm.me>
On Fri, Mar 20, 2026 at 07:02:54AM +0000, Alexander Koskovich wrote:
> On Friday, March 20th, 2026 at 2:50 AM, Alexander Koskovich <akoskovich@pm.me> wrote:
>
> > On Friday, March 20th, 2026 at 2:38 AM, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > > On Fri, Mar 20, 2026 at 04:46:02AM +0000, Alexander Koskovich wrote:
> > > > On Friday, March 20th, 2026 at 12:25 AM, Jonathan Marek <jonathan@marek.ca> wrote:
> > > >
> > > > > On 3/19/26 9:45 PM, Dmitry Baryshkov wrote:
> > > > > > On Thu, Mar 19, 2026 at 01:23:03PM -0400, Jonathan Marek wrote:
> > > > > ...
> > > > > >>
> > > > > >> That's not how it works. INTF (which feeds DSI) is after DSC compression.
> > > > > >>
> > > > > >> INTF timings are always in RGB888 (24-bit) units. Ignoring widebus details,
> > > > > >> the INTF timing should match what is programmed on the DSI side (hdisplay,
> > > > > >> which is calculated as bytes per line / 3).
> > > > > >>
> > > > > >> (fwiw, the current "timing->width = ..." calculation here blames to me, but
> > > > > >> what I wrote originally was just "timing->width = timing->width / 3" with a
> > > > > >> comment about being incomplete.)
> > > > > >>
> > > > > > Okay. After reading the docs (sorry, it took a while).
> > > > > >
> > > > > > - When widebus is not enabled, the transfer is always 24 bit of
> > > > > > compressed data. Thus if it is not in play, pclk and timing->width
> > > > > > should be scaled by source_pixel_depth / compression_ratio / 24. In
> > > > > > case of the code it is 'drm_dsc_get_bpp_int(dsc) / 24'.
> > > > > >
> > > > > > For RGB101010 / 8bpp DSC this should result in the PCLK being lowered
> > > > > > by the factor of 3 (= 24 / (30 / 3.75))
> > > > > >
> > > > > > - When widebus is in play (MDSS 6.x+, DSI 2.4+), the transfer takes
> > > > > > more than 24 bits. In this case the PCLK and timing->width should be
> > > > > > scaled exactly by the DSC compression ratio, which is
> > > > > > 'drm_dsc_get_bpp_int(dsc) / (3 * dsc->bits_per_component).
> > > > > >
> > > > > > So, this piece of code needs to be adjusted to check for the widebus
> > > > > > being enabled or not.
> > > > > >
> > > > >
> > > > > The widebus adjustment on the MDP/INTF side is already in
> > > > > dpu_hw_intf_setup_timing_engine: the "data width" is divided by 2 for
> > > > > 48-bit widebus instead of 24-bit. there shouldn't be any other
> > > > > adjustment (downstream doesn't have any other adjustment).
> > > > >
> > > > > a relevant downstream comment: "In DATABUS-WIDEN mode, MDP always sends
> > > > > out 48-bit compressed data per pclk and on average, DSI consumes an
> > > > > amount of compressed data equivalent to the uncompressed pixel depth per
> > > > > pclk."
> > > > >
> > > > > Based on that comment, this patch is correct, and the
> > > > > ''drm_dsc_get_bpp_int(dsc) / (3 * dsc->bits_per_component)' adjustment
> > > > > only applies to DSI.
> > > >
> > > > If I keep the INTF side at /24 and change the DSI side to:
> > > >
> > > > if (wide_bus)
> > > > new_hdisplay = DIV_ROUND_UP(mode->hdisplay * drm_dsc_get_bpp_int(dsc), dsc->bits_per_component * 3);
> > > > else
> > > > new_hdisplay = DIV_ROUND_UP(mode->hdisplay * drm_dsc_get_bpp_int(dsc), 24);
> > >
> > > Please check the actual fps (I'm usually using a vblank-synced GL, e.g.
> > > kmscube).
> > >
> > > At least this matches my expectations.
> >
> > Hmmm with kmscube I am getting 120FPS with 24 and 100FPS with 30. So I guess that's a no go
>
> Although it was using dsc->bits_per_component * 3 regardless before for
> dsi_adjust_pclk_for_compression so I guess that's what Jonathan was
> referring to earlier...
Do you have any of the patches by Marijn or Pengyu?
- https://lore.kernel.org/linux-arm-msm/20260311-dsi-dsc-regresses-again-v1-1-6a422141eeea@somainline.org/
- https://lore.kernel.org/linux-arm-msm/20260307111250.105772-1-mitltlatltl@gmail.com/
--
With best wishes
Dmitry
next prev parent reply other threads:[~2026-03-20 7:36 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 11:57 [PATCH v3 0/4] drm/msm: add RGB101010 pixel format and fix 10-bit DSC timing Alexander Koskovich
2026-03-19 11:57 ` [PATCH v3 1/4] drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0 Alexander Koskovich
2026-03-19 12:05 ` Konrad Dybcio
2026-03-19 18:50 ` Dmitry Baryshkov
2026-03-21 18:21 ` Claude review: " Claude Code Review Bot
2026-03-19 11:57 ` [PATCH v3 2/4] drm/msm/dsi: add DSI version >= comparison helper Alexander Koskovich
2026-03-19 12:08 ` Konrad Dybcio
2026-03-19 18:50 ` Dmitry Baryshkov
2026-03-19 18:54 ` Dmitry Baryshkov
2026-03-21 18:21 ` Claude review: " Claude Code Review Bot
2026-03-19 11:57 ` [PATCH v3 3/4] drm/msm/dsi: Add support for RGB101010 pixel format Alexander Koskovich
2026-03-19 12:12 ` Konrad Dybcio
2026-03-19 18:59 ` Dmitry Baryshkov
2026-03-19 19:03 ` Alexander Koskovich
2026-03-20 9:22 ` kernel test robot
2026-03-20 17:58 ` kernel test robot
2026-03-21 18:21 ` Claude review: " Claude Code Review Bot
2026-03-19 11:58 ` [PATCH v3 4/4] drm/msm/dpu: fix video mode DSC INTF timing width calculation Alexander Koskovich
2026-03-19 14:09 ` Neil Armstrong
2026-03-19 14:40 ` Alexander Koskovich
2026-03-19 14:54 ` Neil Armstrong
2026-03-19 17:23 ` Jonathan Marek
2026-03-19 17:31 ` Alexander Koskovich
2026-03-19 19:02 ` Jonathan Marek
2026-03-20 1:45 ` Dmitry Baryshkov
2026-03-20 3:55 ` Alexander Koskovich
2026-03-20 4:25 ` Jonathan Marek
2026-03-20 4:46 ` Alexander Koskovich
2026-03-20 6:38 ` Dmitry Baryshkov
2026-03-20 6:50 ` Alexander Koskovich
2026-03-20 7:02 ` Alexander Koskovich
2026-03-20 7:36 ` Dmitry Baryshkov [this message]
2026-03-20 7:47 ` Alexander Koskovich
2026-03-20 8:17 ` Alexander Koskovich
2026-03-20 7:02 ` Dmitry Baryshkov
2026-03-20 7:34 ` Dmitry Baryshkov
2026-03-19 19:05 ` Dmitry Baryshkov
2026-03-21 18:21 ` Claude review: " Claude Code Review Bot
2026-03-21 18:21 ` Claude review: drm/msm: add RGB101010 pixel format and fix 10-bit DSC timing Claude Code Review Bot
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=7o6ddv23aft3eerc7xz7r5rawe24d6vl3qp33ewnqllv5xkfrf@n3dosrwbvlhf \
--to=dmitry.baryshkov@oss.qualcomm.com \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=akoskovich@pm.me \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jeffrey.l.hugo@gmail.com \
--cc=jesszhan0024@gmail.com \
--cc=jonathan@marek.ca \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox