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

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

[Sudarshan Shetty]

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.

Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
---
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index c03ff1ea9df8..6b5a6019c30d 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -976,8 +976,8 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
 
 	dsi->lanes = dsi_lanes;
 	dsi->format = MIPI_DSI_FMT_RGB888;
-	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
-			  MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
+	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA |
+			  MIPI_DSI_MODE_NO_EOT_PACKET;
 
 	ret = devm_mipi_dsi_attach(dev, dsi);
 	if (ret < 0) {
-- 
2.34.1

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

[Sean Nyekjaer]

Hi Luca,

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/

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 :)

> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>

Tested-by: Sean Nyekjaer <sean@geanix.com>

> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index c03ff1ea9df8..6b5a6019c30d 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -976,8 +976,8 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
>  
>  	dsi->lanes = dsi_lanes;
>  	dsi->format = MIPI_DSI_FMT_RGB888;
> -	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
> -			  MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
> +	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA |
> +			  MIPI_DSI_MODE_NO_EOT_PACKET;
>  
>  	ret = devm_mipi_dsi_attach(dev, dsi);
>  	if (ret < 0) {
> -- 
> 2.34.1
> 

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

[Luca Ceresoli]

Hello Sean,

+Cc Marek, Maxime.

On Sat May 30, 2026 at 8:51 PM CEST, Sean Nyekjaer wrote:
> Hi Luca,
>
> 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.

Best regards,
Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[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.

-- 
Regards,

Laurent Pinchart

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

[Luca Ceresoli]

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/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?

Again: AFAICU, I'm trying to understand and improve things.

Cheers,
Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

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

[Sean Nyekjaer]

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

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

[Alexander Stein]

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/

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3861 bytes --]

On Fri, Jun 05, 2026 at 07:09:46PM +0300, Laurent Pinchart wrote:
> On Fri, Jun 05, 2026 at 05:18:43PM +0200, Luca Ceresoli wrote:
> > Hello Sean,
> > 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.

Yeah, that's my take on it too. The question quickly turns into "we want
to regress current users because some new ones don't want to bother",
and, honestly, no. We don't do that.

I really don't buy into the "but it's too hard!" argument, because you
can apply for pretty much everything: a review, a requested preliminary
work, etc.

If downstream users want to patch out the kernel and prefer to take on
technical debt, that's on them.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]

On Fri, Jun 05, 2026 at 06:56:54PM +0200, Luca Ceresoli wrote:
> 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/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?
> 
> Again: AFAICU, I'm trying to understand and improve things.

It doesn't matter though? Take the perspective of a user. You have a
system running somewhere, working, and with an expected power draw. You
update, and now it either doesn't work anymore, or you overshoot your
power budget. But they shouldn't worry, because it was working by luck
before! And now it's better!

It's an absurd argumentation. A system that used to work wouldn't
anymore. It's a regression, and we don't do that (willingly).

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Laurent Pinchart]

On Mon, Jun 08, 2026 at 09:09:18AM +0200, Maxime Ripard wrote:
> On Fri, Jun 05, 2026 at 07:09:46PM +0300, Laurent Pinchart wrote:
> > On Fri, Jun 05, 2026 at 05:18:43PM +0200, Luca Ceresoli wrote:
> > > Hello Sean,
> > > 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.
> 
> Yeah, that's my take on it too. The question quickly turns into "we want
> to regress current users because some new ones don't want to bother",
> and, honestly, no. We don't do that.
> 
> I really don't buy into the "but it's too hard!" argument, because you
> can apply for pretty much everything: a review, a requested preliminary
> work, etc.

Without going that far, I think we need a good technical analysis and
development plan first to back the "it's too hard" argument. If the
amount of work indeed turns to be huge, we can then try to figure out
how to split the effort.

> If downstream users want to patch out the kernel and prefer to take on
> technical debt, that's on them.

-- 
Regards,

Laurent Pinchart

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4717 bytes --]

On Mon, Jun 08, 2026 at 10:14:36AM +0300, Laurent Pinchart wrote:
> On Mon, Jun 08, 2026 at 09:09:18AM +0200, Maxime Ripard wrote:
> > On Fri, Jun 05, 2026 at 07:09:46PM +0300, Laurent Pinchart wrote:
> > > On Fri, Jun 05, 2026 at 05:18:43PM +0200, Luca Ceresoli wrote:
> > > > Hello Sean,
> > > > 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.
> > 
> > Yeah, that's my take on it too. The question quickly turns into "we want
> > to regress current users because some new ones don't want to bother",
> > and, honestly, no. We don't do that.
> > 
> > I really don't buy into the "but it's too hard!" argument, because you
> > can apply for pretty much everything: a review, a requested preliminary
> > work, etc.
> 
> Without going that far, I think we need a good technical analysis and
> development plan first to back the "it's too hard" argument. If the
> amount of work indeed turns to be huge, we can then try to figure out
> how to split the effort.

Either way, we won't regress existing users. If it's indeed pretty
involved (but I'm not sure why it would be more involved than, say,
formats), then I guess we can discuss mitigating the issue, but we're
still not going to create a regression even if it's hard.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]