public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Alexander Koskovich <akoskovich@pm.me>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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 06:50:16 +0000	[thread overview]
Message-ID: <jv_kU6i1uCSu--2-KIWkgsC0NsVK1yE396Nv_fCFA5v9uR-zrMGhrBmKNnG_ztHPiKPqlcjWif3R-XF1bINB387ezJEKtXDY453253BM6fc=@pm.me> (raw)
In-Reply-To: <a7jukaag6juswudeeuskgzahzbixxn5oq4qjnxfny2oapinfnv@kmn7b33yxric>

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

> 
> >
> > This also works on my panel.
> >
> > Should I send this in a v4 for this series or just leave it for a seperate
> > change as panel seems to work with /24 here anyways?
> >
> > > (note: newer downstream looks like it would divide
> > > by 3.75 here, which doesn't make sense. older downstream would divide by
> > > 3 here. I guess downstream is broken now and video mode + 10-bit dsc
> > > doesn't get tested?)
> > >
> > > on DSI side, "uncompressed pixel depth" shouldn't matter either: DSI
> > > only sees the compressed data. But based on that comment, when widebus
> > > is enabled, by setting DSI_VID_CFG0_DST_FORMAT(?) to 30bpp, then the DSI
> > > pclk is in 30-bit units instead of 24-bits. And with this series DSI
> > > side ends up with the right result if 30bpp format and widebus is enabled.
> > >
> > >
> >
> > Thanks,
> > Alex
> 
> --
> With best wishes
> Dmitry
>

  reply	other threads:[~2026-03-20  6:50 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 [this message]
2026-03-20  7:02                     ` Alexander Koskovich
2026-03-20  7:36                       ` Dmitry Baryshkov
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='jv_kU6i1uCSu--2-KIWkgsC0NsVK1yE396Nv_fCFA5v9uR-zrMGhrBmKNnG_ztHPiKPqlcjWif3R-XF1bINB387ezJEKtXDY453253BM6fc=@pm.me' \
    --to=akoskovich@pm.me \
    --cc=abhinav.kumar@linux.dev \
    --cc=airlied@gmail.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --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