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

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

Hello Francesco, Ernest,

On Fri Nov 13, 2026 at 8:36 AM CET, Francesco Dolcini wrote:
> +regression list
>
> Hello all,
>
> On Thu, Oct 29, 2026 at 04:50:39PM +0100, Ernest Van Hoecke wrote:
>> On Sat, Oct 24, 2026 at 11:54:05AM +0200, Francesco Dolcini wrote:
>> > On Wed, Sep 09, 2026 at 03:30:53PM +0200, Luca Ceresoli wrote:
>> > > On Fri Sep 4, 2026 at 2:02 PM CEST, Ernest Van Hoecke wrote:
>> > > >> > 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.
>> >
>> > [...]
>> >
>> > > > 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.
>> > >
>> > > Reverting is surely the last resort. If you can answer the above questions
>> > > it would be good, maybe we find out reverting is not necessary, and worst
>> > > case we'll revert with better understanding on what went wrong, and maybe
>> > > come up with a new fix that doesn't regress.
>> >
>> > What's the status of this regression?
>>
>> I still need to test and look into this, that will happen either in
>> December as I'm off in November, or by someone else in the team. Sorry
>> for the delay.
>
> Luca: I think we should revert this for the moment, the regression is
> real, and I do not see an immediate way forward.

I hoped to get better info from Ernest. The commit looks correct so chances
are that regression is caused but other bugs (incorrect timings, inaccurate
clocks, etc).

That said, why don't you just send a revert patch?

Don't forget to add to the commit message:

 * accurate description of what hardware breaks, with pipeline components
 * panel timings (or, better, panel datasheet URL with that info)
 * exact kernel version (upstream kernel tag or SHA-1)
 * clocks used and measured on the lines
 * difference observed before/after the patch on the cables and in software
 * any other detail of your investigation

I understand some of these info might need time to gather. But right now
every patch fixes some panels and breaks others. If we want this driver to
work with all hardware at some point we have to start doing some
investigation.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com