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

["Luca Ceresoli" <luca.ceresoli@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