drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support
Subsystems (4)
v2 cover drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support
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(-)
Signature · 1 line
2.34.1
PATCH v2 1/2 dt-bindings: display: bridge: ti,sn65dsi83: Add dual-link video mode property
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.
--- .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 9 +++++++++ 1 file changed, 9 insertions(+)
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +9 -0
@@ -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
Signature · 1 line
2.34.1
Luca Ceresoli
reviewerRe: [PATCH v2 1/2] dt-bindings: display: bridge: ti, sn65dsi83: Add dual-link video mode property
Hello Sudarshan,
Quoted 10 lines · Sudarshan Shetty
Add a new optional device tree property
ti,dual-link-video-modeto 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 <[email protected]>
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
Quoted 12 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 9 lines · Sudarshan Shetty
Add a new optional device tree property
ti,dual-link-video-modeto 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.
Quoted 4 lines
Quoted 1 line
Signed-off-by Sudarshan Shetty <[email protected]>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
In reply to Luca CeresoliQuoted 43 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 10 lines · Sudarshan Shetty
Add a new optional device tree property
ti,dual-link-video-modeto 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 <[email protected]>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; } }
Quoted 2 lines
(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>;
};
};
};Quoted 6 lines
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
In reply to Luca CeresoliQuoted 43 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 10 lines · Sudarshan Shetty
Add a new optional device tree property
ti,dual-link-video-modeto 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 <[email protected]>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; } }
Quoted 2 lines
(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>;
};
};
};Quoted 6 lines
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
In reply to Sudarshan ShettySome 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.
--- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 52 ++++++++++++++++++++++++--- 1 file changed, 48 insertions(+), 4 deletions(-)
drivers/gpu/drm/bridge/ti-sn65dsi83.c +48 -4
@@ -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" );
Signature · 1 line
2.34.1
Luca Ceresoli
reviewerRe: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode
Hello Sudarshan,
Quoted 22 lines · 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 <[email protected]>--- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 52 ++++++++++++++++++++++++--- 1 file changed, 48 insertions(+), 4 deletions(-)drivers/gpu/drm/bridge/ti-sn65dsi83.c +0
-0
drivers/gpu/drm/bridge/ti-sn65dsi83.c struct sn65dsi83 { · line 167
Quoted 4 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +1
-0@@ -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.
Quoted 31 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +24
-1static 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,
drivers/gpu/drm/bridge/ti-sn65dsi83.c static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, · line 705
Quoted 10 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +10
-0+ 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.
Quoted 11 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +2
-2+ +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 |
drivers/gpu/drm/bridge/ti-sn65dsi83.c static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) · line 1012
Quoted 10 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +9
-1-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
Quoted 20 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 17 lines · 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 <[email protected]>--- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 52 ++++++++++++++++++++++++--- 1 file changed, 48 insertions(+), 4 deletions(-)
Quoted 13 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c struct sn65dsi83 { · line 167
Quoted 9 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +1
-0@@ -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.
Quoted 36 lines
Quoted 36 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +29
-1static 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 );
Quoted 9 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, · line 705
Quoted 5 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +5
-0+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?
Quoted 24 lines
Quoted 11 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +2
-2+ +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 |drivers/gpu/drm/bridge/ti-sn65dsi83.c static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) · line 1012
Quoted 10 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +9
-1-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?
Quoted 5 lines
I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84, and the removing
MIPI_DSI_MODE_VIDEO_BURSTseems 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.
Quoted 6 lines
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Luca Ceresoli
reviewerRe: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode
Hello Sudarshan,
Quoted 33 lines · tessolveupstream
Quoted 16 lines
Quoted 16 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +16
-0+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 );Quoted 9 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, · line 705
Quoted 5 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +5
-0+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.
Quoted 5 lines
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.
Quoted 25 lines
Quoted 19 lines
Quoted 6 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +0
-2@@ -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 |drivers/gpu/drm/bridge/ti-sn65dsi83.c static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) · line 1012
Quoted 10 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +9
-1-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?
Quoted 5 lines
I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84, and the removing
MIPI_DSI_MODE_VIDEO_BURSTseems to help, but I still have no idea why. Should you have any info, maybe from TI, it would be very interesting.
Quoted 4 lines
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 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode
Quoted 59 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 33 lines · tessolveupstream
Quoted 16 lines
Quoted 16 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +16
-0+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 );Quoted 9 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, · line 705
Quoted 5 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +5
-0+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.
Quoted 5 lines
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);
Quoted 7 lines
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.
Quoted 38 lines
Quoted 25 lines
Quoted 19 lines
Quoted 6 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +0
-2@@ -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 |drivers/gpu/drm/bridge/ti-sn65dsi83.c static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) · line 1012
Quoted 10 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +9
-1-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?
Quoted 5 lines
I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84, and the removing
MIPI_DSI_MODE_VIDEO_BURSTseems to help, but I still have no idea why. Should you have any info, maybe from TI, it would be very interesting.Quoted 4 lines
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?
Quoted 8 lines
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:
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?
Quoted 7 lines
Best regards,
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
In reply to Luca CeresoliQuoted 59 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 33 lines · tessolveupstream
Quoted 16 lines
Quoted 16 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +16
-0+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 );Quoted 9 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, · line 705
Quoted 5 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +5
-0+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.
Quoted 5 lines
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);
Quoted 7 lines
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.
Quoted 38 lines
Quoted 25 lines
Quoted 19 lines
Quoted 6 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +0
-2@@ -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 |drivers/gpu/drm/bridge/ti-sn65dsi83.c static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) · line 1012
Quoted 10 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +9
-1-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?
Quoted 5 lines
I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84, and the removing
MIPI_DSI_MODE_VIDEO_BURSTseems to help, but I still have no idea why. Should you have any info, maybe from TI, it would be very interesting.Quoted 4 lines
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?
Quoted 8 lines
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:
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?
Quoted 7 lines
Best regards,
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
Quoted 139 lines · On 06-04-2026 14:05, [email protected] wrote:
Quoted 59 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 33 lines · tessolveupstream
Quoted 16 lines
Quoted 16 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +16
-0+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 );Quoted 9 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, · line 705
Quoted 5 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +5
-0+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.
Quoted 5 lines
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);Quoted 7 lines
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.
Quoted 38 lines
Quoted 25 lines
Quoted 19 lines
Quoted 6 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +0
-2@@ -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 |drivers/gpu/drm/bridge/ti-sn65dsi83.c static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) · line 1012
Quoted 10 lines
drivers/gpu/drm/bridge/ti-sn65dsi83.c +9
-1-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?
Quoted 5 lines
I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84, and the removing
MIPI_DSI_MODE_VIDEO_BURSTseems to help, but I still have no idea why. Should you have any info, maybe from TI, it would be very interesting.Quoted 4 lines
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?
Quoted 8 lines
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: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:
Quoted 9 lines
MIPI_DSI_MODE_VIDEO|MIPI_DSI_MODE_VIDEO_NO_HSA|MIPI_DSI_MODE_NO_EOT_PACKET;From our testing, removing
MIPI_DSI_MODE_VIDEO_BURSTalong 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?
I wanted to revisit the earlier discussion and share a consolidated summary of our observations below.
With your suggested 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/
Working 'dsi-> mode_flags' configuration is:dsi->mode_flags = 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 and NO_HBP flags results in stable LVDS output in dual-link mode.
Also I am sharing an update from our side after consulting the 'dsi-> mode_flags' behavior with the TI expert.
Based on their inputs:
1. The SN65DSI83/84 reconstructs LVDS timing from the incoming DSI stream and requires explicit horizontal blanking (HFP/HBP) to do so reliably.
2. Suppressing HFP/HBP prevents correct timing reconstruction and can result in unstable LVDS output, even when register timings are programmed.
3. DSI burst mode is supported, but depending on the host controller, it may result in non‑continuous DSI clocking and HS/LP transitions.
4. Non‑burst (continuous) DSI video mode provides a more stable and predictable timing stream, which is better suited for LVDS panels.
5. Ensuring continuous DSI video with standard horizontal blanking has been observed to produce stable LVDS operation, particularly in dual‑link configurations.
Given these observations, we would appreciate your guidance on how to proceed with up-streaming.
Quoted 8 lines
Quoted 7 lines
Best regards,
Luca--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Quoted 38 lines · 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 enabledChanges 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 messagesThanks,
Anusha
Quoted 8 lines
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
Quoted 44 lines · Marek Vasut
Quoted 43 lines · 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 enabledChanges 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 messagesThanks,
AnushaSudarshan 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
Quoted 8 lines
Quoted 3 lines
.../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?
Luca Ceresoli
reviewerHello 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:
[...]
Quoted 4 lines
Quoted 4 lines
+CC Luca
You might want to look at recently posted:
Quoted 8 lines
Quoted 1 line
[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/
Quoted 31 lines
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);
Quoted 1 line
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
Quoted 27 lines · 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:
[...]
Quoted 4 lines
Quoted 4 lines
+CC Luca
You might want to look at recently posted:
Quoted 8 lines
Quoted 1 line
[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?
Quoted 6 lines
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.
Quoted 36 lines
Quoted 31 lines
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);Quoted 1 line
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.
Quoted 9 lines
If you display works, good! Let us know (you can also add your Tested-by / Reviewed-by tags to the
test_patternpatch 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.
Quoted 7 lines
Hope this helps,
Luca--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Luca Ceresoli
reviewerHello Sudarshan,
Quoted 24 lines · tessolveupstream
Quoted 17 lines
Quoted 10 lines
Quoted 3 lines
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?
Quoted 6 lines
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/
Quoted 7 lines
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.
Quoted 13 lines
Quoted 12 lines
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_patternpatch 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.
Quoted 4 lines
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
Quoted 65 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 24 lines · tessolveupstream
Quoted 17 lines
Quoted 10 lines
Quoted 3 lines
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?
Quoted 6 lines
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/Quoted 7 lines
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.
Quoted 13 lines
Quoted 12 lines
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_patternpatch 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.
Quoted 4 lines
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.working2. remove your patches, add the 3 I mentioned, and while the display is enabled (but only backlight is working) do
Quoted 7 lines
cat
/sys/kernel/debug/regmap/4-002c/registers>regs.brokenThen 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.
Quoted 6 lines
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Luca Ceresoli
reviewerQuoted 70 lines · tessolveupstream
Quoted 67 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 24 lines · tessolveupstream
Quoted 17 lines
Quoted 10 lines
Quoted 3 lines
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?
Quoted 6 lines
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/Quoted 7 lines
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.
Quoted 13 lines
Quoted 12 lines
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_patternpatch 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.
Quoted 4 lines
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.working2. 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
Quoted 7 lines
Quoted 5 lines
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.
Quoted 2 lines
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
Quoted 106 lines · Luca Ceresoli
Quoted 70 lines · tessolveupstream
Quoted 67 lines · Luca Ceresoli
Hello Sudarshan,
Quoted 24 lines · tessolveupstream
Quoted 17 lines
Quoted 10 lines
Quoted 3 lines
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?
Quoted 6 lines
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/Quoted 7 lines
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.
Quoted 13 lines
Quoted 12 lines
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_patternpatch 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.
Quoted 4 lines
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.working2. 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.brokenQuoted 7 lines
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 8 lines
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?
Quoted 1 line
In the current working configuration, the measured clock frequencies are:DSI_CLK: ~422MHzLVDS_CLK(both A & B Channels): ~70MHz
Quoted 9 lines
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
Am Dienstag, 24. März 2026, 12:00:43 CET schrieb [email protected]:
Quoted 23 lines
[snip]
Quoted 1 line
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 > AboutCHA_DSI_CLK_RANGE: what is your DSI clock?Quoted 1 line
Quoted 6 lines
In the current working configuration, the measured clock frequencies are:
DSI_CLK: ~422MHzLVDS_CLK(both A & B Channels): ~70MHzQuoted 2 lines
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/[email protected]/
Signature · 4 lines
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/
Quoted 28 lines · Alexander Stein
Am Dienstag, 24. März 2026, 12:00:43 CET schrieb [email protected]:
Quoted 27 lines
[snip]
Quoted 1 line
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 > AboutCHA_DSI_CLK_RANGE: what is your DSI clock?Quoted 1 line
In the current working configuration, the measured clock frequencies are:
DSI_CLK: ~422MHzLVDS_CLK(both A & B Channels): ~70MHz
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
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->LVDSbridge 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/[email protected]/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?
Quoted 4 lines
Best regards,
Alexander
Am Mittwoch, 25. März 2026, 07:09:07 CET schrieb [email protected]:
Quoted 43 lines · Alexander Stein
Quoted 28 lines
Am Dienstag, 24. März 2026, 12:00:43 CET schrieb [email protected]:
Quoted 27 lines
[snip]
Quoted 1 line
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 > AboutCHA_DSI_CLK_RANGE: what is your DSI clock?Quoted 1 line
In the current working configuration, the measured clock frequencies are:
DSI_CLK: ~422MHzLVDS_CLK(both A & B Channels): ~70MHzQuoted 7 lines
Quoted 2 lines
Quoted 2 lines
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->LVDSbridge 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:
Quoted 7 lines
- SoC: QCS615
- Bridge: TI SN65DSI84 (DSI to dual-link LVDS)
- Panel: AUO G133HAN01I am currently using the following DT overlay:
(talos-evk-lvds-auo,g133han01.dtso)
https://lore.kernel.org/all/[email protected]/T/#m00e90e7ff95915bbdb21dbd786c232526e3360a2
I don't know your SoC, but at a first glance the DT looks okay.
Quoted 3 lines
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
Signature · 4 lines
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/