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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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.

-- 
Regards,

Laurent Pinchart