.../bindings/display/bridge/ti,sn65dsi83.yaml | 9 ++++ drivers/gpu/drm/bridge/ti-sn65dsi83.c | 52 +++++++++++++++++-- 2 files changed, 57 insertions(+), 4 deletions(-)
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
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
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?
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
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
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
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
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
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
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/
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/
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/
© 2016 - 2026 Red Hat, Inc.