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? 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
