Hi Luca, Hi Sudarshan, On Wed, May 20, 2026 at 01:38:36PM +0200, Luca Ceresoli wrote: > Hello, > > On Wed May 20, 2026 at 11:04 AM CEST, tessolveupstream wrote: > > [...] > > >>> We have not received any further updates from TI regarding this issue, and > >>> at this point, we are not sure if we will get additional feedback from > >>> them. > >>> As you had mentioned earlier that the patch could be considered after > >>> waiting for some time, could you please let us know how we can proceed > >>> further from here? > >> > >> I am getting some feedback from TI, but it is taking some time. > >> > >> For the time being I think it is clear that HBP and HFP are required, and > >> so removing the MIPI_DSI_MODE_VIDEO_NO_HFP and MIPI_DSI_MODE_VIDEO_NO_HBP > >> in your patch seems to be fully correct, even though this had no effect on > >> the panel I tested. > >> > >> I'm still trying to get some better info to ensure that switching from > >> burst mode to non-burst mode is not expected to have side effects. > >> > >> For thi reason, I think it would be great if you could send a new version > >> with two separate patches: the first one enabling HFP and HBP and which can > >> be applied right away, the second to disable burst mode for which I'd wait > >> a bit longer for TI feedback. You can keep the Tested-by lines. > >> > > > > Thanks for the clarification. I just wanted to confirm my understanding > > regarding the patch split you suggested. > > > > From your comments, my understanding is that the first patch would only > > enable HFP and HBP by removing MIPI_DSI_MODE_VIDEO_NO_HFP and > > MIPI_DSI_MODE_VIDEO_NO_HBP, while keeping burst mode enabled, so the mode > > flags would become: > > > > dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST | > > MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET; > > > > Then, the second patch would only disable burst mode, resulting in: > > > > dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA | > > MIPI_DSI_MODE_NO_EOT_PACKET; > > > > Could you please confirm whether my understanding is correct? > > Yes, correct. > > > Also, from our testing, when using: > > > > dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST | > > MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET; > > > > we are not able to get display output. > > This is the case for the panel I worked on as well. In the practice we both > observe that non-burst mode is what fixes the panel, but there is no clear > explanation of the reason in the docs (that's what I hope to discover from > TI). > I am testing a DSI panel on our Verdin iMX8MP module, and noticed that this caused a regression.
In v4 of this series only the change removing NO_HFP and NO_HBP was applied. [1] For us, the display worked before that change. So with MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_NO_HBP | MIPI_DSI_MODE_VIDEO_NO_HFP: things are fine. But with only MIPI_DSI_MODE_VIDEO_NO_HBP | MIPI_DSI_MODE_VIDEO_NO_HFP removed, it no longer works. I can verify that if I also remove MIPI_DSI_MODE_VIDEO_BURST, things work fine again. How can we proceed, will we be applying the removal of MIPI_DSI_MODE_VIDEO_BURST soon? I think we'll need to either revert this and later apply both together when ready, or apply the second patch now as well. Right now, it broke the DSI panel behind a TI sn65dsi83 bridge on v7.3-rc1. [1] https://lore.kernel.org/all/178164296717.254857.3522055507948798930.b4-ty@b4/ Thanks, Ernest > > On the other hand the HBP and HFP are clearly required by the docs, so it > should be fine to enable those without waiting for further info from > TI. This is not fixing your and my panel, but it's a fix, no doubt. > > > I just wanted to mention this > > observation in case it is relevant to the patch split discussion. > > > > Additionally, regarding the Tested-by tags you mentioned earlier, > > should I carry them forward to both patches, or would you prefer them > > only on the applicable patch? > > I'd say yes. People who sent these tags have tested a patch that is the sum > of the two future patches, so I'd say it's OK to keep the R-by on both > patches. > > Thanks for your patience. We'll get to the bottom of this issue! :) > > Luca > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
