[PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[Sudarshan Shetty]

Hi all,

This patch series improves dual-link LVDS support in the SN65DSI83
DSI-to-LVDS bridge driver.

Currently the driver programs identical horizontal timing parameters
for both single-link and dual-link LVDS modes. According to TI
documentation, when operating in dual-link mode the horizontal timing
values must be divided by two before being programmed into the device.
Without this adjustment, some panels fail to light up or produce
corrupted output.

TI also provides recommended register settings for dual-link LVDS
operation. This series adds support for an optional DT property
ti,dual-link-video-mode that enables the required configuration
in the driver.

When the property is present, the driver applies the recommended
register settings and uses a simplified DSI video mode configuration
to ensure correct dual-link LVDS operation.

Summary:
 - Add DT binding for ti,dual-link-video-mode
 - Add driver support to enable dual-link LVDS configuration
 - Apply recommended register settings for dual-link operation
 - Adjust DSI mode flags when dual-link mode is enabled

Changes in v2:
 - Introduce ti,dual-link-video-mode DT property
 - Add DT binding documentation for the new property
 - Update driver to read the DT property and apply dual-link
   configuration conditionally
 - Adjust DSI mode flags when dual-link video mode is enabled
 - Update commit messages

Thanks,
Anusha

Sudarshan Shetty (2):
  dt-bindings: display: bridge: ti,sn65dsi83: Add dual-link video mode
    property
  drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode

 .../bindings/display/bridge/ti,sn65dsi83.yaml |  9 ++++
 drivers/gpu/drm/bridge/ti-sn65dsi83.c         | 52 +++++++++++++++++--
 2 files changed, 57 insertions(+), 4 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] dt-bindings: display: bridge: ti,sn65dsi83: Add dual-link video mode property

[Sudarshan Shetty]

Add a new optional device tree property `ti,dual-link-video-mode`
to indicate that the bridge should configure the device for
dual-link LVDS video mode.

In dual-link configurations, some panels require the horizontal
timing parameters to be adjusted before programming them into
the device. In such cases, the horizontal timing values must be
divided by two when operating in dual-link mode.

Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
---
 .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
index e69b6343a8eb..b610739555a4 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -38,6 +38,15 @@ properties:
   interrupts:
     maxItems: 1
 
+  ti,dual-link-video-mode:
+    type: boolean
+    description: |
+      Enables configuration settings required for correct dual-link
+      LVDS operation. Some panels require the horizontal timing
+      parameters to be adjusted before being programmed into the
+      device. The horizontal timing values must be divided by
+      two when operating in dual-link mode.
+
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
 
-- 
2.34.1

Re: [PATCH v2 1/2] dt-bindings: display: bridge: ti, sn65dsi83: Add dual-link video mode property

[Luca Ceresoli]

Hello Sudarshan,

On Thu Mar 12, 2026 at 5:37 AM CET, Sudarshan Shetty wrote:
> Add a new optional device tree property `ti,dual-link-video-mode`
> to indicate that the bridge should configure the device for
> dual-link LVDS video mode.
>
> In dual-link configurations, some panels require the horizontal
> timing parameters to be adjusted before programming them into
> the device. In such cases, the horizontal timing values must be
> divided by two when operating in dual-link mode.
>
> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>

This is not needed. Dual link mode is already implied by the presence of
port@2 and port@3.

Also, the driver implements that already, and handles even/odd pixel swap
as well:

	ctx->lvds_dual_link = false;
	ctx->lvds_dual_link_even_odd_swap = false;
	if (model != MODEL_SN65DSI83) {
		struct device_node *port2, *port3;
		int dual_link;

		port2 = of_graph_get_port_by_id(dev->of_node, 2);
		port3 = of_graph_get_port_by_id(dev->of_node, 3);
		dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
		of_node_put(port2);
		of_node_put(port3);

		if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
			ctx->lvds_dual_link = true;
			/* Odd pixels to LVDS Channel A, even pixels to B */
			ctx->lvds_dual_link_even_odd_swap = false;
		} else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
			ctx->lvds_dual_link = true;
			/* Even pixels to LVDS Channel A, odd pixels to B */
			ctx->lvds_dual_link_even_odd_swap = true;
		}
	}

