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

From: tessolveupstream

Date: Tue Mar 24 2026 - 07:01:00 EST

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@xxxxxxxxxxx/
>>>>> - https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@xxxxxxxxxxx/
>>>>> - https://lore.kernel.org/lkml/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-1-e6aaa7e1d181@xxxxxxxxxxx/
>>>>>
>>>>
>>>> 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