[PATCH v3] drm/bridge: ti-sn65dsi83: two fixes + add test pattern

[PATCH v3] drm/bridge: ti-sn65dsi83: two fixes + add test pattern

[Luca Ceresoli]

This series used to have two bug fixes, now applied to drm-misc-fixes, and
a patch adding support for enabling the test pattern output from userspace,
which is now at v3.

Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v3:
- Fix incorrect halving in single-link mode
- Link to v2: https://patch.msgid.link/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-0-e6aaa7e1d181@bootlin.com

Changes in v2:
- Removed patches now on drm-misc-fixes
- Fixes potential inconsistend values in the test_pattern patch
- Link to v1: https://lore.kernel.org/r/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-0-2e15f5a9a6a0@bootlin.com

---
Luca Ceresoli (1):
      drm/bridge: ti-sn65dsi83: add test pattern generation support

 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
---
base-commit: 126c50bc2fb6ddfe5b7718de67bbd7592a1062bb
change-id: 20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-f5ff67e1900c

Best regards,
--  
Luca Ceresoli <luca.ceresoli@bootlin.com>

[PATCH v3] drm/bridge: ti-sn65dsi83: add test pattern generation support

[Luca Ceresoli]

Generation of a test pattern output is a useful tool for panel bringup and
debugging, and very simple to support with this chip.

The value of REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW needs to be divided by two
for the test pattern to work in dual LVDS mode. While not clearly stated in
the datasheet, this is needed according to the DSI Tuner [0] output. And
some dual-LVDS panels refuse to show any picture without this division by
two.

[0] https://www.ti.com/tool/DSI-TUNER

Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

---

Changes in v3:
 - fixed incorrect halving of hdisplay in single-link mode

Changes in v2:
 - added local variable to avoid potential race condition leading to
   inconsistent settings
---
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 17a885244e1e..2b6f6a54edb7 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -114,6 +114,7 @@
 #define REG_VID_CHA_HORIZONTAL_FRONT_PORCH	0x38
 #define REG_VID_CHA_VERTICAL_FRONT_PORCH	0x3a
 #define REG_VID_CHA_TEST_PATTERN		0x3c
+#define  REG_VID_CHA_TEST_PATTERN_EN		BIT(4)
 /* IRQ registers */
 #define REG_IRQ_GLOBAL				0xe0
 #define  REG_IRQ_GLOBAL_IRQ_EN			BIT(0)
@@ -134,6 +135,9 @@
 #define  REG_IRQ_STAT_CHA_SOT_BIT_ERR		BIT(2)
 #define  REG_IRQ_STAT_CHA_PLL_UNLOCK		BIT(0)
 
+static bool sn65dsi83_test_pattern;
+module_param_named(test_pattern, sn65dsi83_test_pattern, bool, 0644);
+
 enum sn65dsi83_channel {
 	CHANNEL_A,
 	CHANNEL_B
@@ -523,6 +527,7 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
 	const struct drm_display_mode *mode;
 	struct drm_connector *connector;
 	struct drm_crtc *crtc;
+	bool test_pattern = sn65dsi83_test_pattern;
 	bool lvds_format_24bpp;
 	bool lvds_format_jeida;
 	unsigned int pval;
@@ -645,7 +650,11 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
 			  REG_LVDS_LANE_CHB_LVDS_TERM : 0));
 	regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
 
-	le16val = cpu_to_le16(mode->hdisplay);
+	/*
+	 * Active line length needs to be halved for test pattern
+	 * generation in dual LVDS output.
+	 */
+	le16val = cpu_to_le16(mode->hdisplay / (test_pattern ? dual_factor : 1));
 	regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
 			  &le16val, 2);
 	le16val = cpu_to_le16(mode->vdisplay);
@@ -668,7 +677,8 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
 		     (mode->hsync_start - mode->hdisplay) / dual_factor);
 	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);
+	regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN,
+		     test_pattern ? REG_VID_CHA_TEST_PATTERN_EN : 0);
 
 	/* Enable PLL */
 	regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);

-- 
2.53.0

Re: [PATCH v3] drm/bridge: ti-sn65dsi83: add test pattern generation support

[Louis Chauvet]

On 4/16/26 15:59, Luca Ceresoli wrote:
> Generation of a test pattern output is a useful tool for panel bringup and
> debugging, and very simple to support with this chip.
> 
> The value of REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW needs to be divided by two
> for the test pattern to work in dual LVDS mode. While not clearly stated in
> the datasheet, this is needed according to the DSI Tuner [0] output. And
> some dual-LVDS panels refuse to show any picture without this division by
> two.
> 
> [0] https://www.ti.com/tool/DSI-TUNER
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> 

Reviewed-by: Louis Chauvet <louis.chauvet@boootlin.com>

