Hi Marek, Actually this property is specific also to DSI8x bridge, as you can see from the screenshot below taken from official datasheet:
[image: image.png] And it's the sn65dsi8x driver that tells MIPI driver which flags to use during attachment. So, for example, this bridge can work also for MIPI interfaces which don't support burst-mode. Also, as a value-added benefit, I found non-burst mode better for some 1920x1200 LVDS panels I'm testing (Of course with more energy consumption). That's why I though it could be useful have this option, since SN65DSI8x supports both modes. Stefano Il giorno mar 9 lug 2024 alle ore 16:16 Marek Vasut <[email protected]> ha scritto: > On 7/9/24 2:45 PM, Stefano Radaelli wrote: > > Hello everyone, > > Hi, > > > Thank you a lot for your prompt feedbacks. > > I'm really sorry for all the mistakes, it is the first time that I try to > > submit a patch and i thought I followed the guideline but clearly that > was > > not the case. > > > > @Marek Vasut <[email protected]> About your question to why disabling > > burst-mode: > > - I agree with you that Burst Mode is the preferred way to send data. For > > that reason I created the new flag in a way that, if not used in dts, > burst > > mode remains active by default. > > However, I decide to introduced this property because I have noticed > that > > some dual-channel panels work better in non-burst mode (even if less > > efficient), and since the sn65dsi84 datasheet allows this setting, I > > thought to give this opportunity to users. > > What do you think about it? > > Are there any further details, which panels behave this way ? Does your > DSI host generate correct HS clock, ones which the DSI84 expects to > receive on the DSI side ? > > Such link mode properties would have to be generic properties placed in > some dsi-client.yaml file in any case, such properties are not specific > to this DSI8x bridge. >
