From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4158E1067045 for ; Thu, 12 Mar 2026 15:47:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 873D310EA56; Thu, 12 Mar 2026 15:47:41 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.b="z1CgqqrH"; dkim-atps=neutral Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) by gabe.freedesktop.org (Postfix) with ESMTPS id E469F10EA56 for ; Thu, 12 Mar 2026 15:47:39 +0000 (UTC) Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 875E1C415AB; Thu, 12 Mar 2026 15:48:00 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id BE9836001B; Thu, 12 Mar 2026 15:47:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id BD33E10369581; Thu, 12 Mar 2026 16:47:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1773330457; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=PT5kIaEDNi9/vOuV4B9O1BBff9a0zdlhj//IW73rDP4=; b=z1CgqqrHXgfJP3ikQMvIN1lXwJbF31afdY/+Bs/ZevuP6M9m67f4KsjjAeI/8A50sXWq7U KFoAmiQyuKj/b8IiSUmqirkt6AB0o8e2/e7bi/i1QDD/Sz3bh08eKCOCxQt+a7SBLgAsac vvf5XEBWeYBQSYJH+1RmcwFN6p4QXusRJ30dM0u/JrcQnb2o0T9ShOvtTcl4y7Tb2EceM5 a6jiVhah/32vREcm7yTMRdwoEvxQL9pSn86Q/MnMN7XtfPCjtPAakPa2aBbHtcmwNzqFCz ntZTuBcahSQ5ulqTgUf/+aaK99ggPSxfi6paY6e7QLk/xzTr0dqWV3cq6LgL/g== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 12 Mar 2026 16:47:33 +0100 Message-Id: From: "Luca Ceresoli" Subject: Re: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode Cc: , , , , , , , , , , , , , , , , To: "Sudarshan Shetty" , , , X-Mailer: aerc 0.20.1 References: <20260312043743.261475-1-tessolveupstream@gmail.com> <20260312043743.261475-3-tessolveupstream@gmail.com> In-Reply-To: <20260312043743.261475-3-tessolveupstream@gmail.com> X-Last-TLS-Session-Version: TLSv1.3 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hello Sudarshan, On Thu Mar 12, 2026 at 5:37 AM CET, Sudarshan Shetty wrote: > Some LVDS panels operating in dual-link mode require adjusted > horizontal timing parameters when programmed into the SN65DSI84 > bridge. According to TI documentation, horizontal timing values > must be divided by two when operating in dual-link mode. Without > this adjustment, the panel may fail to display or produce corrupted > output. > > Add support for an optional DT property "ti,dual-link-video-mode" > to enable configuration required for dual-link LVDS operation. > These settings ensure correct LVDS output for panels that require > this mode of operation. > > Signed-off-by: Sudarshan Shetty > --- > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 52 ++++++++++++++++++++++++--- > 1 file changed, 48 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/brid= ge/ti-sn65dsi83.c > index f6736b4457bb..9b7d35487bd8 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > @@ -164,6 +164,7 @@ struct sn65dsi83 { > int irq; > struct delayed_work monitor_work; > struct work_struct reset_work; > + bool dual_link_video_mode; As said in the reply to patch 1, there is already 'bool lvds_dual_link' carrying the same info. > static const struct regmap_range sn65dsi83_readable_ranges[] =3D { > @@ -667,8 +668,43 @@ static void sn65dsi83_atomic_pre_enable(struct drm_b= ridge *bridge, > mode->hsync_start - mode->hdisplay); > regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH, > mode->vsync_start - mode->vdisplay); > - regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00); > > + /* > + * In dual-link LVDS mode, the SN65DSI84 requires the horizontal > + * timing parameters to be adjusted before being programmed into > + * the device. According to TI documentation, the horizontal timing > + * values must be divided by two when operating in dual-link mode. > + * Without this adjustment, the connected panel may fail to light up > + * or display corrupted output. > + * > + * TI also provides recommended register settings for this mode, > + * which were derived using the TI DSI-Tuner tool. When the optional > + * DT property "ti,dual-link-video-mode" is present, apply these > + * configuration settings to ensure correct dual-link LVDS operation. > + */ > + 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. > + > + regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00); > /* Enable PLL */ > regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN); > usleep_range(3000, 4000); > @@ -965,9 +1001,15 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *= ctx) > > dsi->lanes =3D dsi_lanes; > dsi->format =3D MIPI_DSI_FMT_RGB888; > - dsi->mode_flags =3D 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 =3D MIPI_DSI_MODE_VIDEO; > + else > + dsi->mode_flags =3D 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. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com