Hi Laurent, 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/[email protected]/ >> >> 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? Again: AFAICU, I'm trying to understand and improve things. Cheers, Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
