Message-ID: <jsir3n555ucylcc3m63gzrcf2arvsmsoivubsnrhzuxm3ts3qw@lyrghilffo5j>
Date: Fri, 21 Feb 2025 02:20:58 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Marijn Suijten <marijn.suijten@...ainline.org>
Cc: Jun Nie <jun.nie@...aro.org>, Rob Clark <robdclark@...il.com>, 
	Abhinav Kumar <quic_abhinavk@...cinc.com>, Jessica Zhang <quic_jesszhan@...cinc.com>, 
	Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Krishna Manikandan <quic_mkrishn@...cinc.com>, 
	linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 5/5] drm/msm/dsi: Support DSC for dual panel case

On Thu, Feb 20, 2025 at 10:50:57PM +0100, Marijn Suijten wrote:
> On 2025-02-20 18:06:01, Dmitry Baryshkov wrote:
> > On Thu, Feb 20, 2025 at 11:42:28PM +0800, Jun Nie wrote:
> > > Dmitry Baryshkov <dmitry.baryshkov@...aro.org> 于2025年2月20日周四 18:39写道：
> > > >
> > > > On Thu, Feb 20, 2025 at 06:07:56PM +0800, Jun Nie wrote:
> > > > > There is dual DSI case that every DSI link is connected to an independent
> 
> There is a dual-DSI case where every DSI link ...
> 
> > > > > panel. In this dual panel case, the frame width for DSC on each link should
> > > > > be halved to support the usage case.
> 
> use* case.  Also, it shouldn't be "halved" just... because?  It should be
> "halved" because apparently hdisplay here is the width of the two panels
> together, while the width coded in pic_width should contain that of a single
> panel (since they're independent), which is equal to the width of a single
> interface.
> 
> Tl;dr for below: this needs a *lot* more text to explain the setup and
> possibilities.  How is a DSI panel driver supposed to configure this on their
> end?  Hint: look at my previous drm/msm patches that explain how we expect to
> interface with the parameters set by the panel driver.
> 
> > > >
> > > > Isn't it the case for the DSI panel utilizing two DSI links?
> > > 
> > > The added case here is 2 DSI panel utilizing two DSI links, 1 DSI link
> > > in each panel.
> > > I assume default case is 1 panel with 2 DSI link, such as Marijn's case.
> > 
> > So it should be halved in your case, but not in Marijn's case? I can
> > suspect that if you are describing two DSI panels as a single instance,
> > you should also adjust drm_dsc_config accordingly (on the panel's side?)
> > 
> > Maybe drm_dsc_config.pic_width and drm_dsc_config.pic_height should be
> > set on the panel's side? But then, how will that function for the DSI
> > panels or bridges which can change the mode?
> 
> It appears that these patches are missing a proper description of the setup
> or use-case.  I previously NAK'd those "dual DSI" patches because of this, but
> reading between the lines I think I came to understand the reason without anyone
> else explaining it, unfortunately.  Needless to say that this needs very careful
> documentation and wording in both code (DT and/or header structs) and commit
> messages.
> 
> In my case I have a single high-resolution high-refresh-rate panel that can
> simply not be driven over a single DSI link.  A dual-DSI link is used in bonded
> mode, most likely to keep the clocks and other things in sync, and to make it
> easier to be represented by one virtual encoder in DPU?  All control commands
> only need the sent over one DSI link, not over both.
> 
> In this case pic_width is equal to the entire width of the panel, hence it is
> double the width of a single interface.
> 
> Jun seems to have a strangely different use-case for bonded-DSI / dual-DSI that
> isn't explained: two "independent" panels.  It is clear to me that pic_width
> here has to contain the width of the entire panel, and is hence equal to the
> entire width of a single interface.
> (And in the future, it seems the quad setup can drive two "bonded" panels with
>  two DSI-merge's each)
> 
> But what we're missing here is what the **advantages and limitations** are
> of this setup: why would one run two DSI links for "independent" panels in
> bonded-DSI mode?  Is it more power-optimal?  Will userspace see this as one
> panel that's simply twice as wide?  Do these panels have to be "identical"
> so that they behave and are clocked the same?  How is the driver expected to
> prepare the mode and DSC configuration parameters to make this work?

Fair enough. Maybe you will suggest how to handle it in a more efficient
way. We have been running such configurations (2 independent panels over
a bonded DSI link) in order to get a single synchronous CRTC vblank for
both panels. This is a nice hack for the software that outputs data for
both panels, but doesn't want to be concerned with separate vblanks.

> Perhaps it's possible to scrape this info from [1] and prior commits but I
> rather have a more digestible description in the commit message, thanks.
> 
> - Marijn
> 
> [1]: https://gitlab.com/jun.nie/linux/-/commit/98c0f411a85d68a76be500f8421df467d6cc53f3

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists