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/[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, 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/
