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

[Alexander Stein <alexander.stein@ew.tq-group.com>]

Hi,

Am Freitag, 5. Juni 2026, 18:09:46 CEST schrieb Laurent Pinchart:
> 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, and would prefer if users of burst mode were forced to
> do the work instead ? That doesn't seem very fair to me.

I've never heard of link negotiation for DSI. What is this about? Can you
elaborate a bit?

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/