Re: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode

tessolveupstream
2026-04-06T08:35:48Z

On 18-03-2026 14:22, Luca Ceresoli wrote:
> Hello Sudarshan,
>
> On Wed Mar 18, 2026 at 6:53 AM CET, tessolveupstream wrote:
>>>> + 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);
>>>> + }
>>>
>>> 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?
>
> 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.
>

Thank you so much for your suggestion.

>>>> @@ -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;
>>>
>>> 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.
>>>
>>
>> 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?
>

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:

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/

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?

> Best regards,
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com