(https://elixir.bootlin.com/linux/v7.0-rc3/source/drivers/gpu/drm/bridge/ti-sn65dsi83.c#L895-L916)

Luca

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

Re: [PATCH v2 1/2] dt-bindings: display: bridge: ti, sn65dsi83: Add dual-link video mode property

[Krzysztof Kozlowski]

On Thu, Mar 12, 2026 at 04:46:40PM +0100, Luca Ceresoli wrote:
> Hello Sudarshan,
> 
> On Thu Mar 12, 2026 at 5:37 AM CET, Sudarshan Shetty wrote:
> > Add a new optional device tree property `ti,dual-link-video-mode`
> > to indicate that the bridge should configure the device for
> > dual-link LVDS video mode.
> >
> > In dual-link configurations, some panels require the horizontal
> > timing parameters to be adjusted before programming them into
> > the device. In such cases, the horizontal timing values must be
> > divided by two when operating in dual-link mode.
> >
> > Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
> 
> This is not needed. Dual link mode is already implied by the presence of
> port@2 and port@3.

Yep!

Thanks for chiming in.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: display: bridge: ti, sn65dsi83: Add dual-link video mode property

[tessolveupstream]

On 12-03-2026 21:16, Luca Ceresoli wrote:
> Hello Sudarshan,
> 
> On Thu Mar 12, 2026 at 5:37 AM CET, Sudarshan Shetty wrote:
>> Add a new optional device tree property `ti,dual-link-video-mode`
>> to indicate that the bridge should configure the device for
>> dual-link LVDS video mode.
>>
>> In dual-link configurations, some panels require the horizontal
>> timing parameters to be adjusted before programming them into
>> the device. In such cases, the horizontal timing values must be
>> divided by two when operating in dual-link mode.
>>
>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
> 
> This is not needed. Dual link mode is already implied by the presence of
> port@2 and port@3.
> 
> Also, the driver implements that already, and handles even/odd pixel swap
> as well:
> 
> 	ctx->lvds_dual_link = false;
> 	ctx->lvds_dual_link_even_odd_swap = false;
> 	if (model != MODEL_SN65DSI83) {
> 		struct device_node *port2, *port3;
> 		int dual_link;
> 
> 		port2 = of_graph_get_port_by_id(dev->of_node, 2);
> 		port3 = of_graph_get_port_by_id(dev->of_node, 3);
> 		dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
> 		of_node_put(port2);
> 		of_node_put(port3);
> 
> 		if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
> 			ctx->lvds_dual_link = true;
> 			/* Odd pixels to LVDS Channel A, even pixels to B */
> 			ctx->lvds_dual_link_even_odd_swap = false;
> 		} else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
> 			ctx->lvds_dual_link = true;
> 			/* Even pixels to LVDS Channel A, odd pixels to B */
> 			ctx->lvds_dual_link_even_odd_swap = true;
> 		}
> 	}
> 
> (https://elixir.bootlin.com/linux/v7.0-rc3/source/drivers/gpu/drm/bridge/ti-sn65dsi83.c#L895-L916)
> 

Thanks for the clarification.
For reference, the DTS currently used on our platform already 
describes the two LVDS output ports as follows:

lvds_bridge: bridge@2c {
                compatible = "ti,sn65dsi84";
                reg = <0x2c>;
                enable-gpios = <&tlmm 42 GPIO_ACTIVE_HIGH>;

                ti,dual-link-video-mode;

                ports {
                        #address-cells = <1>;
                        #size-cells = <0>;

                        port@0 {
                                reg = <0>;

                                sn65dsi84_in: endpoint {
                                        data-lanes = <1 2 3 4>;
                                        remote-endpoint = <&mdss_dsi0_out>;
                                };
                        };

                        port@2 {
                                reg = <2>;

                                sn65dsi84_out_a: endpoint {
                                        data-lanes = <1 2 3 4>;
                                        remote-endpoint = <&lvds_panel_out_a>;
                                };
                        };

                        port@3 {
                                reg = <3>;

                                sn65dsi84_out_b: endpoint {
                                        data-lanes = <1 2 3 4>;
                                        remote-endpoint = <&lvds_panel_out_b>;
                                };
                        };
                };

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

Re: [PATCH v2 1/2] dt-bindings: display: bridge: ti, sn65dsi83: Add dual-link video mode property

[tessolveupstream]

On 12-03-2026 21:16, Luca Ceresoli wrote:
> Hello Sudarshan,
> 
> On Thu Mar 12, 2026 at 5:37 AM CET, Sudarshan Shetty wrote:
>> Add a new optional device tree property `ti,dual-link-video-mode`
>> to indicate that the bridge should configure the device for
>> dual-link LVDS video mode.
>>
>> In dual-link configurations, some panels require the horizontal
>> timing parameters to be adjusted before programming them into
>> the device. In such cases, the horizontal timing values must be
>> divided by two when operating in dual-link mode.
>>
>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
> 
> This is not needed. Dual link mode is already implied by the presence of
> port@2 and port@3.
> 
> Also, the driver implements that already, and handles even/odd pixel swap
> as well:
> 
> 	ctx->lvds_dual_link = false;
> 	ctx->lvds_dual_link_even_odd_swap = false;
> 	if (model != MODEL_SN65DSI83) {
> 		struct device_node *port2, *port3;
> 		int dual_link;
> 
> 		port2 = of_graph_get_port_by_id(dev->of_node, 2);
> 		port3 = of_graph_get_port_by_id(dev->of_node, 3);
> 		dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
> 		of_node_put(port2);
> 		of_node_put(port3);
> 
> 		if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
> 			ctx->lvds_dual_link = true;
> 			/* Odd pixels to LVDS Channel A, even pixels to B */
> 			ctx->lvds_dual_link_even_odd_swap = false;
> 		} else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
> 			ctx->lvds_dual_link = true;
> 			/* Even pixels to LVDS Channel A, odd pixels to B */
> 			ctx->lvds_dual_link_even_odd_swap = true;
> 		}
> 	}
> 
> (https://elixir.bootlin.com/linux/v7.0-rc3/source/drivers/gpu/drm/bridge/ti-sn65dsi83.c#L895-L916)
> 

Thanks for the clarification.
For reference, the DTS currently used on our platform already 
describes the two LVDS output ports as follows:

lvds_bridge: bridge@2c {
                compatible = "ti,sn65dsi84";
                reg = <0x2c>;
                enable-gpios = <&tlmm 42 GPIO_ACTIVE_HIGH>;

                ti,dual-link-video-mode;

                ports {
                        #address-cells = <1>;
                        #size-cells = <0>;

                        port@0 {
                                reg = <0>;

                                sn65dsi84_in: endpoint {
                                        data-lanes = <1 2 3 4>;
                                        remote-endpoint = <&mdss_dsi0_out>;
                                };
                        };

                        port@2 {
                                reg = <2>;

                                sn65dsi84_out_a: endpoint {
                                        data-lanes = <1 2 3 4>;
                                        remote-endpoint = <&lvds_panel_out_a>;
                                };
                        };

                        port@3 {
                                reg = <3>;

                                sn65dsi84_out_b: endpoint {
                                        data-lanes = <1 2 3 4>;
                                        remote-endpoint = <&lvds_panel_out_b>;
                                };
                        };
                };

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

[PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode

[Sudarshan Shetty]

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

Re: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode

[Luca Ceresoli]

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.

>  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

Re: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode

[tessolveupstream]

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

Re: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode

[Luca Ceresoli]

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

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[Marek Vasut]

On 3/12/26 5:37 AM, Sudarshan Shetty wrote:
> Hi all,
> 
> This patch series improves dual-link LVDS support in the SN65DSI83
> DSI-to-LVDS bridge driver.
> 
> Currently the driver programs identical horizontal timing parameters
> for both single-link and dual-link LVDS modes. According to TI
> documentation, when operating in dual-link mode the horizontal timing
> values must be divided by two before being programmed into the device.
> Without this adjustment, some panels fail to light up or produce
> corrupted output.
> 
> TI also provides recommended register settings for dual-link LVDS
> operation. This series adds support for an optional DT property
> ti,dual-link-video-mode that enables the required configuration
> in the driver.
> 
> When the property is present, the driver applies the recommended
> register settings and uses a simplified DSI video mode configuration
> to ensure correct dual-link LVDS operation.
> 
> Summary:
>   - Add DT binding for ti,dual-link-video-mode
>   - Add driver support to enable dual-link LVDS configuration
>   - Apply recommended register settings for dual-link operation
>   - Adjust DSI mode flags when dual-link mode is enabled
> 
> Changes in v2:
>   - Introduce ti,dual-link-video-mode DT property
>   - Add DT binding documentation for the new property
>   - Update driver to read the DT property and apply dual-link
>     configuration conditionally
>   - Adjust DSI mode flags when dual-link video mode is enabled
>   - Update commit messages
> 
> Thanks,
> Anusha
> 
> Sudarshan Shetty (2):
>    dt-bindings: display: bridge: ti,sn65dsi83: Add dual-link video mode
>      property
>    drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode
> 
>   .../bindings/display/bridge/ti,sn65dsi83.yaml |  9 ++++
>   drivers/gpu/drm/bridge/ti-sn65dsi83.c         | 52 +++++++++++++++++--
>   2 files changed, 57 insertions(+), 4 deletions(-)
+CC Luca

You might want to look at recently posted:

[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual 
LVDS output

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[tessolveupstream]

On 12-03-2026 10:35, Marek Vasut wrote:
> On 3/12/26 5:37 AM, Sudarshan Shetty wrote:
>> Hi all,
>>
>> This patch series improves dual-link LVDS support in the SN65DSI83
>> DSI-to-LVDS bridge driver.
>>
>> Currently the driver programs identical horizontal timing parameters
>> for both single-link and dual-link LVDS modes. According to TI
>> documentation, when operating in dual-link mode the horizontal timing
>> values must be divided by two before being programmed into the device.
>> Without this adjustment, some panels fail to light up or produce
>> corrupted output.
>>
>> TI also provides recommended register settings for dual-link LVDS
>> operation. This series adds support for an optional DT property
>> ti,dual-link-video-mode that enables the required configuration
>> in the driver.
>>
>> When the property is present, the driver applies the recommended
>> register settings and uses a simplified DSI video mode configuration
>> to ensure correct dual-link LVDS operation.
>>
>> Summary:
>>   - Add DT binding for ti,dual-link-video-mode
>>   - Add driver support to enable dual-link LVDS configuration
>>   - Apply recommended register settings for dual-link operation
>>   - Adjust DSI mode flags when dual-link mode is enabled
>>
>> Changes in v2:
>>   - Introduce ti,dual-link-video-mode DT property
>>   - Add DT binding documentation for the new property
>>   - Update driver to read the DT property and apply dual-link
>>     configuration conditionally
>>   - Adjust DSI mode flags when dual-link video mode is enabled
>>   - Update commit messages
>>
>> Thanks,
>> Anusha
>>
>> Sudarshan Shetty (2):
>>    dt-bindings: display: bridge: ti,sn65dsi83: Add dual-link video mode
>>      property
>>    drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode
>>
>>   .../bindings/display/bridge/ti,sn65dsi83.yaml |  9 ++++
>>   drivers/gpu/drm/bridge/ti-sn65dsi83.c         | 52 +++++++++++++++++--
>>   2 files changed, 57 insertions(+), 4 deletions(-)
> +CC Luca
> 
> You might want to look at recently posted:
> 
> [PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output

Thanks for pointing this out.
I tried applying the patch “[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output” on top of the current tree and 
removed the changes that I had previously added in the driver.
However, with this patch applied, I am currently seeing only the backlight turning on and no image on the LVDS panel.
For reference, the LVDS panel used on our platform is G133HAN01.1 and the 
DSI-to-dual-link LVDS bridge is SN65DSI84ZXHR.

During our earlier debugging, we went through several trial-and-error 
iterations and also received support from TI. According to TI, when 
operating in dual-link mode the horizontal timing parameters must be 
divided by two before being written to the device. Without this 
adjustment, the panel either does not light up or shows corrupted output.

TI also shared a set of recommended register settings for dual-link mode, 
which were derived using the TI DSI-Tuner tool. These settings helped us 
get the panel working on our hardware during testing.
For reference, the register configuration suggested by TI is as follows:

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

If it would help, we can test any proposed changes on our hardware. 
Please let me know if incorporating these register settings or additional adjustments would be the right direction for supporting dual-link LVDS 
in this driver.
Is the current patch expected to fully support dual-link LVDS, or are 
there additional changes planned for the SN65DSI84 driver?

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[Luca Ceresoli]

Hello Sudarshan,

and thanks Marek for copying me, I hadn't noticed this series.

On Thu Mar 12, 2026 at 1:35 PM CET, tessolveupstream wrote:

[...]

>> +CC Luca
>>
>> You might want to look at recently posted:
>>
>> [PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output
>
> Thanks for pointing this out.
> I tried applying the patch “[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output” on top of the current tree and
> removed the changes that I had previously added in the driver.
> However, with this patch applied, I am currently seeing only the backlight turning on and no image on the LVDS panel.
> For reference, the LVDS panel used on our platform is G133HAN01.1 and the
> DSI-to-dual-link LVDS bridge is SN65DSI84ZXHR.

Thanks for having tried.

Can you please test with both the fixes in the series applied + the test
pattern feature and report the results you get with and without test
pattern enabled?

The patches to apply are:

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

> During our earlier debugging, we went through several trial-and-error
> iterations and also received support from TI. According to TI, when
> operating in dual-link mode the horizontal timing parameters must be
> divided by two before being written to the device. Without this
> adjustment, the panel either does not light up or shows corrupted output.
>
> TI also shared a set of recommended register settings for dual-link mode,
> which were derived using the TI DSI-Tuner tool. These settings helped us
> get the panel working on our hardware during testing.
> For reference, the register configuration suggested by TI is as follows:
>
> 	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);
>
> If it would help, we can test any proposed changes on our hardware.

The first thing I suggest doing on your side is testing with the 3 patches
mentioned above.

If you display works, good! Let us know (you can also add your Tested-by /
Reviewed-by tags to the test_pattern patch too if applicable).

If it doesn't work, compare the individual register values to find the
differences, try to figure out why the working setting works and how to
apply that change to the driver in away that keeps other boards
working. You're welcome to come back here to discuss it in case you can't
find out on your own.

Hope this helps,
Luca

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

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[tessolveupstream]

On 12-03-2026 21:19, Luca Ceresoli wrote:
> Hello Sudarshan,
> 
> and thanks Marek for copying me, I hadn't noticed this series.
> 
> On Thu Mar 12, 2026 at 1:35 PM CET, tessolveupstream wrote:
> 
> [...]
> 
>>> +CC Luca
>>>
>>> You might want to look at recently posted:
>>>
>>> [PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output
>>
>> Thanks for pointing this out.
>> I tried applying the patch “[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output” on top of the current tree and
>> removed the changes that I had previously added in the driver.
>> However, with this patch applied, I am currently seeing only the backlight turning on and no image on the LVDS panel.
>> For reference, the LVDS panel used on our platform is G133HAN01.1 and the
>> DSI-to-dual-link LVDS bridge is SN65DSI84ZXHR.
> 
> Thanks for having tried.
> 
> Can you please test with both the fixes in the series applied + the test
> pattern feature and report the results you get with and without test
> pattern enabled?
> 
> The patches to apply are:
> 
>  - 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/
> 

Thanks for the suggestions.

I tested the three patches together as mentioned, but the LVDS panel 
still only shows the backlight and no image. I also tried removing the 
test-pattern patch and retesting with only the remaining two fixes, but 
the result remained the same — only the backlight turns on and no image 
is displayed.
>> During our earlier debugging, we went through several trial-and-error
>> iterations and also received support from TI. According to TI, when
>> operating in dual-link mode the horizontal timing parameters must be
>> divided by two before being written to the device. Without this
>> adjustment, the panel either does not light up or shows corrupted output.
>>
>> TI also shared a set of recommended register settings for dual-link mode,
>> which were derived using the TI DSI-Tuner tool. These settings helped us
>> get the panel working on our hardware during testing.
>> For reference, the register configuration suggested by TI is as follows:
>>
>> 	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);
>>
>> If it would help, we can test any proposed changes on our hardware.
> 
> The first thing I suggest doing on your side is testing with the 3 patches
> mentioned above.
> 
> If you display works, good! Let us know (you can also add your Tested-by /
> Reviewed-by tags to the test_pattern patch too if applicable).
> 
> If it doesn't work, compare the individual register values to find the
> differences, try to figure out why the working setting works and how to
> apply that change to the driver in away that keeps other boards
> working. You're welcome to come back here to discuss it in case you can't
> find out on your own.
> 

I tested the three patches as suggested, but the panel still shows only the 
backlight with no visible image. I’m unsure how to translate the working 
register values into a generic fix based on display timings. Any guidance 
on the right direction would be helpful.
> Hope this helps,
> Luca
> 
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[Luca Ceresoli]

Hello Sudarshan,

On Wed Mar 18, 2026 at 6:45 AM CET, tessolveupstream wrote:
>>>> You might want to look at recently posted:
>>>>
>>>> [PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output
>>>
>>> Thanks for pointing this out.
>>> I tried applying the patch “[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output” on top of the current tree and
>>> removed the changes that I had previously added in the driver.
>>> However, with this patch applied, I am currently seeing only the backlight turning on and no image on the LVDS panel.
>>> For reference, the LVDS panel used on our platform is G133HAN01.1 and the
>>> DSI-to-dual-link LVDS bridge is SN65DSI84ZXHR.
>>
>> Thanks for having tried.
>>
>> Can you please test with both the fixes in the series applied + the test
>> pattern feature and report the results you get with and without test
>> pattern enabled?
>>
>> The patches to apply are:
>>
>>  - 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/
>>
>
> Thanks for the suggestions.
>
> I tested the three patches together as mentioned, but the LVDS panel
> still only shows the backlight and no image. I also tried removing the
> test-pattern patch and retesting with only the remaining two fixes, but
> the result remained the same — only the backlight turns on and no image
> is displayed.

Sure, the test pattern patch does not change anything, unless you enable
the test pattern.

>> The first thing I suggest doing on your side is testing with the 3 patches
>> mentioned above.
>>
>> If you display works, good! Let us know (you can also add your Tested-by /
>> Reviewed-by tags to the test_pattern patch too if applicable).
>>
>> If it doesn't work, compare the individual register values to find the
>> differences, try to figure out why the working setting works and how to
>> apply that change to the driver in away that keeps other boards
>> working. You're welcome to come back here to discuss it in case you can't
>> find out on your own.
>>
>
> I tested the three patches as suggested, but the panel still shows only the
> backlight with no visible image. I’m unsure how to translate the working
> register values into a generic fix based on display timings. Any guidance
> on the right direction would be helpful.

What you should do is:

 1. with your patches, and while the display is enabled (and working) do

     cat /sys/kernel/debug/regmap/4-002c/registers >regs.working

 2. remove your patches, add the 3 I mentioned, and while the display is
    enabled (but only backlight is working) do

     cat /sys/kernel/debug/regmap/4-002c/registers >regs.broken

Then compare regs.working and regs.broken. Which registers differ? Can you
give a reason for the differences?

You can come back with these values here so we may discuss them.

Luca

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

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[tessolveupstream]

On 18-03-2026 14:21, Luca Ceresoli wrote:
> Hello Sudarshan,
> 
> On Wed Mar 18, 2026 at 6:45 AM CET, tessolveupstream wrote:
>>>>> You might want to look at recently posted:
>>>>>
>>>>> [PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output
>>>>
>>>> Thanks for pointing this out.
>>>> I tried applying the patch “[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output” on top of the current tree and
>>>> removed the changes that I had previously added in the driver.
>>>> However, with this patch applied, I am currently seeing only the backlight turning on and no image on the LVDS panel.
>>>> For reference, the LVDS panel used on our platform is G133HAN01.1 and the
>>>> DSI-to-dual-link LVDS bridge is SN65DSI84ZXHR.
>>>
>>> Thanks for having tried.
>>>
>>> Can you please test with both the fixes in the series applied + the test
>>> pattern feature and report the results you get with and without test
>>> pattern enabled?
>>>
>>> The patches to apply are:
>>>
>>>  - 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/
>>>
>>
>> Thanks for the suggestions.
>>
>> I tested the three patches together as mentioned, but the LVDS panel
>> still only shows the backlight and no image. I also tried removing the
>> test-pattern patch and retesting with only the remaining two fixes, but
>> the result remained the same — only the backlight turns on and no image
>> is displayed.
> 
> Sure, the test pattern patch does not change anything, unless you enable
> the test pattern.
> 
>>> The first thing I suggest doing on your side is testing with the 3 patches
>>> mentioned above.
>>>
>>> If you display works, good! Let us know (you can also add your Tested-by /
>>> Reviewed-by tags to the test_pattern patch too if applicable).
>>>
>>> If it doesn't work, compare the individual register values to find the
>>> differences, try to figure out why the working setting works and how to
>>> apply that change to the driver in away that keeps other boards
>>> working. You're welcome to come back here to discuss it in case you can't
>>> find out on your own.
>>>
>>
>> I tested the three patches as suggested, but the panel still shows only the
>> backlight with no visible image. I’m unsure how to translate the working
>> register values into a generic fix based on display timings. Any guidance
>> on the right direction would be helpful.
> 
> What you should do is:
> 
>  1. with your patches, and while the display is enabled (and working) do
> 
>      cat /sys/kernel/debug/regmap/4-002c/registers >regs.working
> 
>  2. remove your patches, add the 3 I mentioned, and while the display is
>     enabled (but only backlight is working) do
> 
>      cat /sys/kernel/debug/regmap/4-002c/registers >regs.broken
> 
> Then compare regs.working and regs.broken. Which registers differ? Can you
> give a reason for the differences?
> 
> You can come back with these values here so we may discuss them.
>

I followed your suggestion and captured the register dumps in both cases.
~# cat regs.working
00: 35
01: 38
02: 49
03: 53
04: 44
05: 20
06: 20
07: 20
08: 01
09: 01
0a: 85
0b: 28
0d: 01
10: 26
11: 00
12: 53
18: 6f
19: 00
1a: 03
1b: 00
20: 80
21: 07
24: 00
25: 00
28: 21
29: 00
2c: 10
2d: 00
30: 0e
31: 00
34: 28
36: 00
38: 00
3a: 00
3c: 00
e0: 00
e1: 00
e5: 00

~# cat regs.broken
00: 35
01: 38
02: 49
03: 53
04: 44
05: 20
06: 20
07: 20
08: 01
09: 01
0a: 85
0b: 28
0d: 01
10: 26
11: 00
12: 55
18: 0f
19: 05
1a: 03
1b: 00
20: 80
21: 07
24: 38
25: 04
28: 21
29: 00
2c: 15
2d: 00
30: 0e
31: 00
34: 2c
36: 0e
38: 1d
3a: 08
3c: 00
e0: 00
e1: 00
e5: 00

In the working case, several of the timing registers remain at 0, 
while in the broken case they are programmed with non-zero values.
> Luca
> 
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[Luca Ceresoli]

On Thu Mar 19, 2026 at 10:55 AM CET, tessolveupstream wrote:
>
>
> On 18-03-2026 14:21, Luca Ceresoli wrote:
>> Hello Sudarshan,
>>
>> On Wed Mar 18, 2026 at 6:45 AM CET, tessolveupstream wrote:
>>>>>> You might want to look at recently posted:
>>>>>>
>>>>>> [PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output
>>>>>
>>>>> Thanks for pointing this out.
>>>>> I tried applying the patch “[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output” on top of the current tree and
>>>>> removed the changes that I had previously added in the driver.
>>>>> However, with this patch applied, I am currently seeing only the backlight turning on and no image on the LVDS panel.
>>>>> For reference, the LVDS panel used on our platform is G133HAN01.1 and the
>>>>> DSI-to-dual-link LVDS bridge is SN65DSI84ZXHR.
>>>>
>>>> Thanks for having tried.
>>>>
>>>> Can you please test with both the fixes in the series applied + the test
>>>> pattern feature and report the results you get with and without test
>>>> pattern enabled?
>>>>
>>>> The patches to apply are:
>>>>
>>>>  - 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/
>>>>
>>>
>>> Thanks for the suggestions.
>>>
>>> I tested the three patches together as mentioned, but the LVDS panel
>>> still only shows the backlight and no image. I also tried removing the
>>> test-pattern patch and retesting with only the remaining two fixes, but
>>> the result remained the same — only the backlight turns on and no image
>>> is displayed.
>>
>> Sure, the test pattern patch does not change anything, unless you enable
>> the test pattern.
>>
>>>> The first thing I suggest doing on your side is testing with the 3 patches
>>>> mentioned above.
>>>>
>>>> If you display works, good! Let us know (you can also add your Tested-by /
>>>> Reviewed-by tags to the test_pattern patch too if applicable).
>>>>
>>>> If it doesn't work, compare the individual register values to find the
>>>> differences, try to figure out why the working setting works and how to
>>>> apply that change to the driver in away that keeps other boards
>>>> working. You're welcome to come back here to discuss it in case you can't
>>>> find out on your own.
>>>>
>>>
>>> I tested the three patches as suggested, but the panel still shows only the
>>> backlight with no visible image. I’m unsure how to translate the working
>>> register values into a generic fix based on display timings. Any guidance
>>> on the right direction would be helpful.
>>
>> What you should do is:
>>
>>  1. with your patches, and while the display is enabled (and working) do
>>
>>      cat /sys/kernel/debug/regmap/4-002c/registers >regs.working
>>
>>  2. remove your patches, add the 3 I mentioned, and while the display is
>>     enabled (but only backlight is working) do
>>
>>      cat /sys/kernel/debug/regmap/4-002c/registers >regs.broken
>>
>> Then compare regs.working and regs.broken. Which registers differ? Can you
>> give a reason for the differences?
>>
>> You can come back with these values here so we may discuss them.
>>
>
> I followed your suggestion and captured the register dumps in both cases.

Thanks for getting the values.

> In the working case, several of the timing registers remain at 0,
> while in the broken case they are programmed with non-zero values.

Yes, but read the documentation carefully and you will discover this is
OK. Also you shuld analyze all the differences, some are very interesting.

The differences are:

  reg working broken  what changes
  12:   53      55    CHA_DSI_CLK_RANGE
  18:   6f      0f    HS_NEG_POLARITY, VS_NEG_POLARITY
  19:   00      05    CHB_LVDS_VOD_SWING, CHA_LVDS_VOD_SWING
  24:   00      38    CHA_VERTICAL_DISPLAY_SIZE_LOW (*)
  25:   00      04    CHA_VERTICAL_DISPLAY_SIZE_HIGH (*)
  2c:   10      15    CHA_HSYNC_PULSE_WIDTH_LOW
  34:   28      2c    CHA_HORIZONTAL_BACK_PORCH
  36:   00      0e    CHA_VERTICAL_BACK_PORCH (*)
  38:   00      1d    CHA_HORIZONTAL_FRONT_PORCH (*)
  3a:   00      08    CHA_VERTICAL_FRONT_PORCH (*)

Values with (*) are those you mentioned above (zero in the working case,
nonzero in the "broken" case). The docs for these registers says: "TEST
PATTERN GENERATION PURPOSE ONLY". Those values are irrelevant when not
using the test pattern.

Your timings are all different. That means probably you have them
incorrectly described in device tree or the panel driver, so the
ti-sn65dsi83 driver computes them using a correct formula but based on
incorrect inputs, thus producing incorrect output values into the
registers. What are the timings in your dts or the panel drivers? If you
don't understand the question: what is your panel description in device
tree?

About CHA_DSI_CLK_RANGE: what is your DSI clock?

Finally I don't think the swing values are problematic, so I'd leave them
as the last thing to check.

Luca

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

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[tessolveupstream]

On 19-03-2026 19:17, Luca Ceresoli wrote:
> On Thu Mar 19, 2026 at 10:55 AM CET, tessolveupstream wrote:
>>
>>
>> On 18-03-2026 14:21, Luca Ceresoli wrote:
>>> Hello Sudarshan,
>>>
>>> On Wed Mar 18, 2026 at 6:45 AM CET, tessolveupstream wrote:
>>>>>>> You might want to look at recently posted:
>>>>>>>
>>>>>>> [PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output
>>>>>>
>>>>>> Thanks for pointing this out.
>>>>>> I tried applying the patch “[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output” on top of the current tree and
>>>>>> removed the changes that I had previously added in the driver.
>>>>>> However, with this patch applied, I am currently seeing only the backlight turning on and no image on the LVDS panel.
>>>>>> For reference, the LVDS panel used on our platform is G133HAN01.1 and the
>>>>>> DSI-to-dual-link LVDS bridge is SN65DSI84ZXHR.
>>>>>
>>>>> Thanks for having tried.
>>>>>
>>>>> Can you please test with both the fixes in the series applied + the test
>>>>> pattern feature and report the results you get with and without test
>>>>> pattern enabled?
>>>>>
>>>>> The patches to apply are:
>>>>>
>>>>>  - 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/
>>>>>
>>>>
>>>> Thanks for the suggestions.
>>>>
>>>> I tested the three patches together as mentioned, but the LVDS panel
>>>> still only shows the backlight and no image. I also tried removing the
>>>> test-pattern patch and retesting with only the remaining two fixes, but
>>>> the result remained the same — only the backlight turns on and no image
>>>> is displayed.
>>>
>>> Sure, the test pattern patch does not change anything, unless you enable
>>> the test pattern.
>>>
>>>>> The first thing I suggest doing on your side is testing with the 3 patches
>>>>> mentioned above.
>>>>>
>>>>> If you display works, good! Let us know (you can also add your Tested-by /
>>>>> Reviewed-by tags to the test_pattern patch too if applicable).
>>>>>
>>>>> If it doesn't work, compare the individual register values to find the
>>>>> differences, try to figure out why the working setting works and how to
>>>>> apply that change to the driver in away that keeps other boards
>>>>> working. You're welcome to come back here to discuss it in case you can't
>>>>> find out on your own.
>>>>>
>>>>
>>>> I tested the three patches as suggested, but the panel still shows only the
>>>> backlight with no visible image. I’m unsure how to translate the working
>>>> register values into a generic fix based on display timings. Any guidance
>>>> on the right direction would be helpful.
>>>
>>> What you should do is:
>>>
>>>  1. with your patches, and while the display is enabled (and working) do
>>>
>>>      cat /sys/kernel/debug/regmap/4-002c/registers >regs.working
>>>
>>>  2. remove your patches, add the 3 I mentioned, and while the display is
>>>     enabled (but only backlight is working) do
>>>
>>>      cat /sys/kernel/debug/regmap/4-002c/registers >regs.broken
>>>
>>> Then compare regs.working and regs.broken. Which registers differ? Can you
>>> give a reason for the differences?
>>>
>>> You can come back with these values here so we may discuss them.
>>>
>>
>> I followed your suggestion and captured the register dumps in both cases.
> 
> Thanks for getting the values.
> 
>> In the working case, several of the timing registers remain at 0,
>> while in the broken case they are programmed with non-zero values.
> 
> Yes, but read the documentation carefully and you will discover this is
> OK. Also you shuld analyze all the differences, some are very interesting.
> 
> The differences are:
> 
>   reg working broken  what changes
>   12:   53      55    CHA_DSI_CLK_RANGE
>   18:   6f      0f    HS_NEG_POLARITY, VS_NEG_POLARITY
>   19:   00      05    CHB_LVDS_VOD_SWING, CHA_LVDS_VOD_SWING
>   24:   00      38    CHA_VERTICAL_DISPLAY_SIZE_LOW (*)
>   25:   00      04    CHA_VERTICAL_DISPLAY_SIZE_HIGH (*)
>   2c:   10      15    CHA_HSYNC_PULSE_WIDTH_LOW
>   34:   28      2c    CHA_HORIZONTAL_BACK_PORCH
>   36:   00      0e    CHA_VERTICAL_BACK_PORCH (*)
>   38:   00      1d    CHA_HORIZONTAL_FRONT_PORCH (*)
>   3a:   00      08    CHA_VERTICAL_FRONT_PORCH (*)
> 
> Values with (*) are those you mentioned above (zero in the working case,
> nonzero in the "broken" case). The docs for these registers says: "TEST
> PATTERN GENERATION PURPOSE ONLY". Those values are irrelevant when not
> using the test pattern.
> 
> Your timings are all different. That means probably you have them
> incorrectly described in device tree or the panel driver, so the
> ti-sn65dsi83 driver computes them using a correct formula but based on
> incorrect inputs, thus producing incorrect output values into the
> registers. What are the timings in your dts or the panel drivers? If you
> don't understand the question: what is your panel description in device
> tree?
>

Thanks for the detailed explanation.
Regarding the panel timings, they are not explicitly defined in the DTS. 
The panel is currently using the timings provided by the panel driver 
(panel-simple.c), specifically:

static const struct display_timing auo_g133han01_timings = {
        .pixelclock = { 134000000, 141200000, 149000000 },
        .hactive = { 1920, 1920, 1920 },
        .hfront_porch = { 39, 58, 77 },
        .hback_porch = { 59, 88, 117 },
        .hsync_len = { 28, 42, 56 },
        .vactive = { 1080, 1080, 1080 },
        .vfront_porch = { 3, 8, 11 },
        .vback_porch = { 5, 14, 19 },
        .vsync_len = { 4, 14, 19 },
};

The panel I am using is based on AUO G133HAN01, and the datasheet can 
be found here:
https://datasheet4u.com/pdf/1257948/G133HAN01.0.pdf > About CHA_DSI_CLK_RANGE: what is your DSI clock?
> 

In the current working configuration, the measured clock frequencies 
are:
DSI_CLK: ~422MHz
LVDS_CLK(both A & B Channels): ~70MHz
> Finally I don't think the swing values are problematic, so I'd leave them
> as the last thing to check.
> 
> Luca
> 
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[Alexander Stein]

Am Dienstag, 24. März 2026, 12:00:43 CET schrieb tessolveupstream@gmail.com:
> [snip]
> > Thanks for the detailed explanation.
> Regarding the panel timings, they are not explicitly defined in the DTS. 
> The panel is currently using the timings provided by the panel driver 
> (panel-simple.c), specifically:
> 
> static const struct display_timing auo_g133han01_timings = {
>         .pixelclock = { 134000000, 141200000, 149000000 },
>         .hactive = { 1920, 1920, 1920 },
>         .hfront_porch = { 39, 58, 77 },
>         .hback_porch = { 59, 88, 117 },
>         .hsync_len = { 28, 42, 56 },
>         .vactive = { 1080, 1080, 1080 },
>         .vfront_porch = { 3, 8, 11 },
>         .vback_porch = { 5, 14, 19 },
>         .vsync_len = { 4, 14, 19 },
> };
> 
> The panel I am using is based on AUO G133HAN01, and the datasheet can 
> be found here:
> https://datasheet4u.com/pdf/1257948/G133HAN01.0.pdf > About CHA_DSI_CLK_RANGE: what is your DSI clock?
> > 
> 
> In the current working configuration, the measured clock frequencies 
> are:
> DSI_CLK: ~422MHz
> LVDS_CLK(both A & B Channels): ~70MHz
> > Finally I don't think the swing values are problematic, so I'd leave them
> > as the last thing to check.

I managed to get this display running with this DSI->LVDS bridge on
TQMa8MxML/TQMa8MxNL (imx8mm or imx8mn) platform.
See [1] for the DT. What platform/ DSI host are you using?

Best regards,
Alexander

[1] https://lore.kernel.org/all/20260316135820.760073-2-alexander.stein@ew.tq-group.com/
-- 
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 v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[tessolveupstream]

On 24-03-2026 16:40, Alexander Stein wrote:
> Am Dienstag, 24. März 2026, 12:00:43 CET schrieb tessolveupstream@gmail.com:
>> [snip]
>>> Thanks for the detailed explanation.
>> Regarding the panel timings, they are not explicitly defined in the DTS. 
>> The panel is currently using the timings provided by the panel driver 
>> (panel-simple.c), specifically:
>>
>> static const struct display_timing auo_g133han01_timings = {
>>         .pixelclock = { 134000000, 141200000, 149000000 },
>>         .hactive = { 1920, 1920, 1920 },
>>         .hfront_porch = { 39, 58, 77 },
>>         .hback_porch = { 59, 88, 117 },
>>         .hsync_len = { 28, 42, 56 },
>>         .vactive = { 1080, 1080, 1080 },
>>         .vfront_porch = { 3, 8, 11 },
>>         .vback_porch = { 5, 14, 19 },
>>         .vsync_len = { 4, 14, 19 },
>> };
>>
>> The panel I am using is based on AUO G133HAN01, and the datasheet can 
>> be found here:
>> https://datasheet4u.com/pdf/1257948/G133HAN01.0.pdf > About CHA_DSI_CLK_RANGE: what is your DSI clock?
>>>
>>
>> In the current working configuration, the measured clock frequencies 
>> are:
>> DSI_CLK: ~422MHz
>> LVDS_CLK(both A & B Channels): ~70MHz
>>> Finally I don't think the swing values are problematic, so I'd leave them
>>> as the last thing to check.
> 
> I managed to get this display running with this DSI->LVDS bridge on
> TQMa8MxML/TQMa8MxNL (imx8mm or imx8mn) platform.
> See [1] for the DT. What platform/ DSI host are you using?
>

Thanks for sharing your setup.

I am currently working on the Qualcomm QCS615 platform. The setup 
is as follows:

- SoC: QCS615
- Bridge: TI SN65DSI84 (DSI to dual-link LVDS)
- Panel: AUO G133HAN01

I am currently using the following DT overlay:
(talos-evk-lvds-auo,g133han01.dtso)
https://lore.kernel.org/all/20260302121159.1938694-1-tessolveupstream@gmail.com/T/#m00e90e7ff95915bbdb21dbd786c232526e3360a2

Could you please confirm whether the display was brought up on your platform 
using only the DT changes you shared, without requiring any driver 
modifications?
 
> Best regards,
> Alexander
> 
> [1] https://lore.kernel.org/all/20260316135820.760073-2-alexander.stein@ew.tq-group.com/

Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support

[Alexander Stein]

Am Mittwoch, 25. März 2026, 07:09:07 CET schrieb tessolveupstream@gmail.com:
> 
> On 24-03-2026 16:40, Alexander Stein wrote:
> > Am Dienstag, 24. März 2026, 12:00:43 CET schrieb tessolveupstream@gmail.com:
> >> [snip]
> >>> Thanks for the detailed explanation.
> >> Regarding the panel timings, they are not explicitly defined in the DTS. 
> >> The panel is currently using the timings provided by the panel driver 
> >> (panel-simple.c), specifically:
> >>
> >> static const struct display_timing auo_g133han01_timings = {
> >>         .pixelclock = { 134000000, 141200000, 149000000 },
> >>         .hactive = { 1920, 1920, 1920 },
> >>         .hfront_porch = { 39, 58, 77 },
> >>         .hback_porch = { 59, 88, 117 },
> >>         .hsync_len = { 28, 42, 56 },
> >>         .vactive = { 1080, 1080, 1080 },
> >>         .vfront_porch = { 3, 8, 11 },
> >>         .vback_porch = { 5, 14, 19 },
> >>         .vsync_len = { 4, 14, 19 },
> >> };
> >>
> >> The panel I am using is based on AUO G133HAN01, and the datasheet can 
> >> be found here:
> >> https://datasheet4u.com/pdf/1257948/G133HAN01.0.pdf > About CHA_DSI_CLK_RANGE: what is your DSI clock?
> >>>
> >>
> >> In the current working configuration, the measured clock frequencies 
> >> are:
> >> DSI_CLK: ~422MHz
> >> LVDS_CLK(both A & B Channels): ~70MHz
> >>> Finally I don't think the swing values are problematic, so I'd leave them
> >>> as the last thing to check.
> > 
> > I managed to get this display running with this DSI->LVDS bridge on
> > TQMa8MxML/TQMa8MxNL (imx8mm or imx8mn) platform.
> > See [1] for the DT. What platform/ DSI host are you using?
> >
> 
> Thanks for sharing your setup.
> 
> I am currently working on the Qualcomm QCS615 platform. The setup 
> is as follows:
> 
> - SoC: QCS615
> - Bridge: TI SN65DSI84 (DSI to dual-link LVDS)
> - Panel: AUO G133HAN01
> 
> I am currently using the following DT overlay:
> (talos-evk-lvds-auo,g133han01.dtso)
> https://lore.kernel.org/all/20260302121159.1938694-1-tessolveupstream@gmail.com/T/#m00e90e7ff95915bbdb21dbd786c232526e3360a2

I don't know your SoC, but at a first glance the DT looks okay.

> Could you please confirm whether the display was brought up on your platform 
> using only the DT changes you shared, without requiring any driver 
> modifications?

Yes, no modifications on the driver. Do you see any picture on your display?
Initialization of these DSI-to-X bridges is a mess. Most of them need LP-11
on the DSI (clock/data0?) lanes upon reset.
I've also read that some DSI hosts (Raspberry Pi?) adjust the display timings
in hardware as well. Also make sure your burst clock is high enough.

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/