Some LVDS panels operating in dual-link mode require adjusted
horizontal timing parameters when programmed into the SN65DSI84
bridge. According to TI documentation, horizontal timing values
must be divided by two when operating in dual-link mode. Without
this adjustment, the panel may fail to display or produce corrupted
output.
Add support for an optional DT property "ti,dual-link-video-mode"
to enable configuration required for dual-link LVDS operation.
These settings ensure correct LVDS output for panels that require
this mode of operation.
Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 52 ++++++++++++++++++++++++---
1 file changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index f6736b4457bb..9b7d35487bd8 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -164,6 +164,7 @@ struct sn65dsi83 {
int irq;
struct delayed_work monitor_work;
struct work_struct reset_work;
+ bool dual_link_video_mode;
};
static const struct regmap_range sn65dsi83_readable_ranges[] = {
@@ -667,8 +668,43 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
mode->hsync_start - mode->hdisplay);
regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,
mode->vsync_start - mode->vdisplay);
- regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
+ /*
+ * In dual-link LVDS mode, the SN65DSI84 requires the horizontal
+ * timing parameters to be adjusted before being programmed into
+ * the device. According to TI documentation, the horizontal timing
+ * values must be divided by two when operating in dual-link mode.
+ * Without this adjustment, the connected panel may fail to light up
+ * or display corrupted output.
+ *
+ * TI also provides recommended register settings for this mode,
+ * which were derived using the TI DSI-Tuner tool. When the optional
+ * DT property "ti,dual-link-video-mode" is present, apply these
+ * configuration settings to ensure correct dual-link LVDS operation.
+ */
+ if (ctx->dual_link_video_mode) {
+ regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
+ regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
+ regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
+ regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
+ regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
+ regmap_write(ctx->regmap,
+ REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
+ regmap_write(ctx->regmap,
+ REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
+ regmap_write(ctx->regmap,
+ REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
+ regmap_write(ctx->regmap,
+ REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
+ regmap_write(ctx->regmap,
+ REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
+ regmap_write(ctx->regmap,
+ REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
+ regmap_write(ctx->regmap,
+ REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
+ }
+
+ regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
/* Enable PLL */
regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
usleep_range(3000, 4000);
@@ -965,9 +1001,15 @@ 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_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
- MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
+ if (ctx->dual_link_video_mode)
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
+ else
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
+ MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_VIDEO_NO_HFP |
+ MIPI_DSI_MODE_VIDEO_NO_HBP |
+ MIPI_DSI_MODE_VIDEO_NO_HSA |
+ MIPI_DSI_MODE_NO_EOT_PACKET;
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
@@ -1021,6 +1063,8 @@ static int sn65dsi83_probe(struct i2c_client *client)
if (ret)
return ret;
+ ctx->dual_link_video_mode =
+ of_property_read_bool(dev->of_node, "ti,dual-link-video-mode");
ctx->regmap = devm_regmap_init_i2c(client, &sn65dsi83_regmap_config);
if (IS_ERR(ctx->regmap))
return dev_err_probe(dev, PTR_ERR(ctx->regmap), "failed to get regmap\n");
--
2.34.1Hello Sudarshan,
On Thu Mar 12, 2026 at 5:37 AM CET, Sudarshan Shetty wrote:
> Some LVDS panels operating in dual-link mode require adjusted
> horizontal timing parameters when programmed into the SN65DSI84
> bridge. According to TI documentation, horizontal timing values
> must be divided by two when operating in dual-link mode. Without
> this adjustment, the panel may fail to display or produce corrupted
> output.
>
> Add support for an optional DT property "ti,dual-link-video-mode"
> to enable configuration required for dual-link LVDS operation.
> These settings ensure correct LVDS output for panels that require
> this mode of operation.
>
> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 52 ++++++++++++++++++++++++---
> 1 file changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index f6736b4457bb..9b7d35487bd8 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -164,6 +164,7 @@ struct sn65dsi83 {
> int irq;
> struct delayed_work monitor_work;
> struct work_struct reset_work;
> + bool dual_link_video_mode;
As said in the reply to patch 1, there is already 'bool lvds_dual_link'
carrying the same info.
> static const struct regmap_range sn65dsi83_readable_ranges[] = {
> @@ -667,8 +668,43 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
> mode->hsync_start - mode->hdisplay);
> regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,
> mode->vsync_start - mode->vdisplay);
> - regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
>
> + /*
> + * In dual-link LVDS mode, the SN65DSI84 requires the horizontal
> + * timing parameters to be adjusted before being programmed into
> + * the device. According to TI documentation, the horizontal timing
> + * values must be divided by two when operating in dual-link mode.
> + * Without this adjustment, the connected panel may fail to light up
> + * or display corrupted output.
> + *
> + * TI also provides recommended register settings for this mode,
> + * which were derived using the TI DSI-Tuner tool. When the optional
> + * DT property "ti,dual-link-video-mode" is present, apply these
> + * configuration settings to ensure correct dual-link LVDS operation.
> + */
> + if (ctx->dual_link_video_mode) {
> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> + regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
> + regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
> + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
> + regmap_write(ctx->regmap,
> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
> + regmap_write(ctx->regmap,
> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
> + regmap_write(ctx->regmap,
> + REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
> + regmap_write(ctx->regmap,
> + REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
> + regmap_write(ctx->regmap,
> + REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
> + regmap_write(ctx->regmap,
> + REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
> + regmap_write(ctx->regmap,
> + REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
> + }
I guess these hard-coded values are sepcific to your panel. They must
instead be computed based on the timings in order to work for every panel.
> +
> + regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
> /* Enable PLL */
> regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
> usleep_range(3000, 4000);
> @@ -965,9 +1001,15 @@ 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_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
> - MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
> + if (ctx->dual_link_video_mode)
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
> + else
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> + MIPI_DSI_MODE_VIDEO_BURST |
> + MIPI_DSI_MODE_VIDEO_NO_HFP |
> + MIPI_DSI_MODE_VIDEO_NO_HBP |
> + MIPI_DSI_MODE_VIDEO_NO_HSA |
> + MIPI_DSI_MODE_NO_EOT_PACKET;
There is no explanation about this, can you elaborate on why?
I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84,
and the removing MIPI_DSI_MODE_VIDEO_BURST seems to help, but I still have
no idea why. Should you have any info, maybe from TI, it would be very
interesting.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 12-03-2026 21:17, Luca Ceresoli wrote:
> Hello Sudarshan,
>
> On Thu Mar 12, 2026 at 5:37 AM CET, Sudarshan Shetty wrote:
>> Some LVDS panels operating in dual-link mode require adjusted
>> horizontal timing parameters when programmed into the SN65DSI84
>> bridge. According to TI documentation, horizontal timing values
>> must be divided by two when operating in dual-link mode. Without
>> this adjustment, the panel may fail to display or produce corrupted
>> output.
>>
>> Add support for an optional DT property "ti,dual-link-video-mode"
>> to enable configuration required for dual-link LVDS operation.
>> These settings ensure correct LVDS output for panels that require
>> this mode of operation.
>>
>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
>> ---
>> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 52 ++++++++++++++++++++++++---
>> 1 file changed, 48 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> index f6736b4457bb..9b7d35487bd8 100644
>> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> @@ -164,6 +164,7 @@ struct sn65dsi83 {
>> int irq;
>> struct delayed_work monitor_work;
>> struct work_struct reset_work;
>> + bool dual_link_video_mode;
>
> As said in the reply to patch 1, there is already 'bool lvds_dual_link'
> carrying the same info.
>
okay.
>> static const struct regmap_range sn65dsi83_readable_ranges[] = {
>> @@ -667,8 +668,43 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
>> mode->hsync_start - mode->hdisplay);
>> regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,
>> mode->vsync_start - mode->vdisplay);
>> - regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
>>
>> + /*
>> + * In dual-link LVDS mode, the SN65DSI84 requires the horizontal
>> + * timing parameters to be adjusted before being programmed into
>> + * the device. According to TI documentation, the horizontal timing
>> + * values must be divided by two when operating in dual-link mode.
>> + * Without this adjustment, the connected panel may fail to light up
>> + * or display corrupted output.
>> + *
>> + * TI also provides recommended register settings for this mode,
>> + * which were derived using the TI DSI-Tuner tool. When the optional
>> + * DT property "ti,dual-link-video-mode" is present, apply these
>> + * configuration settings to ensure correct dual-link LVDS operation.
>> + */
>> + if (ctx->dual_link_video_mode) {
>> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
>> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>> + regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
>> + regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
>> + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
>> + regmap_write(ctx->regmap,
>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
>> + regmap_write(ctx->regmap,
>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
>> + regmap_write(ctx->regmap,
>> + REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
>> + regmap_write(ctx->regmap,
>> + REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
>> + regmap_write(ctx->regmap,
>> + REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
>> + regmap_write(ctx->regmap,
>> + REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
>> + regmap_write(ctx->regmap,
>> + REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
>> + }
>
> I guess these hard-coded values are sepcific to your panel. They must
> instead be computed based on the timings in order to work for every panel.
>
The hard-coded values were initially derived from the TI DSI Tuner output
during our bring-up testing. TI had also mentioned that when PATGEN is
enabled with dual-LVDS output on the SN65DSI84, the horizontal timings
must be divided by 2. They also noted that the current driver does not
appear to divide the horizontal timings when PATGEN is enabled in
dual-LVDS mode.
Based on that suggestion, we had tried adjusting the horizontal timing
registers accordingly to match the tuner output.
Could you please advise how these register values are expected to be
derived from the mode timings so that they work correctly for different
panels?
>> +
>> + regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
>> /* Enable PLL */
>> regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
>> usleep_range(3000, 4000);
>> @@ -965,9 +1001,15 @@ 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_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
>> - MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>> + if (ctx->dual_link_video_mode)
>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
>> + else
>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>> + MIPI_DSI_MODE_VIDEO_BURST |
>> + MIPI_DSI_MODE_VIDEO_NO_HFP |
>> + MIPI_DSI_MODE_VIDEO_NO_HBP |
>> + MIPI_DSI_MODE_VIDEO_NO_HSA |
>> + MIPI_DSI_MODE_NO_EOT_PACKET;
>
> There is no explanation about this, can you elaborate on why?
>
> I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84,
> and the removing MIPI_DSI_MODE_VIDEO_BURST seems to help, but I still have
> no idea why. Should you have any info, maybe from TI, it would be very
> interesting.
>
During our earlier bring-up, TI mentioned that one possible reason for the DSI
REFCLK not behaving as expected could be that the DSI output is configured in
burst mode instead of non-burst mode. In burst mode the DSI clock may not be
continuous, whereas non-burst mode provides a more predictable DSI clock.
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Hello Sudarshan,
On Wed Mar 18, 2026 at 6:53 AM CET, tessolveupstream wrote:
>>> + if (ctx->dual_link_video_mode) {
>>> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
>>> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>> + regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
>>> + regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
>>> + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
>>> + regmap_write(ctx->regmap,
>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
>>> + regmap_write(ctx->regmap,
>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
>>> + regmap_write(ctx->regmap,
>>> + REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
>>> + regmap_write(ctx->regmap,
>>> + REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
>>> + regmap_write(ctx->regmap,
>>> + REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
>>> + regmap_write(ctx->regmap,
>>> + REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
>>> + regmap_write(ctx->regmap,
>>> + REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
>>> + }
>>
>> I guess these hard-coded values are sepcific to your panel. They must
>> instead be computed based on the timings in order to work for every panel.
>>
>
> The hard-coded values were initially derived from the TI DSI Tuner output
> during our bring-up testing. TI had also mentioned that when PATGEN is
> enabled with dual-LVDS output on the SN65DSI84, the horizontal timings
> must be divided by 2. They also noted that the current driver does not
> appear to divide the horizontal timings when PATGEN is enabled in
> dual-LVDS mode.
>
> Based on that suggestion, we had tried adjusting the horizontal timing
> registers accordingly to match the tuner output.
> Could you please advise how these register values are expected to be
> derived from the mode timings so that they work correctly for different
> panels?
Well, the principle is quite simple:
1. the panel docs tell you which timings the panel needs, e.g. HBP must be
10 clock cycles
2. your panel description in dts or implementation in a panel driver will
then be written accordingly
3. the ti-sn65dsi83 driver will receive a struct drm_display_mode* with
these values
4. based on those values it sets the registers so the SN65DSI84 uses the
timings required by the panel (with a bit of math if needed):
regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
mode->htotal - mode->hsync_end);
Same for all other timings.
Ti is more complicated if more cases need to be handled, such as dual-LVDS,
and the chip documentation is vague about what must be done in those cases.
I suggested next steps to move forward in reply to the cover letter.
>>> @@ -965,9 +1001,15 @@ 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_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
>>> - MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>>> + if (ctx->dual_link_video_mode)
>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
>>> + else
>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>> + MIPI_DSI_MODE_VIDEO_BURST |
>>> + MIPI_DSI_MODE_VIDEO_NO_HFP |
>>> + MIPI_DSI_MODE_VIDEO_NO_HBP |
>>> + MIPI_DSI_MODE_VIDEO_NO_HSA |
>>> + MIPI_DSI_MODE_NO_EOT_PACKET;
>>
>> There is no explanation about this, can you elaborate on why?
>>
>> I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84,
>> and the removing MIPI_DSI_MODE_VIDEO_BURST seems to help, but I still have
>> no idea why. Should you have any info, maybe from TI, it would be very
>> interesting.
>>
>
> During our earlier bring-up, TI mentioned that one possible reason for the DSI
> REFCLK not behaving as expected could be that the DSI output is configured in
> burst mode instead of non-burst mode. In burst mode the DSI clock may not be
> continuous, whereas non-burst mode provides a more predictable DSI clock.
Uhm, this is a bit vague. They basically said "burst can be more
problematic than continuous", which is obvious, and "try disabling burst
and see whether it helps" with no explanation on why one works and not the
other. Shoudl you have more info from them you'd be welcome to share it. In
particular, is disabling burst mode specifically related to dual-LVDS, or
just a way to (try to) get rid of some problems without a clear
understanding?
On my side I also have a dual-LVDS panel connected to a SN65DSI84, which
works only by disabling burst mode. I haven't tried upstreaming it because
I don't have an explanation of why it fixes the panel and so I have no idea
how to teach the driver when it should disable burst mode.
Additionally inyour patch you remove many other flags. Any explanation from
those?
Best regards,
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 18-03-2026 14:22, Luca Ceresoli wrote:
> Hello Sudarshan,
>
> On Wed Mar 18, 2026 at 6:53 AM CET, tessolveupstream wrote:
>>>> + if (ctx->dual_link_video_mode) {
>>>> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
>>>> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>> + regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
>>>> + regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
>>>> + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
>>>> + }
>>>
>>> I guess these hard-coded values are sepcific to your panel. They must
>>> instead be computed based on the timings in order to work for every panel.
>>>
>>
>> The hard-coded values were initially derived from the TI DSI Tuner output
>> during our bring-up testing. TI had also mentioned that when PATGEN is
>> enabled with dual-LVDS output on the SN65DSI84, the horizontal timings
>> must be divided by 2. They also noted that the current driver does not
>> appear to divide the horizontal timings when PATGEN is enabled in
>> dual-LVDS mode.
>>
>> Based on that suggestion, we had tried adjusting the horizontal timing
>> registers accordingly to match the tuner output.
>> Could you please advise how these register values are expected to be
>> derived from the mode timings so that they work correctly for different
>> panels?
>
> Well, the principle is quite simple:
>
> 1. the panel docs tell you which timings the panel needs, e.g. HBP must be
> 10 clock cycles
>
> 2. your panel description in dts or implementation in a panel driver will
> then be written accordingly
>
> 3. the ti-sn65dsi83 driver will receive a struct drm_display_mode* with
> these values
>
> 4. based on those values it sets the registers so the SN65DSI84 uses the
> timings required by the panel (with a bit of math if needed):
>
> regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> mode->htotal - mode->hsync_end);
>
> Same for all other timings.
>
> Ti is more complicated if more cases need to be handled, such as dual-LVDS,
> and the chip documentation is vague about what must be done in those cases.
>
> I suggested next steps to move forward in reply to the cover letter.
>
Thank you so much for your suggestion.
>>>> @@ -965,9 +1001,15 @@ 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_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>> - MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>>>> + if (ctx->dual_link_video_mode)
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
>>>> + else
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>>> + MIPI_DSI_MODE_VIDEO_BURST |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HFP |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HSA |
>>>> + MIPI_DSI_MODE_NO_EOT_PACKET;
>>>
>>> There is no explanation about this, can you elaborate on why?
>>>
>>> I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84,
>>> and the removing MIPI_DSI_MODE_VIDEO_BURST seems to help, but I still have
>>> no idea why. Should you have any info, maybe from TI, it would be very
>>> interesting.
>>>
>>
>> During our earlier bring-up, TI mentioned that one possible reason for the DSI
>> REFCLK not behaving as expected could be that the DSI output is configured in
>> burst mode instead of non-burst mode. In burst mode the DSI clock may not be
>> continuous, whereas non-burst mode provides a more predictable DSI clock.
>
> Uhm, this is a bit vague. They basically said "burst can be more
> problematic than continuous", which is obvious, and "try disabling burst
> and see whether it helps" with no explanation on why one works and not the
> other. Shoudl you have more info from them you'd be welcome to share it. In
> particular, is disabling burst mode specifically related to dual-LVDS, or
> just a way to (try to) get rid of some problems without a clear
> understanding?
>
> On my side I also have a dual-LVDS panel connected to a SN65DSI84, which
> works only by disabling burst mode. I haven't tried upstreaming it because
> I don't have an explanation of why it fixes the panel and so I have no idea
> how to teach the driver when it should disable burst mode.
>
> Additionally inyour patch you remove many other flags. Any explanation from
> those?
>
Thanks for your inputs.
I wanted to share a quick observation from our side. With your suggested 3
patches (links below), the panel started working after simplifying the
dsi-> mode_flags:
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-1-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/lkml/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-1-e6aaa7e1d181@bootlin.com/
Earlier configuration:
MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
Working configuration:
MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA |
MIPI_DSI_MODE_NO_EOT_PACKET;
From our testing, removing MIPI_DSI_MODE_VIDEO_BURST along with the NO_HFP/NO_HBP
flags results in stable LVDS output in dual-link mode.
Could you please suggest how you would prefer to handle this change for
upstreaming?
> Best regards,
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
On 18-03-2026 14:22, Luca Ceresoli wrote:
> Hello Sudarshan,
>
> On Wed Mar 18, 2026 at 6:53 AM CET, tessolveupstream wrote:
>>>> + if (ctx->dual_link_video_mode) {
>>>> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
>>>> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>> + regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
>>>> + regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
>>>> + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
>>>> + }
>>>
>>> I guess these hard-coded values are sepcific to your panel. They must
>>> instead be computed based on the timings in order to work for every panel.
>>>
>>
>> The hard-coded values were initially derived from the TI DSI Tuner output
>> during our bring-up testing. TI had also mentioned that when PATGEN is
>> enabled with dual-LVDS output on the SN65DSI84, the horizontal timings
>> must be divided by 2. They also noted that the current driver does not
>> appear to divide the horizontal timings when PATGEN is enabled in
>> dual-LVDS mode.
>>
>> Based on that suggestion, we had tried adjusting the horizontal timing
>> registers accordingly to match the tuner output.
>> Could you please advise how these register values are expected to be
>> derived from the mode timings so that they work correctly for different
>> panels?
>
> Well, the principle is quite simple:
>
> 1. the panel docs tell you which timings the panel needs, e.g. HBP must be
> 10 clock cycles
>
> 2. your panel description in dts or implementation in a panel driver will
> then be written accordingly
>
> 3. the ti-sn65dsi83 driver will receive a struct drm_display_mode* with
> these values
>
> 4. based on those values it sets the registers so the SN65DSI84 uses the
> timings required by the panel (with a bit of math if needed):
>
> regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> mode->htotal - mode->hsync_end);
>
> Same for all other timings.
>
> Ti is more complicated if more cases need to be handled, such as dual-LVDS,
> and the chip documentation is vague about what must be done in those cases.
>
> I suggested next steps to move forward in reply to the cover letter.
>
Thank you so much for your suggestion.
>>>> @@ -965,9 +1001,15 @@ 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_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>> - MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>>>> + if (ctx->dual_link_video_mode)
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
>>>> + else
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>>> + MIPI_DSI_MODE_VIDEO_BURST |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HFP |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HSA |
>>>> + MIPI_DSI_MODE_NO_EOT_PACKET;
>>>
>>> There is no explanation about this, can you elaborate on why?
>>>
>>> I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84,
>>> and the removing MIPI_DSI_MODE_VIDEO_BURST seems to help, but I still have
>>> no idea why. Should you have any info, maybe from TI, it would be very
>>> interesting.
>>>
>>
>> During our earlier bring-up, TI mentioned that one possible reason for the DSI
>> REFCLK not behaving as expected could be that the DSI output is configured in
>> burst mode instead of non-burst mode. In burst mode the DSI clock may not be
>> continuous, whereas non-burst mode provides a more predictable DSI clock.
>
> Uhm, this is a bit vague. They basically said "burst can be more
> problematic than continuous", which is obvious, and "try disabling burst
> and see whether it helps" with no explanation on why one works and not the
> other. Shoudl you have more info from them you'd be welcome to share it. In
> particular, is disabling burst mode specifically related to dual-LVDS, or
> just a way to (try to) get rid of some problems without a clear
> understanding?
>
> On my side I also have a dual-LVDS panel connected to a SN65DSI84, which
> works only by disabling burst mode. I haven't tried upstreaming it because
> I don't have an explanation of why it fixes the panel and so I have no idea
> how to teach the driver when it should disable burst mode.
>
> Additionally inyour patch you remove many other flags. Any explanation from
> those?
>
Thanks for your inputs.
I wanted to share a quick observation from our side. With your suggested 3
patches (links below), the panel started working after simplifying the
dsi-> mode_flags:
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-1-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/lkml/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-1-e6aaa7e1d181@bootlin.com/
Earlier configuration:
MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
Working configuration:
MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA |
MIPI_DSI_MODE_NO_EOT_PACKET;
From our testing, removing MIPI_DSI_MODE_VIDEO_BURST along with the NO_HFP/NO_HBP
flags results in stable LVDS output in dual-link mode.
Could you please suggest how you would prefer to handle this change for
upstreaming?
> Best regards,
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
© 2016 - 2026 Red Hat, Inc.