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

[tessolveupstream]

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@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/
 
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