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

[tessolveupstream@gmail.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