Re: [PATCH v4 2/2] drm: bridge: ti-sn65dsi83: Disable video burst mode for LVDS stability

[Sean Nyekjaer <sean@geanix.com>]

On Fri, Jun 05, 2026 at 08:31:56PM +0100, Laurent Pinchart wrote:
> On Fri, Jun 05, 2026 at 06:56:54PM +0200, Luca Ceresoli wrote:
> > On Fri Jun 5, 2026 at 6:09 PM CEST, Laurent Pinchart wrote:
> > > On Fri, Jun 05, 2026 at 05:18:43PM +0200, Luca Ceresoli wrote:
> > >> Hello Sean,
> > >>
> > >> +Cc Marek, Maxime.
> > >>
> > >> On Sat May 30, 2026 at 8:51 PM CEST, Sean Nyekjaer wrote:
> > >> > On Wed, May 27, 2026 at 02:27:36PM +0100, Sudarshan Shetty wrote:
> > >> >> The current DSI configuration enables MIPI_DSI_MODE_VIDEO_BURST.
> > >> >> while burst mode is supported by the hardware, its use
> > >> >> depends on continuous clock behavior from the DSI host. In practice,
> > >> >> burst mode may introduce instability depending on the host controller
> > >> >> implementation, as the DSI link may transition to low-power state
> > >> >> between bursts.
> > >> >>
> > >> >> Testing showed improved display stability when using non-burst mode on
> > >> >> affected panels.
> > >> >>
> > >> >> Remove MIPI_DSI_MODE_VIDEO_BURST and use non-burst video mode.
> > >> >
> > >> > We briefly talked about this at Embedded Recipes
> > >> > I promised to sent a link:
> > >> > https://lore.kernel.org/all/E35054BA-FBE5-4CEE-905C-1F5D20140590@geanix.com/
> > >>
> > >> Thanks for the discussion at ER and for this follow-up e-mail.
> > >>
> > >> > When burst mode is enabled, the LVDS clock gets way to high for my
> > >> > panel. I don't know if it's the DSI controller in the STM32MP1 or
> > >> > something not supported on the TI side.
> > >> >
> > >> > We have been running with this fix for 2 years :)
> > >>
> > >> If I can summarize the situation in the last 4 years:
> > >>
> > >>  * Several users reported the same trouble
> > >>  * Those users patch their kernel out of tree to disable burst mode as a
> > >>    workaround
> > >>  * According to Marek the correct way to make burst mode work is
> > >>    implementing link negotiation
> > >>  * Nobody is willing to implement link negotiation as of now
> > >>
> > >> And this leads me to some questions.
> > >>
> > >>  * Do we want to keep the current situation (everybody beats their head on
> > >>    the wall until they discover disabling burst mode "fixes" their panel,
> > >>    and keep an out of tree patch)?
> > >>
> > >>  * Assuming the priority is getting a screen working (and not saving power
> > >>    on a black screen), would it make sense to apply this patch, and let
> > >>    people improve in the future by implementing link negotiation?
> > >>
> > >>    Let's pretend for a moment this is a new driver being developed: would
> > >>    it be OK to have a basic working driver, without some power optimization
> > >>    features which can be added later on? The only valid answer to this
> > >>    question is obviously "yes". Doesn't the same principle apply here? If
> > >>    it doesn't, why?
> > >>
> > >>  * What is the expected power saving with burst mode?
> > >>
> > >>    I'm afraid I don't have precise numbers but I measured the total board
> > >>    consumption with or without burst mode (the former with a black screen
> > >>    but backlight enabled) and found no difference: exactly 12.74 W in both
> > >>    cases.
> > >>
> > >> Thanks for you rpatience in reading this. I hope it helps in finding a
> > >> better solution.
> > >
> > > Rephrasing this a bit, is the discussion about dropping support for a
> > > supported feature (burst mode) because users who suffer from the lack of
> > > another feature (link negotiation) are not willing to spend time
> > > implementing it,
> > 
> > That's the question I have, more or less. I have no answer yet, I'm mostly
> > trying to clarify the situation in the first place, for myself and anyone
> > interested.
> > 
> > Maybe it's worth pointing out that AFAICU any driver enabling burst mode is
> > buggy because in lack of link negotiation it may work or not, based on pure
> > luck.
> > 
> > > and would prefer if users of burst mode were forced to
> > > do the work instead ? That doesn't seem very fair to me.
> > 
> > Link negotiation is not just "another feature" w.r.t. burts mode. It's a
> > prerequisite for burst mode to work reliably. So hard-enabling burst mode
> > was building a roof without solid walls (link negotiation).
> > 
> > So I'm rephrasing your the question :) as: shouldn't users of burst mode be
> > forced to implement link negotiation, since _they_ need it?
> 
> It's quite annoying when both positions have compelling arguments :-)
> 
> Has anyone analyzed what work would be needed to implement the link
> negotiation ? Dropping burst mode without any plan to support it will be
> demotivating for some people. If asking for link negotiation support to
> support non-burst mode is too much yak shaving, would researching a
> technical plan be an acceptable middleground ?
> 
> > Again: AFAICU, I'm trying to understand and improve things.

I'm by no means an expert on this.

As far as I know, burst mode is a power-saving feature. I haven't heard
of burst mode being used specifically for LVDS.

Since this is a DSI-to-LVDS converter, it looks like the bridge doesn't
support burst mode properly, it shouldn't increase the LVDS clock by 20%.

I'm in favor of disabling this "optional" feature, to enable more
display's to work out of the box.

/Sean