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.barysh...@linaro.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
