Re: [PATCH v3 1/1] drm: bridge: ti-sn65dsi83: Fix DSI mode flags for stable LVDS output

[Ernest Van Hoecke]

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