> ---
> 
> Changes in v3:
>   - fixed incorrect halving of hdisplay in single-link mode
> 
> Changes in v2:
>   - added local variable to avoid potential race condition leading to
>     inconsistent settings
> ---
>   drivers/gpu/drm/bridge/ti-sn65dsi83.c | 14 ++++++++++++--
>   1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index 17a885244e1e..2b6f6a54edb7 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -114,6 +114,7 @@
>   #define REG_VID_CHA_HORIZONTAL_FRONT_PORCH	0x38
>   #define REG_VID_CHA_VERTICAL_FRONT_PORCH	0x3a
>   #define REG_VID_CHA_TEST_PATTERN		0x3c
> +#define  REG_VID_CHA_TEST_PATTERN_EN		BIT(4)
>   /* IRQ registers */
>   #define REG_IRQ_GLOBAL				0xe0
>   #define  REG_IRQ_GLOBAL_IRQ_EN			BIT(0)
> @@ -134,6 +135,9 @@
>   #define  REG_IRQ_STAT_CHA_SOT_BIT_ERR		BIT(2)
>   #define  REG_IRQ_STAT_CHA_PLL_UNLOCK		BIT(0)
>   
> +static bool sn65dsi83_test_pattern;
> +module_param_named(test_pattern, sn65dsi83_test_pattern, bool, 0644);
> +
>   enum sn65dsi83_channel {
>   	CHANNEL_A,
>   	CHANNEL_B
> @@ -523,6 +527,7 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
>   	const struct drm_display_mode *mode;
>   	struct drm_connector *connector;
>   	struct drm_crtc *crtc;
> +	bool test_pattern = sn65dsi83_test_pattern;
>   	bool lvds_format_24bpp;
>   	bool lvds_format_jeida;
>   	unsigned int pval;
> @@ -645,7 +650,11 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
>   			  REG_LVDS_LANE_CHB_LVDS_TERM : 0));
>   	regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
>   
> -	le16val = cpu_to_le16(mode->hdisplay);
> +	/*
> +	 * Active line length needs to be halved for test pattern
> +	 * generation in dual LVDS output.
> +	 */
> +	le16val = cpu_to_le16(mode->hdisplay / (test_pattern ? dual_factor : 1));
>   	regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
>   			  &le16val, 2);
>   	le16val = cpu_to_le16(mode->vdisplay);
> @@ -668,7 +677,8 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
>   		     (mode->hsync_start - mode->hdisplay) / dual_factor);
>   	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);
> +	regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN,
> +		     test_pattern ? REG_VID_CHA_TEST_PATTERN_EN : 0);
>   
>   	/* Enable PLL */
>   	regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
> 

Re: [PATCH v3] drm/bridge: ti-sn65dsi83: two fixes + add test pattern

[Dmitry Baryshkov]

On Thu, Apr 16, 2026 at 03:59:54PM +0200, Luca Ceresoli wrote:
> This series used to have two bug fixes, now applied to drm-misc-fixes, and
> a patch adding support for enabling the test pattern output from userspace,
> which is now at v3.

We really need a generic interface for TPGs...

> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> Changes in v3:
> - Fix incorrect halving in single-link mode
> - Link to v2: https://patch.msgid.link/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-0-e6aaa7e1d181@bootlin.com
> 
> Changes in v2:
> - Removed patches now on drm-misc-fixes
> - Fixes potential inconsistend values in the test_pattern patch
> - Link to v1: https://lore.kernel.org/r/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-0-2e15f5a9a6a0@bootlin.com
> 
> ---
> Luca Ceresoli (1):
>       drm/bridge: ti-sn65dsi83: add test pattern generation support
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> ---
> base-commit: 126c50bc2fb6ddfe5b7718de67bbd7592a1062bb
> change-id: 20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-f5ff67e1900c
> 
> Best regards,
> --  
> Luca Ceresoli <luca.ceresoli@bootlin.com>
> 

-- 
With best wishes
Dmitry

Re: [PATCH v3] drm/bridge: ti-sn65dsi83: two fixes + add test pattern

[Luca Ceresoli]

Hi Dmitry,

On Wed Apr 22, 2026 at 9:40 PM CEST, Dmitry Baryshkov wrote:
> On Thu, Apr 16, 2026 at 03:59:54PM +0200, Luca Ceresoli wrote:
>> This series used to have two bug fixes, now applied to drm-misc-fixes, and
>> a patch adding support for enabling the test pattern output from userspace,
>> which is now at v3.
>
> We really need a generic interface for TPGs...

I agree on the general principle, but where could this interface be placed?
Bridges are not exposed to user space. They are somewhat visible in debugfs
but even there there's no per-bridge file or directory.

Luca

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

Re: [PATCH v3] drm/bridge: ti-sn65dsi83: two fixes + add test pattern

[Dmitry Baryshkov]

On Thu, 23 Apr 2026 at 10:36, Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
>
> Hi Dmitry,
>
> On Wed Apr 22, 2026 at 9:40 PM CEST, Dmitry Baryshkov wrote:
> > On Thu, Apr 16, 2026 at 03:59:54PM +0200, Luca Ceresoli wrote:
> >> This series used to have two bug fixes, now applied to drm-misc-fixes, and
> >> a patch adding support for enabling the test pattern output from userspace,
> >> which is now at v3.
> >
> > We really need a generic interface for TPGs...
>
> I agree on the general principle, but where could this interface be placed?
> Bridges are not exposed to user space. They are somewhat visible in debugfs
> but even there there's no per-bridge file or directory.

I'd say it should be a part of the encoder. They are exported to
userspace via debugfs. Probably we can have a "tpg" file listing all
possible "test" sources and then accepting the one to generate the
pattern (there can be many TPG sources in the bridge chain + one in
the encoder itself). But it's more of a generic rant, don't let it
stop this series.

-- 
With best wishes
Dmitry