[PATCH v1 0/6] drm/tegra: Add support for Tegra20/Tegra30 8-bit CPU interface

[PATCH v1 0/6] drm/tegra: Add support for Tegra20/Tegra30 8-bit CPU interface

[Svyatoslav Ryhel]

The display controller in Tegra20/30 SoCs features an 8-bit SPI interface
that closely resembles the MIPI DBI Type B protocol and is referred to as
'8-bit CPU'.

Add DC parametrization options needed for fine tuning by bridges.
Add 8-bit CPU interface in form of a bridge linking to RGB port.
Add 2 DBI Type B panels used in LG Optimus 2X which work with
the 8-bit CPU interface.

Svyatoslav Ryhel (6):
  drm/tegra: dc: Expand available registers layouts
  drm/tegra: rgb: Parameterize configuration based on bus flags
  dt-bindings: display: tegra: Document 8-bit CPU parallel interface
  drm/tegra: Add support for 8-bit CPU interface
  dt-bindings: display: panel: Document Hitachi TX10D07VM0BAA and LG
    LH400WV3 panels
  drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI
    panel driver

 .../display/panel/hit,tx10d07vm0baa.yaml      |  55 +++
 .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++
 drivers/gpu/drm/panel/Kconfig                 |  14 +
 drivers/gpu/drm/panel/Makefile                |   1 +
 .../drm/panel/panel-hitachi-tx10d07vm0baa.c   | 396 ++++++++++++++++
 drivers/gpu/drm/tegra/Kconfig                 |   7 +
 drivers/gpu/drm/tegra/Makefile                |   1 +
 drivers/gpu/drm/tegra/cpu-bridge.c            | 427 ++++++++++++++++++
 drivers/gpu/drm/tegra/dc.c                    |   3 +-
 drivers/gpu/drm/tegra/dc.h                    |  54 ++-
 drivers/gpu/drm/tegra/rgb.c                   |  36 +-
 11 files changed, 1121 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/panel/hit,tx10d07vm0baa.yaml
 create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
 create mode 100644 drivers/gpu/drm/tegra/cpu-bridge.c

-- 
2.53.0

[PATCH v1 1/6] drm/tegra: dc: Expand available registers layouts

[Svyatoslav Ryhel]

Expand existing DC register definitions with additional fields in
preparation for adding the 8-bit CPU interface.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 drivers/gpu/drm/tegra/dc.c |  3 ++-
 drivers/gpu/drm/tegra/dc.h | 54 ++++++++++++++++++++++++++++++++++----
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b0bfa946e6979..5c67928bcabfa 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2384,7 +2384,8 @@ static void tegra_crtc_atomic_enable(struct drm_crtc *crtc,
 
 	if (dc->rgb) {
 		/* XXX: parameterize? */
-		value = SC0_H_QUALIFIER_NONE | SC1_H_QUALIFIER_NONE;
+		value = SC0_H_QUALIFIER(SC_H_QUALIFIER_NONE) |
+			SC1_H_QUALIFIER(SC_H_QUALIFIER_NONE);
 		tegra_dc_writel(dc, value, DC_DISP_SHIFT_CLOCK_OPTIONS);
 	}
 
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 0cb0515968b35..5679e1ca0c2a5 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -274,8 +274,11 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
 #define DC_COM_CRC_CHECKSUM			0x301
 #define DC_COM_PIN_OUTPUT_ENABLE(x) (0x302 + (x))
 #define DC_COM_PIN_OUTPUT_POLARITY(x) (0x306 + (x))
+#define LSC0_OUTPUT_POLARITY_LOW BIT(24)
 #define LVS_OUTPUT_POLARITY_LOW (1 << 28)
 #define LHS_OUTPUT_POLARITY_LOW (1 << 30)
+#define LSPI_OUTPUT_POLARITY_LOW BIT(8)
+#define LDC_OUTPUT_SELECT_V_PULSE1 BIT(14)
 #define DC_COM_PIN_OUTPUT_DATA(x) (0x30a + (x))
 #define DC_COM_PIN_INPUT_ENABLE(x) (0x30e + (x))
 #define DC_COM_PIN_INPUT_DATA(x) (0x312 + (x))
@@ -303,9 +306,15 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
 #define  UNDERFLOW_REPORT_ENABLE (1 << 0)
 
 #define DC_DISP_DISP_SIGNAL_OPTIONS0		0x400
-#define H_PULSE0_ENABLE (1 <<  8)
-#define H_PULSE1_ENABLE (1 << 10)
-#define H_PULSE2_ENABLE (1 << 12)
+#define H_PULSE0_ENABLE				BIT(8)
+#define H_PULSE1_ENABLE				BIT(10)
+#define H_PULSE2_ENABLE				BIT(12)
+#define V_PULSE0_ENABLE				BIT(16)
+#define V_PULSE1_ENABLE				BIT(18)
+#define V_PULSE2_ENABLE				BIT(19)
+#define V_PULSE3_ENABLE				BIT(20)
+#define M0_ENABLE				BIT(24)
+#define M1_ENABLE				BIT(26)
 
 #define DC_DISP_DISP_SIGNAL_OPTIONS1		0x401
 
@@ -451,11 +460,30 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
 #define BASE_COLOR_SIZE_888    (  8 << 0)
 #define BASE_COLOR_SIZE_101010 ( 10 << 0)
 #define BASE_COLOR_SIZE_121212 ( 12 << 0)
+#define DISP_COLOR_SWAP_BGR	BIT(16)
 #define CMU_ENABLE_ENABLE      (1 << 20)
 
 #define DC_DISP_SHIFT_CLOCK_OPTIONS		0x431
-#define  SC1_H_QUALIFIER_NONE	(1 << 16)
-#define  SC0_H_QUALIFIER_NONE	(1 <<  0)
+#define SC0_H_QUALIFIER(x)			(((x) & 0x7) <<  0)
+#define SC1_H_QUALIFIER(x)			(((x) & 0x7) << 16)
+enum {
+	SC_H_QUALIFIER_DISABLE,
+	SC_H_QUALIFIER_NONE,
+	SC_H_QUALIFIER_HACTIVE,
+	SC_H_QUALIFIER_EXT_HACTIVE,
+	SC_H_QUALIFIER_HPULSE,
+	SC_H_QUALIFIER_EXT_HPULSE,
+};
+#define SC0_V_QUALIFIER(x)			(((x) & 0x7) <<  3)
+#define SC1_V_QUALIFIER(x)			(((x) & 0x7) <<  19)
+enum {
+	SC_V_QUALIFIER_NONE,
+	SC_V_QUALIFIER_RSVD,
+	SC_V_QUALIFIER_VACTIVE,
+	SC_V_QUALIFIER_EXT_VACTIVE,
+	SC_V_QUALIFIER_VPULSE,
+	SC_V_QUALIFIER_EXT_VPULSE,
+};
 
 #define DC_DISP_DATA_ENABLE_OPTIONS		0x432
 #define DE_SELECT_ACTIVE_BLANK  (0 << 0)
@@ -493,6 +521,22 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
 #define DC_DISP_CURSOR_POSITION_NS		0x441
 
 #define DC_DISP_INIT_SEQ_CONTROL		0x442
+#define SEND_INIT_SEQUENCE			BIT(0)
+#define INIT_SEQUENCE_MODE_SPI			BIT(1)
+#define INIT_SEQUENCE_MODE_PLCD			0x0
+#define INIT_SEQ_DC_SIGNAL_SHIFT		4
+#define INIT_SEQ_DC_SIGNAL_MASK			(0x7 << INIT_SEQ_DC_SIGNAL_SHIFT)
+enum {
+	NO_DC_SIGNAL,
+	DC_SIGNAL_VSYNC,
+	DC_SIGNAL_VPULSE0,
+	DC_SIGNAL_VPULSE1,
+	DC_SIGNAL_VPULSE2,
+	DC_SIGNAL_VPULSE3,
+};
+#define INIT_SEQ_DC_CONTROL_SHIFT		7
+#define FRAME_INIT_SEQ_CYCLES_SHIFT		8
+
 #define DC_DISP_SPI_INIT_SEQ_DATA_A		0x443
 #define DC_DISP_SPI_INIT_SEQ_DATA_B		0x444
 #define DC_DISP_SPI_INIT_SEQ_DATA_C		0x445
-- 
2.53.0

Re: [PATCH v1 1/6] drm/tegra: dc: Expand available registers layouts

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3346 bytes --]

On Wed, Sep 30, 2026 at 10:05:30AM +0300, Svyatoslav Ryhel wrote:
> Expand existing DC register definitions with additional fields in
> preparation for adding the 8-bit CPU interface.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  drivers/gpu/drm/tegra/dc.c |  3 ++-
>  drivers/gpu/drm/tegra/dc.h | 54 ++++++++++++++++++++++++++++++++++----
>  2 files changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index b0bfa946e6979..5c67928bcabfa 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -2384,7 +2384,8 @@ static void tegra_crtc_atomic_enable(struct drm_crtc *crtc,
>  
>  	if (dc->rgb) {
>  		/* XXX: parameterize? */
> -		value = SC0_H_QUALIFIER_NONE | SC1_H_QUALIFIER_NONE;
> +		value = SC0_H_QUALIFIER(SC_H_QUALIFIER_NONE) |
> +			SC1_H_QUALIFIER(SC_H_QUALIFIER_NONE);
>  		tegra_dc_writel(dc, value, DC_DISP_SHIFT_CLOCK_OPTIONS);
>  	}
>  
> diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
> index 0cb0515968b35..5679e1ca0c2a5 100644
> --- a/drivers/gpu/drm/tegra/dc.h
> +++ b/drivers/gpu/drm/tegra/dc.h
> @@ -274,8 +274,11 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
>  #define DC_COM_CRC_CHECKSUM			0x301
>  #define DC_COM_PIN_OUTPUT_ENABLE(x) (0x302 + (x))
>  #define DC_COM_PIN_OUTPUT_POLARITY(x) (0x306 + (x))
> +#define LSC0_OUTPUT_POLARITY_LOW BIT(24)
>  #define LVS_OUTPUT_POLARITY_LOW (1 << 28)
>  #define LHS_OUTPUT_POLARITY_LOW (1 << 30)
> +#define LSPI_OUTPUT_POLARITY_LOW BIT(8)
> +#define LDC_OUTPUT_SELECT_V_PULSE1 BIT(14)
>  #define DC_COM_PIN_OUTPUT_DATA(x) (0x30a + (x))
>  #define DC_COM_PIN_INPUT_ENABLE(x) (0x30e + (x))
>  #define DC_COM_PIN_INPUT_DATA(x) (0x312 + (x))
> @@ -303,9 +306,15 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
>  #define  UNDERFLOW_REPORT_ENABLE (1 << 0)
>  
>  #define DC_DISP_DISP_SIGNAL_OPTIONS0		0x400
> -#define H_PULSE0_ENABLE (1 <<  8)
> -#define H_PULSE1_ENABLE (1 << 10)
> -#define H_PULSE2_ENABLE (1 << 12)
> +#define H_PULSE0_ENABLE				BIT(8)
> +#define H_PULSE1_ENABLE				BIT(10)
> +#define H_PULSE2_ENABLE				BIT(12)
> +#define V_PULSE0_ENABLE				BIT(16)
> +#define V_PULSE1_ENABLE				BIT(18)
> +#define V_PULSE2_ENABLE				BIT(19)
> +#define V_PULSE3_ENABLE				BIT(20)
> +#define M0_ENABLE				BIT(24)
> +#define M1_ENABLE				BIT(26)
>  
>  #define DC_DISP_DISP_SIGNAL_OPTIONS1		0x401
>  
> @@ -451,11 +460,30 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
>  #define BASE_COLOR_SIZE_888    (  8 << 0)
>  #define BASE_COLOR_SIZE_101010 ( 10 << 0)
>  #define BASE_COLOR_SIZE_121212 ( 12 << 0)
> +#define DISP_COLOR_SWAP_BGR	BIT(16)
>  #define CMU_ENABLE_ENABLE      (1 << 20)
>  
>  #define DC_DISP_SHIFT_CLOCK_OPTIONS		0x431
> -#define  SC1_H_QUALIFIER_NONE	(1 << 16)
> -#define  SC0_H_QUALIFIER_NONE	(1 <<  0)
> +#define SC0_H_QUALIFIER(x)			(((x) & 0x7) <<  0)
> +#define SC1_H_QUALIFIER(x)			(((x) & 0x7) << 16)
> +enum {
> +	SC_H_QUALIFIER_DISABLE,
> +	SC_H_QUALIFIER_NONE,
> +	SC_H_QUALIFIER_HACTIVE,
> +	SC_H_QUALIFIER_EXT_HACTIVE,
> +	SC_H_QUALIFIER_HPULSE,
> +	SC_H_QUALIFIER_EXT_HPULSE,
> +};

Let's stick with regular defines for this, there's really no advantage
in using enums for this and the other enums introduced by this patch.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 1/6] drm/tegra: dc: Expand available registers layouts

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 11:35 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 10:05:30AM +0300, Svyatoslav Ryhel wrote:
> > Expand existing DC register definitions with additional fields in
> > preparation for adding the 8-bit CPU interface.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  drivers/gpu/drm/tegra/dc.c |  3 ++-
> >  drivers/gpu/drm/tegra/dc.h | 54 ++++++++++++++++++++++++++++++++++----
> >  2 files changed, 51 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index b0bfa946e6979..5c67928bcabfa 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -2384,7 +2384,8 @@ static void tegra_crtc_atomic_enable(struct drm_crtc *crtc,
> >
> >       if (dc->rgb) {
> >               /* XXX: parameterize? */
> > -             value = SC0_H_QUALIFIER_NONE | SC1_H_QUALIFIER_NONE;
> > +             value = SC0_H_QUALIFIER(SC_H_QUALIFIER_NONE) |
> > +                     SC1_H_QUALIFIER(SC_H_QUALIFIER_NONE);
> >               tegra_dc_writel(dc, value, DC_DISP_SHIFT_CLOCK_OPTIONS);
> >       }
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
> > index 0cb0515968b35..5679e1ca0c2a5 100644
> > --- a/drivers/gpu/drm/tegra/dc.h
> > +++ b/drivers/gpu/drm/tegra/dc.h
> > @@ -274,8 +274,11 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
> >  #define DC_COM_CRC_CHECKSUM                  0x301
> >  #define DC_COM_PIN_OUTPUT_ENABLE(x) (0x302 + (x))
> >  #define DC_COM_PIN_OUTPUT_POLARITY(x) (0x306 + (x))
> > +#define LSC0_OUTPUT_POLARITY_LOW BIT(24)
> >  #define LVS_OUTPUT_POLARITY_LOW (1 << 28)
> >  #define LHS_OUTPUT_POLARITY_LOW (1 << 30)
> > +#define LSPI_OUTPUT_POLARITY_LOW BIT(8)
> > +#define LDC_OUTPUT_SELECT_V_PULSE1 BIT(14)
> >  #define DC_COM_PIN_OUTPUT_DATA(x) (0x30a + (x))
> >  #define DC_COM_PIN_INPUT_ENABLE(x) (0x30e + (x))
> >  #define DC_COM_PIN_INPUT_DATA(x) (0x312 + (x))
> > @@ -303,9 +306,15 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
> >  #define  UNDERFLOW_REPORT_ENABLE (1 << 0)
> >
> >  #define DC_DISP_DISP_SIGNAL_OPTIONS0         0x400
> > -#define H_PULSE0_ENABLE (1 <<  8)
> > -#define H_PULSE1_ENABLE (1 << 10)
> > -#define H_PULSE2_ENABLE (1 << 12)
> > +#define H_PULSE0_ENABLE                              BIT(8)
> > +#define H_PULSE1_ENABLE                              BIT(10)
> > +#define H_PULSE2_ENABLE                              BIT(12)
> > +#define V_PULSE0_ENABLE                              BIT(16)
> > +#define V_PULSE1_ENABLE                              BIT(18)
> > +#define V_PULSE2_ENABLE                              BIT(19)
> > +#define V_PULSE3_ENABLE                              BIT(20)
> > +#define M0_ENABLE                            BIT(24)
> > +#define M1_ENABLE                            BIT(26)
> >
> >  #define DC_DISP_DISP_SIGNAL_OPTIONS1         0x401
> >
> > @@ -451,11 +460,30 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
> >  #define BASE_COLOR_SIZE_888    (  8 << 0)
> >  #define BASE_COLOR_SIZE_101010 ( 10 << 0)
> >  #define BASE_COLOR_SIZE_121212 ( 12 << 0)
> > +#define DISP_COLOR_SWAP_BGR  BIT(16)
> >  #define CMU_ENABLE_ENABLE      (1 << 20)
> >
> >  #define DC_DISP_SHIFT_CLOCK_OPTIONS          0x431
> > -#define  SC1_H_QUALIFIER_NONE        (1 << 16)
> > -#define  SC0_H_QUALIFIER_NONE        (1 <<  0)
> > +#define SC0_H_QUALIFIER(x)                   (((x) & 0x7) <<  0)
> > +#define SC1_H_QUALIFIER(x)                   (((x) & 0x7) << 16)
> > +enum {
> > +     SC_H_QUALIFIER_DISABLE,
> > +     SC_H_QUALIFIER_NONE,
> > +     SC_H_QUALIFIER_HACTIVE,
> > +     SC_H_QUALIFIER_EXT_HACTIVE,
> > +     SC_H_QUALIFIER_HPULSE,
> > +     SC_H_QUALIFIER_EXT_HPULSE,
> > +};
>
> Let's stick with regular defines for this, there's really no advantage
> in using enums for this and the other enums introduced by this patch.
>

Alright, noted. Thanks.

> Thierry

[PATCH v1 2/6] drm/tegra: rgb: Parameterize configuration based on bus flags

[Svyatoslav Ryhel]

Parameterize configuration based on bus flags passed from the bridge or
panel. The list of supported flags includes now pixel clock polarity,
display enable (DE) polarity, and data alignment.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 drivers/gpu/drm/tegra/rgb.c | 36 +++++++++++++++++++++++++++++++-----
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index bc1c93c7554c5..e72e076b13d5f 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -5,6 +5,7 @@
  */
 
 #include <linux/clk.h>
+#include <linux/media-bus-format.h>
 #include <linux/of.h>
 
 #include <drm/drm_atomic_helper.h>
@@ -103,14 +104,19 @@ static void tegra_rgb_encoder_enable(struct drm_encoder *encoder)
 	struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
 	struct tegra_output *output = encoder_to_output(encoder);
 	struct tegra_rgb *rgb = to_rgb(output);
-	u32 value;
+	struct drm_bridge_state *bridge_state;
+	u32 bus_flags, value;
+
+	/* Get but flags from the bridge state. */
+	bridge_state = drm_bridge_get_current_state(output->bridge);
+	bus_flags = bridge_state->input_bus_cfg.flags;
 
 	tegra_dc_write_regs(rgb->dc, rgb_enable, ARRAY_SIZE(rgb_enable));
 
 	value = DE_SELECT_ACTIVE | DE_CONTROL_NORMAL;
 	tegra_dc_writel(rgb->dc, value, DC_DISP_DATA_ENABLE_OPTIONS);
 
-	/* configure H- and V-sync signal polarities */
+	/* configure H- and V-sync and pixel clock signal polarities */
 	value = tegra_dc_readl(rgb->dc, DC_COM_PIN_OUTPUT_POLARITY(1));
 
 	if (mode->flags & DRM_MODE_FLAG_NHSYNC)
@@ -123,11 +129,31 @@ static void tegra_rgb_encoder_enable(struct drm_encoder *encoder)
 	else
 		value &= ~LVS_OUTPUT_POLARITY_LOW;
 
+	if (bus_flags & DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE)
+		value |= LSC0_OUTPUT_POLARITY_LOW;
+	else
+		value &= ~LSC0_OUTPUT_POLARITY_LOW;
+
 	tegra_dc_writel(rgb->dc, value, DC_COM_PIN_OUTPUT_POLARITY(1));
 
-	/* XXX: parameterize? */
-	value = DISP_DATA_FORMAT_DF1P1C | DISP_ALIGNMENT_MSB |
-		DISP_ORDER_RED_BLUE;
+	/* configure DE signal polarities */
+	value = tegra_dc_readl(rgb->dc, DC_COM_PIN_OUTPUT_POLARITY(3));
+
+	if (bus_flags & DRM_BUS_FLAG_DE_LOW)
+		value |= LSPI_OUTPUT_POLARITY_LOW;
+	else
+		value &= ~LSPI_OUTPUT_POLARITY_LOW;
+
+	tegra_dc_writel(rgb->dc, value, DC_COM_PIN_OUTPUT_POLARITY(3));
+
+	/* configure DATA order and alignment */
+	value = DISP_DATA_FORMAT_DF1P1C | DISP_ORDER_RED_BLUE;
+
+	if (bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
+		value |= DISP_ALIGNMENT_LSB;
+	else
+		value &= ~DISP_ALIGNMENT_LSB;
+
 	tegra_dc_writel(rgb->dc, value, DC_DISP_DISP_INTERFACE_CONTROL);
 
 	tegra_dc_commit(rgb->dc);
-- 
2.53.0

[PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

Document 8-bit CPU parallel MIPI DBI Type B interface provided by
Tegra20/30 SoCs display controller.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
 1 file changed, 138 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml

diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
new file mode 100644
index 0000000000000..f0dab608b2936
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nvidia Tegra DC based MIPI DBI Type B bridge
+
+maintainers:
+  - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description: The display controller in Tegra20/30 SoCs features an
+  8-bit SPI interface that closely resembles the MIPI DBI Type B
+  protocol and is referred to as '8-bit CPU'. Each display controller
+  provides two such interfaces, which can be used to send MIPI DCS
+  commands to initialize and control the panel while image data is
+  transmitted via 16/18/24-line RGB.
+
+properties:
+  compatible:
+    const: nvidia,tegra-8bit-cpu
+
+  dc-gpios:
+    description: Data/command selection pin.
+    maxItems: 1
+
+  rw-gpios:
+    description: Read/write pin.
+    maxItems: 1
+
+  cs-gpios:
+    description: Chip select pin.
+    maxItems: 1
+
+  data-gpios:
+    description: Specifies a set of 8 gpio pins used to transfer data.
+    minItems: 8
+    maxItems: 8
+
+  nvidia,init-sequence:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description: Device specific set of values used in DC DISP_SPI_INIT_SEQ
+      registers.
+    minItems: 4
+    maxItems: 4
+
+  panel:
+    type: object
+    description: Node of supported panel driven by the bridge.
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/$defs/port-base
+        unevaluatedProperties: false
+        description: Video port for RGB input.
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            unevaluatedProperties: false
+
+            properties:
+              bus-width:
+                enum: [ 16, 18, 24 ]
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for DBI output (panel or connector).
+
+    required:
+      - port@0
+      - port@1
+
+required:
+  - compatible
+  - ports
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    dbi-bridge {
+        compatible = "nvidia,tegra-8bit-cpu";
+
+        dc-gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+        rw-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
+        cs-gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
+
+        data-gpios = <&gpio 32 GPIO_ACTIVE_HIGH>, <&gpio 33 GPIO_ACTIVE_HIGH>,
+                     <&gpio 34 GPIO_ACTIVE_HIGH>, <&gpio 35 GPIO_ACTIVE_HIGH>,
+                     <&gpio 36 GPIO_ACTIVE_HIGH>, <&gpio 37 GPIO_ACTIVE_HIGH>,
+                     <&gpio 38 GPIO_ACTIVE_HIGH>, <&gpio 39 GPIO_ACTIVE_HIGH>;
+
+        nvidia,init-sequence = <0x0000002c 0x0 0x0 0x00005000>;
+
+        panel {
+            compatible = "hit,tx10d07vm0baa";
+
+            reset-gpios = <&gpio 175 GPIO_ACTIVE_LOW>;
+
+            avci-supply = <&vcc_2v8_lcd>;
+            iovcc-supply = <&iovcc_1v8_lcd>;
+
+            backlight = <&backlight>;
+
+            port {
+                panel_input: endpoint {
+                    remote-endpoint = <&bridge_output>;
+                };
+            };
+        };
+
+        ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            port@0 {
+                reg = <0>;
+
+                bridge_input: endpoint {
+                    remote-endpoint = <&dpi_output>;
+                };
+            };
+
+            port@1 {
+                reg = <1>;
+
+                bridge_output: endpoint {
+                    remote-endpoint = <&panel_input>;
+                };
+            };
+        };
+    };
-- 
2.53.0

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> Tegra20/30 SoCs display controller.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
>  1 file changed, 138 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> new file mode 100644
> index 0000000000000..f0dab608b2936
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> @@ -0,0 +1,138 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> +
> +maintainers:
> +  - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description: The display controller in Tegra20/30 SoCs features an
> +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> +  protocol and is referred to as '8-bit CPU'. Each display controller
> +  provides two such interfaces, which can be used to send MIPI DCS
> +  commands to initialize and control the panel while image data is
> +  transmitted via 16/18/24-line RGB.
> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra-8bit-cpu

The description says that this is a feature of the display controller,
so adding a new binding and compatible string for this is not the right
move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
need to extend that with whatever is new.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 11:47 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > Tegra20/30 SoCs display controller.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> >  1 file changed, 138 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > new file mode 100644
> > index 0000000000000..f0dab608b2936
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > @@ -0,0 +1,138 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > +
> > +maintainers:
> > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description: The display controller in Tegra20/30 SoCs features an
> > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > +  provides two such interfaces, which can be used to send MIPI DCS
> > +  commands to initialize and control the panel while image data is
> > +  transmitted via 16/18/24-line RGB.
> > +
> > +properties:
> > +  compatible:
> > +    const: nvidia,tegra-8bit-cpu
>
> The description says that this is a feature of the display controller,
> so adding a new binding and compatible string for this is not the right
> move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
> need to extend that with whatever is new.
>

How would you model it? I have tried to model 8bit-cpu as a bridge, similar
to how DSI bridges are modeled. This reflects interface used to link RGB and
panel, without inflating existing DC binding. If you have any ideas in modelling
this, I am open to any suggestions.

> Thierry

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

On Wed, Sep 30, 2026 at 12:00:21PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 11:47 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > Tegra20/30 SoCs display controller.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > >  1 file changed, 138 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > new file mode 100644
> > > index 0000000000000..f0dab608b2936
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > @@ -0,0 +1,138 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > +
> > > +maintainers:
> > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +description: The display controller in Tegra20/30 SoCs features an
> > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > +  commands to initialize and control the panel while image data is
> > > +  transmitted via 16/18/24-line RGB.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: nvidia,tegra-8bit-cpu
> >
> > The description says that this is a feature of the display controller,
> > so adding a new binding and compatible string for this is not the right
> > move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
> > need to extend that with whatever is new.
> >
> 
> How would you model it? I have tried to model 8bit-cpu as a bridge, similar
> to how DSI bridges are modeled. This reflects interface used to link RGB and
> panel, without inflating existing DC binding. If you have any ideas in modelling
> this, I am open to any suggestions.

My suggestion is to integrate this into the existing "rgb" node, or, if
that becomes too convoluted, a separate "lcd" node (or "dbi", whatever).

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 13:34 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 12:00:21PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 11:47 Thierry Reding <thierry.reding@kernel.org> пише:
> > >
> > > On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > Tegra20/30 SoCs display controller.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > >  1 file changed, 138 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > new file mode 100644
> > > > index 0000000000000..f0dab608b2936
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > @@ -0,0 +1,138 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > +
> > > > +maintainers:
> > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > +
> > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > +  commands to initialize and control the panel while image data is
> > > > +  transmitted via 16/18/24-line RGB.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: nvidia,tegra-8bit-cpu
> > >
> > > The description says that this is a feature of the display controller,
> > > so adding a new binding and compatible string for this is not the right
> > > move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
> > > need to extend that with whatever is new.
> > >
> >
> > How would you model it? I have tried to model 8bit-cpu as a bridge, similar
> > to how DSI bridges are modeled. This reflects interface used to link RGB and
> > panel, without inflating existing DC binding. If you have any ideas in modelling
> > this, I am open to any suggestions.
>
> My suggestion is to integrate this into the existing "rgb" node, or, if

Not an option since it is not clean RGB and there will be no way to
distinguish RGB from 8bit-CPU.

> that becomes too convoluted, a separate "lcd" node (or "dbi", whatever).

This is fine by me but nesting nodes without compatible feels weird. Oh well.

dc {
  compatible = "...";
  rgb {
    dbi {
      ...
    };
  };
};

>
> Thierry

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3913 bytes --]

On Wed, Sep 30, 2026 at 01:42:17PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 13:34 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 12:00:21PM +0300, Svyatoslav Ryhel wrote:
> > > ср, 30 вер. 2026 р. о 11:47 Thierry Reding <thierry.reding@kernel.org> пише:
> > > >
> > > > On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > Tegra20/30 SoCs display controller.
> > > > >
> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > ---
> > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > >  1 file changed, 138 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > new file mode 100644
> > > > > index 0000000000000..f0dab608b2936
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > @@ -0,0 +1,138 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > +
> > > > > +maintainers:
> > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > +
> > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > +  commands to initialize and control the panel while image data is
> > > > > +  transmitted via 16/18/24-line RGB.
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    const: nvidia,tegra-8bit-cpu
> > > >
> > > > The description says that this is a feature of the display controller,
> > > > so adding a new binding and compatible string for this is not the right
> > > > move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
> > > > need to extend that with whatever is new.
> > > >
> > >
> > > How would you model it? I have tried to model 8bit-cpu as a bridge, similar
> > > to how DSI bridges are modeled. This reflects interface used to link RGB and
> > > panel, without inflating existing DC binding. If you have any ideas in modelling
> > > this, I am open to any suggestions.
> >
> > My suggestion is to integrate this into the existing "rgb" node, or, if
> 
> Not an option since it is not clean RGB and there will be no way to
> distinguish RGB from 8bit-CPU.
> 
> > that becomes too convoluted, a separate "lcd" node (or "dbi", whatever).
> 
> This is fine by me but nesting nodes without compatible feels weird. Oh well.
> 
> dc {
>   compatible = "...";
>   rgb {
>     dbi {
>       ...
>     };
>   };
> };

That's one option, but there's also many other ways you could
differentiate between RGB and DBI. Could be a simple "nvidia,interface"
property in the "rgb" node (that defaults to RGB if absent). It could
also be a node that is a sibling to "rgb" (rather than a child). Or the
child could work, too.

Ultimately we're still describing aspects of the display controller here
since this is all registers within the display controller's MMIO region.
Nested nodes are purely for adding some logical structure for the
description that makes sense.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 13:54 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 01:42:17PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 13:34 Thierry Reding <thierry.reding@kernel.org> пише:
> > >
> > > On Wed, Sep 30, 2026 at 12:00:21PM +0300, Svyatoslav Ryhel wrote:
> > > > ср, 30 вер. 2026 р. о 11:47 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > >
> > > > > On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> > > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > > Tegra20/30 SoCs display controller.
> > > > > >
> > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > ---
> > > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > > >  1 file changed, 138 insertions(+)
> > > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > new file mode 100644
> > > > > > index 0000000000000..f0dab608b2936
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > @@ -0,0 +1,138 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > +
> > > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > > +  commands to initialize and control the panel while image data is
> > > > > > +  transmitted via 16/18/24-line RGB.
> > > > > > +
> > > > > > +properties:
> > > > > > +  compatible:
> > > > > > +    const: nvidia,tegra-8bit-cpu
> > > > >
> > > > > The description says that this is a feature of the display controller,
> > > > > so adding a new binding and compatible string for this is not the right
> > > > > move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
> > > > > need to extend that with whatever is new.
> > > > >
> > > >
> > > > How would you model it? I have tried to model 8bit-cpu as a bridge, similar
> > > > to how DSI bridges are modeled. This reflects interface used to link RGB and
> > > > panel, without inflating existing DC binding. If you have any ideas in modelling
> > > > this, I am open to any suggestions.
> > >
> > > My suggestion is to integrate this into the existing "rgb" node, or, if
> >
> > Not an option since it is not clean RGB and there will be no way to
> > distinguish RGB from 8bit-CPU.
> >
> > > that becomes too convoluted, a separate "lcd" node (or "dbi", whatever).
> >
> > This is fine by me but nesting nodes without compatible feels weird. Oh well.
> >
> > dc {
> >   compatible = "...";
> >   rgb {
> >     dbi {
> >       ...
> >     };
> >   };
> > };
>
> That's one option, but there's also many other ways you could
> differentiate between RGB and DBI. Could be a simple "nvidia,interface"
> property in the "rgb" node (that defaults to RGB if absent). It could
> also be a node that is a sibling to "rgb" (rather than a child). Or the
> child could work, too.
>
> Ultimately we're still describing aspects of the display controller here
> since this is all registers within the display controller's MMIO region.
> Nested nodes are purely for adding some logical structure for the
> description that makes sense.
>

From my understanding data is sent basically as RGB, at least RGB
configuration is still used in downstream. Panel commands are sent via
DBI

dc {
   compatible = "...";

   rgb {
    port...
   };

   dbi {
      ...
   };
};

This would work nicely if DBI is modeled using bridge framework. I
would strongly insist on keeping it as a stand-alone configuration
separated from RGB and DC.

> Thierry

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5075 bytes --]

On Wed, Sep 30, 2026 at 02:10:15PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 13:54 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 01:42:17PM +0300, Svyatoslav Ryhel wrote:
> > > ср, 30 вер. 2026 р. о 13:34 Thierry Reding <thierry.reding@kernel.org> пише:
> > > >
> > > > On Wed, Sep 30, 2026 at 12:00:21PM +0300, Svyatoslav Ryhel wrote:
> > > > > ср, 30 вер. 2026 р. о 11:47 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > > >
> > > > > > On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> > > > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > > > Tegra20/30 SoCs display controller.
> > > > > > >
> > > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > ---
> > > > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > > > >  1 file changed, 138 insertions(+)
> > > > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > new file mode 100644
> > > > > > > index 0000000000000..f0dab608b2936
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > @@ -0,0 +1,138 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > +
> > > > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > > > +  commands to initialize and control the panel while image data is
> > > > > > > +  transmitted via 16/18/24-line RGB.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > +  compatible:
> > > > > > > +    const: nvidia,tegra-8bit-cpu
> > > > > >
> > > > > > The description says that this is a feature of the display controller,
> > > > > > so adding a new binding and compatible string for this is not the right
> > > > > > move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
> > > > > > need to extend that with whatever is new.
> > > > > >
> > > > >
> > > > > How would you model it? I have tried to model 8bit-cpu as a bridge, similar
> > > > > to how DSI bridges are modeled. This reflects interface used to link RGB and
> > > > > panel, without inflating existing DC binding. If you have any ideas in modelling
> > > > > this, I am open to any suggestions.
> > > >
> > > > My suggestion is to integrate this into the existing "rgb" node, or, if
> > >
> > > Not an option since it is not clean RGB and there will be no way to
> > > distinguish RGB from 8bit-CPU.
> > >
> > > > that becomes too convoluted, a separate "lcd" node (or "dbi", whatever).
> > >
> > > This is fine by me but nesting nodes without compatible feels weird. Oh well.
> > >
> > > dc {
> > >   compatible = "...";
> > >   rgb {
> > >     dbi {
> > >       ...
> > >     };
> > >   };
> > > };
> >
> > That's one option, but there's also many other ways you could
> > differentiate between RGB and DBI. Could be a simple "nvidia,interface"
> > property in the "rgb" node (that defaults to RGB if absent). It could
> > also be a node that is a sibling to "rgb" (rather than a child). Or the
> > child could work, too.
> >
> > Ultimately we're still describing aspects of the display controller here
> > since this is all registers within the display controller's MMIO region.
> > Nested nodes are purely for adding some logical structure for the
> > description that makes sense.
> >
> 
> From my understanding data is sent basically as RGB, at least RGB
> configuration is still used in downstream. Panel commands are sent via
> DBI
> 
> dc {
>    compatible = "...";
> 
>    rgb {
>     port...
>    };
> 
>    dbi {
>       ...
>    };
> };
> 
> This would work nicely if DBI is modeled using bridge framework. I
> would strongly insist on keeping it as a stand-alone configuration
> separated from RGB and DC.

Okay, maybe give that a try then. But to clarify: this should all be
part of the Tegra DC driver and not need an extra compatible string or
separate driver. The DC itself should be able to function as a bridge.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 14:41 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 02:10:15PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 13:54 Thierry Reding <thierry.reding@kernel.org> пише:
> > >
> > > On Wed, Sep 30, 2026 at 01:42:17PM +0300, Svyatoslav Ryhel wrote:
> > > > ср, 30 вер. 2026 р. о 13:34 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > >
> > > > > On Wed, Sep 30, 2026 at 12:00:21PM +0300, Svyatoslav Ryhel wrote:
> > > > > > ср, 30 вер. 2026 р. о 11:47 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > > > >
> > > > > > > On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> > > > > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > > > > Tegra20/30 SoCs display controller.
> > > > > > > >
> > > > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > > ---
> > > > > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > > > > >  1 file changed, 138 insertions(+)
> > > > > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > >
> > > > > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > > new file mode 100644
> > > > > > > > index 0000000000000..f0dab608b2936
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > > @@ -0,0 +1,138 @@
> > > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > > +%YAML 1.2
> > > > > > > > +---
> > > > > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > +
> > > > > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > > > > +
> > > > > > > > +maintainers:
> > > > > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > > +
> > > > > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > > > > +  commands to initialize and control the panel while image data is
> > > > > > > > +  transmitted via 16/18/24-line RGB.
> > > > > > > > +
> > > > > > > > +properties:
> > > > > > > > +  compatible:
> > > > > > > > +    const: nvidia,tegra-8bit-cpu
> > > > > > >
> > > > > > > The description says that this is a feature of the display controller,
> > > > > > > so adding a new binding and compatible string for this is not the right
> > > > > > > move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
> > > > > > > need to extend that with whatever is new.
> > > > > > >
> > > > > >
> > > > > > How would you model it? I have tried to model 8bit-cpu as a bridge, similar
> > > > > > to how DSI bridges are modeled. This reflects interface used to link RGB and
> > > > > > panel, without inflating existing DC binding. If you have any ideas in modelling
> > > > > > this, I am open to any suggestions.
> > > > >
> > > > > My suggestion is to integrate this into the existing "rgb" node, or, if
> > > >
> > > > Not an option since it is not clean RGB and there will be no way to
> > > > distinguish RGB from 8bit-CPU.
> > > >
> > > > > that becomes too convoluted, a separate "lcd" node (or "dbi", whatever).
> > > >
> > > > This is fine by me but nesting nodes without compatible feels weird. Oh well.
> > > >
> > > > dc {
> > > >   compatible = "...";
> > > >   rgb {
> > > >     dbi {
> > > >       ...
> > > >     };
> > > >   };
> > > > };
> > >
> > > That's one option, but there's also many other ways you could
> > > differentiate between RGB and DBI. Could be a simple "nvidia,interface"
> > > property in the "rgb" node (that defaults to RGB if absent). It could
> > > also be a node that is a sibling to "rgb" (rather than a child). Or the
> > > child could work, too.
> > >
> > > Ultimately we're still describing aspects of the display controller here
> > > since this is all registers within the display controller's MMIO region.
> > > Nested nodes are purely for adding some logical structure for the
> > > description that makes sense.
> > >
> >
> > From my understanding data is sent basically as RGB, at least RGB
> > configuration is still used in downstream. Panel commands are sent via
> > DBI
> >
> > dc {
> >    compatible = "...";
> >
> >    rgb {
> >     port...
> >    };
> >
> >    dbi {
> >       ...
> >    };
> > };
> >
> > This would work nicely if DBI is modeled using bridge framework. I
> > would strongly insist on keeping it as a stand-alone configuration
> > separated from RGB and DC.
>
> Okay, maybe give that a try then. But to clarify: this should all be
> part of the Tegra DC driver and not need an extra compatible string or
> separate driver. The DC itself should be able to function as a bridge.

Noted, I will not add compatible string to the dbi node.

>
> Thierry

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Mikko Perttunen]

On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> Tegra20/30 SoCs display controller.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
>  1 file changed, 138 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> new file mode 100644
> index 0000000000000..f0dab608b2936
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> @@ -0,0 +1,138 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> +
> +maintainers:
> +  - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description: The display controller in Tegra20/30 SoCs features an
> +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> +  protocol and is referred to as '8-bit CPU'. Each display controller
> +  provides two such interfaces, which can be used to send MIPI DCS
> +  commands to initialize and control the panel while image data is
> +  transmitted via 16/18/24-line RGB.
> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra-8bit-cpu
> +
> +  dc-gpios:
> +    description: Data/command selection pin.
> +    maxItems: 1
> +
> +  rw-gpios:
> +    description: Read/write pin.
> +    maxItems: 1
> +
> +  cs-gpios:
> +    description: Chip select pin.
> +    maxItems: 1
> +
> +  data-gpios:
> +    description: Specifies a set of 8 gpio pins used to transfer data.
> +    minItems: 8
> +    maxItems: 8

Based on my admittedly brief research, according to the TRM the display 
controller can drive all of these pins - of which there are two fixed 
sets as you mention - directly. So we'd need to describe which interface 
the display is connected to in DT, but not any GPIOs (which they really 
aren't).

> +
> +  nvidia,init-sequence:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description: Device specific set of values used in DC DISP_SPI_INIT_SEQ
> +      registers.
> +    minItems: 4
> +    maxItems: 4

And AIUI this is panel-specific DBI commands the display controller will 
transmit. So ideally the display driver should receive this data from 
the panel driver.

Thank you
Mikko

> +
> +  panel:
> +    type: object
> +    description: Node of supported panel driven by the bridge.
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: Video port for RGB input.
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            unevaluatedProperties: false
> +
> +            properties:
> +              bus-width:
> +                enum: [ 16, 18, 24 ]
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for DBI output (panel or connector).
> +
> +    required:
> +      - port@0
> +      - port@1
> +
> +required:
> +  - compatible
> +  - ports
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    dbi-bridge {
> +        compatible = "nvidia,tegra-8bit-cpu";
> +
> +        dc-gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
> +        rw-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
> +        cs-gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
> +
> +        data-gpios = <&gpio 32 GPIO_ACTIVE_HIGH>, <&gpio 33 GPIO_ACTIVE_HIGH>,
> +                     <&gpio 34 GPIO_ACTIVE_HIGH>, <&gpio 35 GPIO_ACTIVE_HIGH>,
> +                     <&gpio 36 GPIO_ACTIVE_HIGH>, <&gpio 37 GPIO_ACTIVE_HIGH>,
> +                     <&gpio 38 GPIO_ACTIVE_HIGH>, <&gpio 39 GPIO_ACTIVE_HIGH>;
> +
> +        nvidia,init-sequence = <0x0000002c 0x0 0x0 0x00005000>;
> +
> +        panel {
> +            compatible = "hit,tx10d07vm0baa";
> +
> +            reset-gpios = <&gpio 175 GPIO_ACTIVE_LOW>;
> +
> +            avci-supply = <&vcc_2v8_lcd>;
> +            iovcc-supply = <&iovcc_1v8_lcd>;
> +
> +            backlight = <&backlight>;
> +
> +            port {
> +                panel_input: endpoint {
> +                    remote-endpoint = <&bridge_output>;
> +                };
> +            };
> +        };
> +
> +        ports {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            port@0 {
> +                reg = <0>;
> +
> +                bridge_input: endpoint {
> +                    remote-endpoint = <&dpi_output>;
> +                };
> +            };
> +
> +            port@1 {
> +                reg = <1>;
> +
> +                bridge_output: endpoint {
> +                    remote-endpoint = <&panel_input>;
> +                };
> +            };
> +        };
> +    };
> -- 
> 2.53.0
> 
> 

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@nvidia.com> пише:
>
> On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > Tegra20/30 SoCs display controller.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> >  1 file changed, 138 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > new file mode 100644
> > index 0000000000000..f0dab608b2936
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > @@ -0,0 +1,138 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > +
> > +maintainers:
> > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description: The display controller in Tegra20/30 SoCs features an
> > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > +  provides two such interfaces, which can be used to send MIPI DCS
> > +  commands to initialize and control the panel while image data is
> > +  transmitted via 16/18/24-line RGB.
> > +
> > +properties:
> > +  compatible:
> > +    const: nvidia,tegra-8bit-cpu
> > +
> > +  dc-gpios:
> > +    description: Data/command selection pin.
> > +    maxItems: 1
> > +
> > +  rw-gpios:
> > +    description: Read/write pin.
> > +    maxItems: 1
> > +
> > +  cs-gpios:
> > +    description: Chip select pin.
> > +    maxItems: 1
> > +
> > +  data-gpios:
> > +    description: Specifies a set of 8 gpio pins used to transfer data.
> > +    minItems: 8
> > +    maxItems: 8
>
> Based on my admittedly brief research, according to the TRM the display
> controller can drive all of these pins - of which there are two fixed
> sets as you mention - directly. So we'd need to describe which interface
> the display is connected to in DT, but not any GPIOs (which they really
> aren't).
>

I am perfectly fine to not expose any gpios in the binding, if this is
preferred. Only question, which method of interface checking would be
preferred. I assume if primary then nothing, if secondary - boolean
prop "nvidia,secondary"? Feel free to share your vision.

> > +
> > +  nvidia,init-sequence:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    description: Device specific set of values used in DC DISP_SPI_INIT_SEQ
> > +      registers.
> > +    minItems: 4
> > +    maxItems: 4
>
> And AIUI this is panel-specific DBI commands the display controller will
> transmit. So ideally the display driver should receive this data from
> the panel driver.
>

This is not panel driver data, but it is panel or maybe even more
interface itself specific. TRM has no clear method of generation of
this seq I am aware of. Maybe I have missed smth. These 4 entries
co-respond to DC_DISP_SPI_INIT_SEQ_DATA_A_0,
DC_DISP_SPI_INIT_SEQ_DATA_B_0, DC_DISP_SPI_INIT_SEQ_DATA_C_0 and
DC_DISP_SPI_INIT_SEQ_DATA_D_0 registers of DC. Maybe you have some
info to shed some light onto method of generation of this seq. Then it
could be simply removed from binding and calculated internally. Thank
you!

> Thank you
> Mikko
>

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5110 bytes --]

On Wed, Sep 30, 2026 at 12:52:18PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@nvidia.com> пише:
> >
> > On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > Tegra20/30 SoCs display controller.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > >  1 file changed, 138 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > new file mode 100644
> > > index 0000000000000..f0dab608b2936
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > @@ -0,0 +1,138 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > +
> > > +maintainers:
> > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +description: The display controller in Tegra20/30 SoCs features an
> > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > +  commands to initialize and control the panel while image data is
> > > +  transmitted via 16/18/24-line RGB.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: nvidia,tegra-8bit-cpu
> > > +
> > > +  dc-gpios:
> > > +    description: Data/command selection pin.
> > > +    maxItems: 1
> > > +
> > > +  rw-gpios:
> > > +    description: Read/write pin.
> > > +    maxItems: 1
> > > +
> > > +  cs-gpios:
> > > +    description: Chip select pin.
> > > +    maxItems: 1
> > > +
> > > +  data-gpios:
> > > +    description: Specifies a set of 8 gpio pins used to transfer data.
> > > +    minItems: 8
> > > +    maxItems: 8
> >
> > Based on my admittedly brief research, according to the TRM the display
> > controller can drive all of these pins - of which there are two fixed
> > sets as you mention - directly. So we'd need to describe which interface
> > the display is connected to in DT, but not any GPIOs (which they really
> > aren't).
> >
> 
> I am perfectly fine to not expose any gpios in the binding, if this is
> preferred. Only question, which method of interface checking would be
> preferred. I assume if primary then nothing, if secondary - boolean
> prop "nvidia,secondary"? Feel free to share your vision.

The driver currently uses the GPIOs to program DBI commands, so I
suspect we do need some way of controlling those pins. Or is there a way
to have the display controller program the pins and send commands? That
would be much preferred because it would more accurately reflect the HW
design and possibly also simplify the driver because it doesn't need to
parse the GPIOs and then also not use the GPIO API to set the values.

As for selecting the interface to use, it could probably be just a
simple, single-cell value with two valid values. That's a bit clearer
than a boolean, because with a boolean you need to explicitly document
what happens when it is absent.

> > > +
> > > +  nvidia,init-sequence:
> > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > +    description: Device specific set of values used in DC DISP_SPI_INIT_SEQ
> > > +      registers.
> > > +    minItems: 4
> > > +    maxItems: 4
> >
> > And AIUI this is panel-specific DBI commands the display controller will
> > transmit. So ideally the display driver should receive this data from
> > the panel driver.
> >
> 
> This is not panel driver data, but it is panel or maybe even more
> interface itself specific. TRM has no clear method of generation of
> this seq I am aware of. Maybe I have missed smth. These 4 entries
> co-respond to DC_DISP_SPI_INIT_SEQ_DATA_A_0,
> DC_DISP_SPI_INIT_SEQ_DATA_B_0, DC_DISP_SPI_INIT_SEQ_DATA_C_0 and
> DC_DISP_SPI_INIT_SEQ_DATA_D_0 registers of DC. Maybe you have some
> info to shed some light onto method of generation of this seq. Then it
> could be simply removed from binding and calculated internally. Thank
> you!

Even if this is interface-specific data, it is still defined by the
panel that's being used, right?

As such it'd make sense to integrate it into the panel driver and have
some side-channel to feed it to the display controller. If there's no
good standard way of doing so, having the display controller read it
from the panel node and programming it at the appropriate time could
work, too.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 13:50 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 12:52:18PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@nvidia.com> пише:
> > >
> > > On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > Tegra20/30 SoCs display controller.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > >  1 file changed, 138 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > new file mode 100644
> > > > index 0000000000000..f0dab608b2936
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > @@ -0,0 +1,138 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > +
> > > > +maintainers:
> > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > +
> > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > +  commands to initialize and control the panel while image data is
> > > > +  transmitted via 16/18/24-line RGB.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: nvidia,tegra-8bit-cpu
> > > > +
> > > > +  dc-gpios:
> > > > +    description: Data/command selection pin.
> > > > +    maxItems: 1
> > > > +
> > > > +  rw-gpios:
> > > > +    description: Read/write pin.
> > > > +    maxItems: 1
> > > > +
> > > > +  cs-gpios:
> > > > +    description: Chip select pin.
> > > > +    maxItems: 1
> > > > +
> > > > +  data-gpios:
> > > > +    description: Specifies a set of 8 gpio pins used to transfer data.
> > > > +    minItems: 8
> > > > +    maxItems: 8
> > >
> > > Based on my admittedly brief research, according to the TRM the display
> > > controller can drive all of these pins - of which there are two fixed
> > > sets as you mention - directly. So we'd need to describe which interface
> > > the display is connected to in DT, but not any GPIOs (which they really
> > > aren't).
> > >
> >
> > I am perfectly fine to not expose any gpios in the binding, if this is
> > preferred. Only question, which method of interface checking would be
> > preferred. I assume if primary then nothing, if secondary - boolean
> > prop "nvidia,secondary"? Feel free to share your vision.
>
> The driver currently uses the GPIOs to program DBI commands, so I
> suspect we do need some way of controlling those pins. Or is there a way
> to have the display controller program the pins and send commands? That
> would be much preferred because it would more accurately reflect the HW
> design and possibly also simplify the driver because it doesn't need to
> parse the GPIOs and then also not use the GPIO API to set the values.
>

From what I know, GPIOs must be used and freed after use. Sets of
GPIOs are defined and remain fixed for primary and secondary
interface.

> As for selecting the interface to use, it could probably be just a
> simple, single-cell value with two valid values. That's a bit clearer
> than a boolean, because with a boolean you need to explicitly document
> what happens when it is absent.
>

I can describe boolean too, but if you want set it like "nvidia,head".
Fine by me.

> > > > +
> > > > +  nvidia,init-sequence:
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > +    description: Device specific set of values used in DC DISP_SPI_INIT_SEQ
> > > > +      registers.
> > > > +    minItems: 4
> > > > +    maxItems: 4
> > >
> > > And AIUI this is panel-specific DBI commands the display controller will
> > > transmit. So ideally the display driver should receive this data from
> > > the panel driver.
> > >
> >
> > This is not panel driver data, but it is panel or maybe even more
> > interface itself specific. TRM has no clear method of generation of
> > this seq I am aware of. Maybe I have missed smth. These 4 entries
> > co-respond to DC_DISP_SPI_INIT_SEQ_DATA_A_0,
> > DC_DISP_SPI_INIT_SEQ_DATA_B_0, DC_DISP_SPI_INIT_SEQ_DATA_C_0 and
> > DC_DISP_SPI_INIT_SEQ_DATA_D_0 registers of DC. Maybe you have some
> > info to shed some light onto method of generation of this seq. Then it
> > could be simply removed from binding and calculated internally. Thank
> > you!
>
> Even if this is interface-specific data, it is still defined by the
> panel that's being used, right?
>
> As such it'd make sense to integrate it into the panel driver and have
> some side-channel to feed it to the display controller. If there's no
> good standard way of doing so, having the display controller read it
> from the panel node and programming it at the appropriate time could
> work, too.
>
> Thierry

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5035 bytes --]

On Wed, Sep 30, 2026 at 01:56:40PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 13:50 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 12:52:18PM +0300, Svyatoslav Ryhel wrote:
> > > ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@nvidia.com> пише:
> > > >
> > > > On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > Tegra20/30 SoCs display controller.
> > > > >
> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > ---
> > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > >  1 file changed, 138 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > new file mode 100644
> > > > > index 0000000000000..f0dab608b2936
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > @@ -0,0 +1,138 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > +
> > > > > +maintainers:
> > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > +
> > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > +  commands to initialize and control the panel while image data is
> > > > > +  transmitted via 16/18/24-line RGB.
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    const: nvidia,tegra-8bit-cpu
> > > > > +
> > > > > +  dc-gpios:
> > > > > +    description: Data/command selection pin.
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  rw-gpios:
> > > > > +    description: Read/write pin.
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  cs-gpios:
> > > > > +    description: Chip select pin.
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  data-gpios:
> > > > > +    description: Specifies a set of 8 gpio pins used to transfer data.
> > > > > +    minItems: 8
> > > > > +    maxItems: 8
> > > >
> > > > Based on my admittedly brief research, according to the TRM the display
> > > > controller can drive all of these pins - of which there are two fixed
> > > > sets as you mention - directly. So we'd need to describe which interface
> > > > the display is connected to in DT, but not any GPIOs (which they really
> > > > aren't).
> > > >
> > >
> > > I am perfectly fine to not expose any gpios in the binding, if this is
> > > preferred. Only question, which method of interface checking would be
> > > preferred. I assume if primary then nothing, if secondary - boolean
> > > prop "nvidia,secondary"? Feel free to share your vision.
> >
> > The driver currently uses the GPIOs to program DBI commands, so I
> > suspect we do need some way of controlling those pins. Or is there a way
> > to have the display controller program the pins and send commands? That
> > would be much preferred because it would more accurately reflect the HW
> > design and possibly also simplify the driver because it doesn't need to
> > parse the GPIOs and then also not use the GPIO API to set the values.
> >
> 
> From what I know, GPIOs must be used and freed after use. Sets of
> GPIOs are defined and remain fixed for primary and secondary
> interface.

So you're saying that we need the GPIO handling in the RGB/DBI driver to
prevent anyone else from using these GPIOs and potentially messing with
the DBI communication?

It feels like there should be a better mechanism for that than requiring
the DC driver to request all the GPIOs. Maybe these should be excluded
from the range of valid GPIOs?

We can make sure that device tree isn't going to use these on a given
platform, but there's still the risk of users grabbing them via sysfs or
the chardev API.

> > As for selecting the interface to use, it could probably be just a
> > simple, single-cell value with two valid values. That's a bit clearer
> > than a boolean, because with a boolean you need to explicitly document
> > what happens when it is absent.
> >
> 
> I can describe boolean too, but if you want set it like "nvidia,head".
> Fine by me.

Yeah, I'd prefer it to be explicit which mode of operation is selected.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 14:46 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 01:56:40PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 13:50 Thierry Reding <thierry.reding@kernel.org> пише:
> > >
> > > On Wed, Sep 30, 2026 at 12:52:18PM +0300, Svyatoslav Ryhel wrote:
> > > > ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@nvidia.com> пише:
> > > > >
> > > > > On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> > > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > > Tegra20/30 SoCs display controller.
> > > > > >
> > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > ---
> > > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > > >  1 file changed, 138 insertions(+)
> > > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > new file mode 100644
> > > > > > index 0000000000000..f0dab608b2936
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > @@ -0,0 +1,138 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > +
> > > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > > +  commands to initialize and control the panel while image data is
> > > > > > +  transmitted via 16/18/24-line RGB.
> > > > > > +
> > > > > > +properties:
> > > > > > +  compatible:
> > > > > > +    const: nvidia,tegra-8bit-cpu
> > > > > > +
> > > > > > +  dc-gpios:
> > > > > > +    description: Data/command selection pin.
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  rw-gpios:
> > > > > > +    description: Read/write pin.
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  cs-gpios:
> > > > > > +    description: Chip select pin.
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  data-gpios:
> > > > > > +    description: Specifies a set of 8 gpio pins used to transfer data.
> > > > > > +    minItems: 8
> > > > > > +    maxItems: 8
> > > > >
> > > > > Based on my admittedly brief research, according to the TRM the display
> > > > > controller can drive all of these pins - of which there are two fixed
> > > > > sets as you mention - directly. So we'd need to describe which interface
> > > > > the display is connected to in DT, but not any GPIOs (which they really
> > > > > aren't).
> > > > >
> > > >
> > > > I am perfectly fine to not expose any gpios in the binding, if this is
> > > > preferred. Only question, which method of interface checking would be
> > > > preferred. I assume if primary then nothing, if secondary - boolean
> > > > prop "nvidia,secondary"? Feel free to share your vision.
> > >
> > > The driver currently uses the GPIOs to program DBI commands, so I
> > > suspect we do need some way of controlling those pins. Or is there a way
> > > to have the display controller program the pins and send commands? That
> > > would be much preferred because it would more accurately reflect the HW
> > > design and possibly also simplify the driver because it doesn't need to
> > > parse the GPIOs and then also not use the GPIO API to set the values.
> > >
> >
> > From what I know, GPIOs must be used and freed after use. Sets of
> > GPIOs are defined and remain fixed for primary and secondary
> > interface.
>
> So you're saying that we need the GPIO handling in the RGB/DBI driver to
> prevent anyone else from using these GPIOs and potentially messing with
> the DBI communication?
>

No, gpios are used for dbi communcation while their sfio versions are
used to transfer RGB data. So there is no risk in external
intereference.

> It feels like there should be a better mechanism for that than requiring
> the DC driver to request all the GPIOs. Maybe these should be excluded
> from the range of valid GPIOs?
>

NO! These gpios can be used for random purposes on devices with non-RGB setups.

> We can make sure that device tree isn't going to use these on a given
> platform, but there's still the risk of users grabbing them via sysfs or
> the chardev API.
>

Well, defining them in the schema as it is now and adding a note that
gpios specified in the binding cannot be re-used/shared may be a
solution. But overall it is impossible to reuse gpios dedicated for
dbi by hw design. They cannot be shared or used for other purposes if
dbi is used.

> > > As for selecting the interface to use, it could probably be just a
> > > simple, single-cell value with two valid values. That's a bit clearer
> > > than a boolean, because with a boolean you need to explicitly document
> > > what happens when it is absent.
> > >
> >
> > I can describe boolean too, but if you want set it like "nvidia,head".
> > Fine by me.
>
> Yeah, I'd prefer it to be explicit which mode of operation is selected.
>
> Thierry

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6010 bytes --]

On Wed, Sep 30, 2026 at 02:56:26PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 14:46 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 01:56:40PM +0300, Svyatoslav Ryhel wrote:
> > > ср, 30 вер. 2026 р. о 13:50 Thierry Reding <thierry.reding@kernel.org> пише:
> > > >
> > > > On Wed, Sep 30, 2026 at 12:52:18PM +0300, Svyatoslav Ryhel wrote:
> > > > > ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@nvidia.com> пише:
> > > > > >
> > > > > > On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> > > > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > > > Tegra20/30 SoCs display controller.
> > > > > > >
> > > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > ---
> > > > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > > > >  1 file changed, 138 insertions(+)
> > > > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > new file mode 100644
> > > > > > > index 0000000000000..f0dab608b2936
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > @@ -0,0 +1,138 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > +
> > > > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > > > +  commands to initialize and control the panel while image data is
> > > > > > > +  transmitted via 16/18/24-line RGB.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > +  compatible:
> > > > > > > +    const: nvidia,tegra-8bit-cpu
> > > > > > > +
> > > > > > > +  dc-gpios:
> > > > > > > +    description: Data/command selection pin.
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  rw-gpios:
> > > > > > > +    description: Read/write pin.
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  cs-gpios:
> > > > > > > +    description: Chip select pin.
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  data-gpios:
> > > > > > > +    description: Specifies a set of 8 gpio pins used to transfer data.
> > > > > > > +    minItems: 8
> > > > > > > +    maxItems: 8
> > > > > >
> > > > > > Based on my admittedly brief research, according to the TRM the display
> > > > > > controller can drive all of these pins - of which there are two fixed
> > > > > > sets as you mention - directly. So we'd need to describe which interface
> > > > > > the display is connected to in DT, but not any GPIOs (which they really
> > > > > > aren't).
> > > > > >
> > > > >
> > > > > I am perfectly fine to not expose any gpios in the binding, if this is
> > > > > preferred. Only question, which method of interface checking would be
> > > > > preferred. I assume if primary then nothing, if secondary - boolean
> > > > > prop "nvidia,secondary"? Feel free to share your vision.
> > > >
> > > > The driver currently uses the GPIOs to program DBI commands, so I
> > > > suspect we do need some way of controlling those pins. Or is there a way
> > > > to have the display controller program the pins and send commands? That
> > > > would be much preferred because it would more accurately reflect the HW
> > > > design and possibly also simplify the driver because it doesn't need to
> > > > parse the GPIOs and then also not use the GPIO API to set the values.
> > > >
> > >
> > > From what I know, GPIOs must be used and freed after use. Sets of
> > > GPIOs are defined and remain fixed for primary and secondary
> > > interface.
> >
> > So you're saying that we need the GPIO handling in the RGB/DBI driver to
> > prevent anyone else from using these GPIOs and potentially messing with
> > the DBI communication?
> >
> 
> No, gpios are used for dbi communcation while their sfio versions are
> used to transfer RGB data. So there is no risk in external
> intereference.
> 
> > It feels like there should be a better mechanism for that than requiring
> > the DC driver to request all the GPIOs. Maybe these should be excluded
> > from the range of valid GPIOs?
> >
> 
> NO! These gpios can be used for random purposes on devices with non-RGB setups.
> 
> > We can make sure that device tree isn't going to use these on a given
> > platform, but there's still the risk of users grabbing them via sysfs or
> > the chardev API.
> >
> 
> Well, defining them in the schema as it is now and adding a note that
> gpios specified in the binding cannot be re-used/shared may be a
> solution. But overall it is impossible to reuse gpios dedicated for
> dbi by hw design. They cannot be shared or used for other purposes if
> dbi is used.

My concern was that somebody might try to use these pins as GPIOs, in
which case the GPIO and pin controllers are going to interoperate and
reprogram the pin functions, potentially making the DBI interface
malfunction.

Or is there some other hardware mechanism to prevent this from
happening?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 15:58 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 02:56:26PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 14:46 Thierry Reding <thierry.reding@kernel.org> пише:
> > >
> > > On Wed, Sep 30, 2026 at 01:56:40PM +0300, Svyatoslav Ryhel wrote:
> > > > ср, 30 вер. 2026 р. о 13:50 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > >
> > > > > On Wed, Sep 30, 2026 at 12:52:18PM +0300, Svyatoslav Ryhel wrote:
> > > > > > ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@nvidia.com> пише:
> > > > > > >
> > > > > > > On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> > > > > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > > > > Tegra20/30 SoCs display controller.
> > > > > > > >
> > > > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > > ---
> > > > > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > > > > >  1 file changed, 138 insertions(+)
> > > > > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > >
> > > > > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > > new file mode 100644
> > > > > > > > index 0000000000000..f0dab608b2936
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > > @@ -0,0 +1,138 @@
> > > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > > +%YAML 1.2
> > > > > > > > +---
> > > > > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > +
> > > > > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > > > > +
> > > > > > > > +maintainers:
> > > > > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > > +
> > > > > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > > > > +  commands to initialize and control the panel while image data is
> > > > > > > > +  transmitted via 16/18/24-line RGB.
> > > > > > > > +
> > > > > > > > +properties:
> > > > > > > > +  compatible:
> > > > > > > > +    const: nvidia,tegra-8bit-cpu
> > > > > > > > +
> > > > > > > > +  dc-gpios:
> > > > > > > > +    description: Data/command selection pin.
> > > > > > > > +    maxItems: 1
> > > > > > > > +
> > > > > > > > +  rw-gpios:
> > > > > > > > +    description: Read/write pin.
> > > > > > > > +    maxItems: 1
> > > > > > > > +
> > > > > > > > +  cs-gpios:
> > > > > > > > +    description: Chip select pin.
> > > > > > > > +    maxItems: 1
> > > > > > > > +
> > > > > > > > +  data-gpios:
> > > > > > > > +    description: Specifies a set of 8 gpio pins used to transfer data.
> > > > > > > > +    minItems: 8
> > > > > > > > +    maxItems: 8
> > > > > > >
> > > > > > > Based on my admittedly brief research, according to the TRM the display
> > > > > > > controller can drive all of these pins - of which there are two fixed
> > > > > > > sets as you mention - directly. So we'd need to describe which interface
> > > > > > > the display is connected to in DT, but not any GPIOs (which they really
> > > > > > > aren't).
> > > > > > >
> > > > > >
> > > > > > I am perfectly fine to not expose any gpios in the binding, if this is
> > > > > > preferred. Only question, which method of interface checking would be
> > > > > > preferred. I assume if primary then nothing, if secondary - boolean
> > > > > > prop "nvidia,secondary"? Feel free to share your vision.
> > > > >
> > > > > The driver currently uses the GPIOs to program DBI commands, so I
> > > > > suspect we do need some way of controlling those pins. Or is there a way
> > > > > to have the display controller program the pins and send commands? That
> > > > > would be much preferred because it would more accurately reflect the HW
> > > > > design and possibly also simplify the driver because it doesn't need to
> > > > > parse the GPIOs and then also not use the GPIO API to set the values.
> > > > >
> > > >
> > > > From what I know, GPIOs must be used and freed after use. Sets of
> > > > GPIOs are defined and remain fixed for primary and secondary
> > > > interface.
> > >
> > > So you're saying that we need the GPIO handling in the RGB/DBI driver to
> > > prevent anyone else from using these GPIOs and potentially messing with
> > > the DBI communication?
> > >
> >
> > No, gpios are used for dbi communcation while their sfio versions are
> > used to transfer RGB data. So there is no risk in external
> > intereference.
> >
> > > It feels like there should be a better mechanism for that than requiring
> > > the DC driver to request all the GPIOs. Maybe these should be excluded
> > > from the range of valid GPIOs?
> > >
> >
> > NO! These gpios can be used for random purposes on devices with non-RGB setups.
> >
> > > We can make sure that device tree isn't going to use these on a given
> > > platform, but there's still the risk of users grabbing them via sysfs or
> > > the chardev API.
> > >
> >
> > Well, defining them in the schema as it is now and adding a note that
> > gpios specified in the binding cannot be re-used/shared may be a
> > solution. But overall it is impossible to reuse gpios dedicated for
> > dbi by hw design. They cannot be shared or used for other purposes if
> > dbi is used.
>
> My concern was that somebody might try to use these pins as GPIOs, in
> which case the GPIO and pin controllers are going to interoperate and
> reprogram the pin functions, potentially making the DBI interface
> malfunction.
>

If 8bit interface is in use these gpios cannot be used for anything
else. You can be sure of that.

> Or is there some other hardware mechanism to prevent this from
> happening?
>

yes, pins are physically linked to the panel

> Thierry

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@nvidia.com> пише:
>
> On Wednesday, September 30, 2026 4:05 PM Svyatoslav Ryhel wrote:
> > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > Tegra20/30 SoCs display controller.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> >  1 file changed, 138 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > new file mode 100644
> > index 0000000000000..f0dab608b2936
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > @@ -0,0 +1,138 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > +
> > +maintainers:
> > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description: The display controller in Tegra20/30 SoCs features an
> > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > +  provides two such interfaces, which can be used to send MIPI DCS
> > +  commands to initialize and control the panel while image data is
> > +  transmitted via 16/18/24-line RGB.
> > +
> > +properties:
> > +  compatible:
> > +    const: nvidia,tegra-8bit-cpu
> > +
> > +  dc-gpios:
> > +    description: Data/command selection pin.
> > +    maxItems: 1
> > +
> > +  rw-gpios:
> > +    description: Read/write pin.
> > +    maxItems: 1
> > +
> > +  cs-gpios:
> > +    description: Chip select pin.
> > +    maxItems: 1
> > +
> > +  data-gpios:
> > +    description: Specifies a set of 8 gpio pins used to transfer data.
> > +    minItems: 8
> > +    maxItems: 8
>
> Based on my admittedly brief research, according to the TRM the display
> controller can drive all of these pins - of which there are two fixed
> sets as you mention - directly. So we'd need to describe which interface
> the display is connected to in DT, but not any GPIOs (which they really
> aren't).
>

Thierry, Mikko.

I am not sure how to approach GPIOs defined outside of Device Tree.
All GPIO interactions are done either by ofnode/fwnode or software
nodes. Global gpio declaration is in process of being removed and
legacy GPIO API seem to be not long-therm sustainable. How to resolve
this? Should I keep above layout with GPIOs defined in the tree?

> > +
> > +  nvidia,init-sequence:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    description: Device specific set of values used in DC DISP_SPI_INIT_SEQ
> > +      registers.
> > +    minItems: 4
> > +    maxItems: 4
>
> And AIUI this is panel-specific DBI commands the display controller will
> transmit. So ideally the display driver should receive this data from
> the panel driver.
>
> Thank you
> Mikko
>
> > +
> > +  panel:
> > +    type: object
> > +    description: Node of supported panel driven by the bridge.
> > +
> > +  ports:
> > +    $ref: /schemas/graph.yaml#/properties/ports
> > +
> > +    properties:
> > +      port@0:
> > +        $ref: /schemas/graph.yaml#/$defs/port-base
> > +        unevaluatedProperties: false
> > +        description: Video port for RGB input.
> > +
> > +        properties:
> > +          endpoint:
> > +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> > +            unevaluatedProperties: false
> > +
> > +            properties:
> > +              bus-width:
> > +                enum: [ 16, 18, 24 ]
> > +
> > +      port@1:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: Video port for DBI output (panel or connector).
> > +
> > +    required:
> > +      - port@0
> > +      - port@1
> > +
> > +required:
> > +  - compatible
> > +  - ports
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/gpio/gpio.h>
> > +
> > +    dbi-bridge {
> > +        compatible = "nvidia,tegra-8bit-cpu";
> > +
> > +        dc-gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
> > +        rw-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
> > +        cs-gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
> > +
> > +        data-gpios = <&gpio 32 GPIO_ACTIVE_HIGH>, <&gpio 33 GPIO_ACTIVE_HIGH>,
> > +                     <&gpio 34 GPIO_ACTIVE_HIGH>, <&gpio 35 GPIO_ACTIVE_HIGH>,
> > +                     <&gpio 36 GPIO_ACTIVE_HIGH>, <&gpio 37 GPIO_ACTIVE_HIGH>,
> > +                     <&gpio 38 GPIO_ACTIVE_HIGH>, <&gpio 39 GPIO_ACTIVE_HIGH>;
> > +
> > +        nvidia,init-sequence = <0x0000002c 0x0 0x0 0x00005000>;
> > +
> > +        panel {
> > +            compatible = "hit,tx10d07vm0baa";
> > +
> > +            reset-gpios = <&gpio 175 GPIO_ACTIVE_LOW>;
> > +
> > +            avci-supply = <&vcc_2v8_lcd>;
> > +            iovcc-supply = <&iovcc_1v8_lcd>;
> > +
> > +            backlight = <&backlight>;
> > +
> > +            port {
> > +                panel_input: endpoint {
> > +                    remote-endpoint = <&bridge_output>;
> > +                };
> > +            };
> > +        };
> > +
> > +        ports {
> > +            #address-cells = <1>;
> > +            #size-cells = <0>;
> > +
> > +            port@0 {
> > +                reg = <0>;
> > +
> > +                bridge_input: endpoint {
> > +                    remote-endpoint = <&dpi_output>;
> > +                };
> > +            };
> > +
> > +            port@1 {
> > +                reg = <1>;
> > +
> > +                bridge_output: endpoint {
> > +                    remote-endpoint = <&panel_input>;
> > +                };
> > +            };
> > +        };
> > +    };
> > --
> > 2.53.0
> >
> >
>
>
>
>

Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Rob Herring (Arm)]

On Wed, 30 Sep 2026 10:05:32 +0300, Svyatoslav Ryhel wrote:
> Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> Tegra20/30 SoCs display controller.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
>  1 file changed, 138 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.example.dtb: /example-0/dbi-bridge/panel: failed to match any schema with compatible: ['hit,tx10d07vm0baa']

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260930070535.47130-4-clamor95@gmail.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

[PATCH v1 4/6] drm/tegra: Add support for 8-bit CPU interface

[Svyatoslav Ryhel]

The display controller in Tegra20/30 SoCs features an 8-bit SPI interface
that closely resembles the MIPI DBI Type B protocol and is referred to as
'8-bit CPU'. Each display controller provides two such interfaces, which
can be used to send MIPI DCS commands to initialize and control the panel
while image data is transmitted via 16/18/24-line RGB.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 drivers/gpu/drm/tegra/Kconfig      |   7 +
 drivers/gpu/drm/tegra/Makefile     |   1 +
 drivers/gpu/drm/tegra/cpu-bridge.c | 427 +++++++++++++++++++++++++++++
 3 files changed, 435 insertions(+)
 create mode 100644 drivers/gpu/drm/tegra/cpu-bridge.c

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 8a3b16aac5d68..db9839280b8aa 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -30,6 +30,13 @@ config DRM_TEGRA
 
 if DRM_TEGRA
 
+config DRM_TEGRA_CPU_BRIDGE
+	bool "Enable 8 bit panel communication protocol for Tegra 20/30"
+	help
+	  Tegra20 and Tegra30 feature 8 bit CPU driver panel control
+	  protocol (similar to MIPI DBI Type B). This option allows use
+	  it as a MIPI DBI bridge to set up and control compatible panel.
+
 config DRM_TEGRA_DEBUG
 	bool "NVIDIA Tegra DRM debug support"
 	help
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index e399b40d64a1d..88d5ed2f9ded0 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -31,5 +31,6 @@ tegra-drm-y := \
 tegra-drm-y += trace.o
 
 tegra-drm-$(CONFIG_DRM_FBDEV_EMULATION) += fbdev.o
+tegra-drm-$(CONFIG_DRM_TEGRA_CPU_BRIDGE) += cpu-bridge.o
 
 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/cpu-bridge.c b/drivers/gpu/drm/tegra/cpu-bridge.c
new file mode 100644
index 0000000000000..63ca87a0be909
--- /dev/null
+++ b/drivers/gpu/drm/tegra/cpu-bridge.c
@@ -0,0 +1,427 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/kernel.h>
+#include <linux/media-bus-format.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge.h>
+#include <drm/drm_drv.h>
+#include <drm/drm_mipi_dbi.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+#include <video/mipi_display.h>
+
+#include "dc.h"
+
+#define CPU_BRIDGE_COMMAND			0
+#define CPU_BRIDGE_DATA				1
+#define CPU_BRIDGE_DATA_PINS_MAX		8
+
+struct tegra_cpu_bridge_dbi_output {
+	struct drm_panel *panel;
+	struct drm_bridge *bridge;
+};
+
+struct tegra_cpu_bridge_priv {
+	struct mipi_dbi dbi;		/* must be first */
+	struct device *dev;
+	struct tegra_dc *dc;
+
+	struct gpio_desc *dc_gpio;
+	struct gpio_desc *rw_gpio;
+	struct gpio_desc *cs_gpio;
+	struct gpio_descs *data_gpios;
+
+	struct drm_bridge bridge;
+	struct tegra_cpu_bridge_dbi_output output;
+
+	u32 spi_init_seq[4];
+	u32 bus_width;
+	bool prepared;
+};
+
+static inline struct tegra_cpu_bridge_priv *mipi_dbi_to_tegra_cpu_bridge(struct mipi_dbi *dbi)
+{
+	return container_of(dbi, struct tegra_cpu_bridge_priv, dbi);
+}
+
+static inline struct tegra_cpu_bridge_priv *bridge_to_tegra_cpu_bridge(struct drm_bridge *bridge)
+{
+	return container_of(bridge, struct tegra_cpu_bridge_priv, bridge);
+}
+
+static void tegra_cpu_bridge_write(struct tegra_cpu_bridge_priv *priv, u8 type, u8 value)
+{
+	DECLARE_BITMAP(value_bitmap, 8);
+
+	value_bitmap[0] = value;
+
+	gpiod_set_value(priv->dc_gpio, type);
+
+	gpiod_set_value(priv->cs_gpio, 0);
+	gpiod_set_value(priv->rw_gpio, 0);
+
+	gpiod_set_array_value(priv->data_gpios->ndescs, priv->data_gpios->desc,
+			      priv->data_gpios->info, value_bitmap);
+
+	gpiod_set_value(priv->cs_gpio, 1);
+	gpiod_set_value(priv->rw_gpio, 1);
+
+	udelay(10);
+}
+
+static int tegra_cpu_bridge_dbi_command(struct mipi_dbi *dbi, u8 *cmd, u8 *param, size_t num)
+{
+	struct tegra_cpu_bridge_priv *priv = mipi_dbi_to_tegra_cpu_bridge(dbi);
+	u8 command = *cmd;
+
+	tegra_cpu_bridge_write(priv, CPU_BRIDGE_COMMAND, command);
+
+	for (int i = 0; i < num; i++)
+		tegra_cpu_bridge_write(priv, CPU_BRIDGE_DATA, param[i]);
+
+	return 0;
+}
+
+static int tegra_cpu_bridge_prepare_gpios(struct tegra_cpu_bridge_priv *priv)
+{
+	struct device *dev = priv->dev;
+
+	if (priv->prepared)
+		return 0;
+
+	/*
+	 * Control and data GPIOs are shared between SPI and DPI. The bridge
+	 * driver must get and put the required GPIOs each time DCS commands
+	 * are transmitted.
+	 */
+
+	priv->data_gpios = devm_gpiod_get_array_optional(dev, "data", GPIOD_OUT_LOW);
+	if (IS_ERR(priv->data_gpios)) {
+		dev_err(dev, "Failed to get data gpios %ld\n", PTR_ERR(priv->data_gpios));
+		return PTR_ERR(priv->data_gpios);
+	}
+
+	if (priv->data_gpios && priv->data_gpios->ndescs > CPU_BRIDGE_DATA_PINS_MAX) {
+		dev_err(dev, "Too many data gpios\n");
+		return -EINVAL;
+	}
+
+	priv->cs_gpio = devm_gpiod_get_optional(dev, "cs", GPIOD_OUT_HIGH);
+	if (IS_ERR(priv->cs_gpio)) {
+		dev_err(dev, "Failed to get CS GPIO: %ld\n", PTR_ERR(priv->cs_gpio));
+		return PTR_ERR(priv->cs_gpio);
+	}
+
+	priv->rw_gpio = devm_gpiod_get_optional(dev, "rw", GPIOD_OUT_HIGH);
+	if (IS_ERR(priv->rw_gpio)) {
+		dev_err(dev, "Failed to get RW GPIO: %ld\n", PTR_ERR(priv->rw_gpio));
+		return PTR_ERR(priv->rw_gpio);
+	}
+
+	priv->dc_gpio = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
+	if (IS_ERR(priv->dc_gpio)) {
+		dev_err(dev, "Failed to get DC GPIO: %ld\n", PTR_ERR(priv->dc_gpio));
+		return PTR_ERR(priv->dc_gpio);
+	}
+
+	priv->prepared = true;
+
+	return 0;
+}
+
+static void tegra_cpu_bridge_atomic_enable(struct drm_bridge *bridge,
+					   struct drm_atomic_commit *state)
+{
+	struct tegra_cpu_bridge_priv *priv = bridge_to_tegra_cpu_bridge(bridge);
+	struct tegra_dc *dc = priv->dc;
+	u32 value;
+	int ret;
+
+	value = tegra_dc_readl(dc, DC_CMD_DISPLAY_COMMAND);
+	value &= ~DISP_CTRL_MODE_MASK;
+	tegra_dc_writel(dc, value, DC_CMD_DISPLAY_COMMAND);
+
+	/* Disable all options except cursor if enabled */
+	value = tegra_dc_readl(dc, DC_DISP_DISP_WIN_OPTIONS);
+	value &= CURSOR_ENABLE;
+	tegra_dc_writel(dc, value, DC_DISP_DISP_WIN_OPTIONS);
+
+	tegra_dc_commit(dc);
+
+	tegra_dc_writel(dc, V_PULSE1_ENABLE, DC_DISP_DISP_SIGNAL_OPTIONS0);
+	tegra_dc_writel(dc, PULSE_POLARITY_LOW, DC_DISP_V_PULSE1_CONTROL);
+
+	tegra_dc_writel(dc, PULSE_END(1), DC_DISP_V_PULSE0_POSITION_A);
+	tegra_dc_writel(dc, 0, DC_DISP_V_PULSE0_POSITION_B);
+	tegra_dc_writel(dc, 0, DC_DISP_V_PULSE0_POSITION_C);
+
+	value = 1 << FRAME_INIT_SEQ_CYCLES_SHIFT |
+		DC_SIGNAL_VPULSE1 << INIT_SEQ_DC_SIGNAL_SHIFT |
+		INIT_SEQUENCE_MODE_PLCD | SEND_INIT_SEQUENCE;
+	tegra_dc_writel(dc, value, DC_DISP_INIT_SEQ_CONTROL);
+
+	tegra_dc_writel(dc, priv->spi_init_seq[0], DC_DISP_SPI_INIT_SEQ_DATA_A);
+	tegra_dc_writel(dc, priv->spi_init_seq[1], DC_DISP_SPI_INIT_SEQ_DATA_B);
+	tegra_dc_writel(dc, priv->spi_init_seq[2], DC_DISP_SPI_INIT_SEQ_DATA_C);
+	tegra_dc_writel(dc, priv->spi_init_seq[3], DC_DISP_SPI_INIT_SEQ_DATA_D);
+
+	value = tegra_dc_readl(dc, DC_CMD_DISPLAY_COMMAND);
+	value &= ~DISP_CTRL_MODE_MASK;
+	value |= DISP_CTRL_MODE_C_DISPLAY;
+	tegra_dc_writel(dc, value, DC_CMD_DISPLAY_COMMAND);
+
+	/* set LDC pin to V Pulse 1 */
+	value = tegra_dc_readl(dc, DC_COM_PIN_OUTPUT_SELECT(6));
+	value |= LDC_OUTPUT_SELECT_V_PULSE1;
+	tegra_dc_writel(dc, value, DC_COM_PIN_OUTPUT_SELECT(6));
+
+	value = SC1_H_QUALIFIER(SC_H_QUALIFIER_NONE) |
+		SC0_V_QUALIFIER(SC_V_QUALIFIER_VACTIVE) |
+		SC0_H_QUALIFIER(SC_H_QUALIFIER_HACTIVE);
+	tegra_dc_writel(dc, value, DC_DISP_SHIFT_CLOCK_OPTIONS);
+
+	value = tegra_dc_readl(dc, DC_DISP_DISP_COLOR_CONTROL);
+	value &= ~BASE_COLOR_SIZE_MASK;
+
+	switch (priv->bus_width) {
+	case 16:
+		value |= BASE_COLOR_SIZE_565;
+		break;
+	case 18:
+		value |= BASE_COLOR_SIZE_666;
+		break;
+	case 24:
+	default:
+		value |= BASE_COLOR_SIZE_888;
+		break;
+	}
+
+	tegra_dc_writel(dc, value, DC_DISP_DISP_COLOR_CONTROL);
+
+	ret = tegra_cpu_bridge_prepare_gpios(priv);
+	if (ret)
+		return;
+
+	if (priv->output.panel)
+		drm_panel_enable(priv->output.panel);
+
+	gpiod_set_value(priv->cs_gpio, 0);
+
+	devm_gpiod_put(priv->dev, priv->dc_gpio);
+	devm_gpiod_put(priv->dev, priv->rw_gpio);
+	devm_gpiod_put(priv->dev, priv->cs_gpio);
+
+	devm_gpiod_put_array(priv->dev, priv->data_gpios);
+	priv->prepared = false;
+}
+
+static void tegra_cpu_bridge_atomic_disable(struct drm_bridge *bridge,
+					    struct drm_atomic_commit *state)
+{
+	struct tegra_cpu_bridge_priv *priv = bridge_to_tegra_cpu_bridge(bridge);
+	int ret;
+
+	ret = tegra_cpu_bridge_prepare_gpios(priv);
+	if (ret)
+		return;
+
+	if (priv->output.panel)
+		drm_panel_disable(priv->output.panel);
+
+	gpiod_set_value(priv->cs_gpio, 0);
+
+	devm_gpiod_put(priv->dev, priv->dc_gpio);
+	devm_gpiod_put(priv->dev, priv->rw_gpio);
+	devm_gpiod_put(priv->dev, priv->cs_gpio);
+
+	devm_gpiod_put_array(priv->dev, priv->data_gpios);
+	priv->prepared = false;
+}
+
+static int tegra_cpu_bridge_atomic_check(struct drm_bridge *bridge,
+					 struct drm_bridge_state *bridge_state,
+					 struct drm_crtc_state *crtc_state,
+					 struct drm_connector_state *conn_state)
+{
+	struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
+
+	/* Set safe default bus flags if panel does not specify them */
+	if (!bridge_state->input_bus_cfg.flags)
+		bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags;
+
+	/* Default to positive sync */
+	if (!(adjusted_mode->flags &
+	      (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC)))
+		adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+
+	if (!(adjusted_mode->flags &
+	      (DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC)))
+		adjusted_mode->flags |= DRM_MODE_FLAG_PVSYNC;
+
+	return 0;
+}
+
+static int tegra_cpu_bridge_attach(struct drm_bridge *bridge,
+				   struct drm_encoder *encoder,
+				   enum drm_bridge_attach_flags flags)
+{
+	struct tegra_cpu_bridge_priv *priv = bridge_to_tegra_cpu_bridge(bridge);
+	struct device_node *rgb_node, *dc_node;
+	struct platform_device *dc_pdev;
+
+	rgb_node = of_graph_get_remote_node(dev_of_node(priv->dev), 0, 0);
+	if (!rgb_node)
+		return -ENODEV;
+
+	dc_node = of_get_parent(rgb_node);
+	of_node_put(rgb_node);
+	if (!dc_node)
+		return -ENODEV;
+
+	dc_pdev = of_find_device_by_node(dc_node);
+	of_node_put(dc_node);
+	if (!dc_pdev)
+		return -ENODEV;
+
+	priv->dc = platform_get_drvdata(dc_pdev);
+	if (!priv->dc)
+		return -ENODEV;
+
+	return drm_bridge_attach(bridge->encoder, priv->output.bridge, bridge,
+				 flags);
+}
+
+static enum drm_mode_status
+tegra_cpu_bridge_mode_valid(struct drm_bridge *bridge,
+			    const struct drm_display_info *info,
+			    const struct drm_display_mode *mode)
+{
+	if (mode->hdisplay > 800)
+		return MODE_H_ILLEGAL;
+
+	if (mode->vdisplay > 800)
+		return MODE_V_ILLEGAL;
+
+	return MODE_OK;
+}
+
+static const struct drm_bridge_funcs tegra_cpu_bridge_funcs = {
+	.attach = tegra_cpu_bridge_attach,
+	.mode_valid = tegra_cpu_bridge_mode_valid,
+
+	.atomic_enable = tegra_cpu_bridge_atomic_enable,
+	.atomic_disable = tegra_cpu_bridge_atomic_disable,
+	.atomic_check = tegra_cpu_bridge_atomic_check,
+
+	.atomic_create_state = drm_atomic_helper_bridge_create_state,
+	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+};
+
+static const struct drm_bridge_timings default_tegra_cpu_bridge_timings = {
+	.input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
+			   DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE |
+			   DRM_BUS_FLAG_DE_HIGH,
+};
+
+static int tegra_cpu_bridge_probe(struct platform_device *pdev)
+{
+	struct tegra_cpu_bridge_priv *priv;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct drm_bridge *bridge;
+	struct drm_panel *panel;
+	struct device_node *ep;
+	int ret;
+
+	priv = devm_drm_bridge_alloc(dev, struct tegra_cpu_bridge_priv, bridge,
+				     &tegra_cpu_bridge_funcs);
+	if (IS_ERR(priv))
+		return PTR_ERR(priv);
+
+	priv->dev = dev;
+
+	ret = device_property_read_u32_array(dev, "nvidia,init-sequence",
+					     priv->spi_init_seq, 4);
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "Failed to get init sequence\n");
+
+	ret = devm_of_platform_populate(dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to probe children\n");
+
+	/* Initialize MIPI DBI interface */
+	mutex_init(&priv->dbi.cmdlock);
+	priv->dbi.command = tegra_cpu_bridge_dbi_command;
+
+	ret = drm_of_find_panel_or_bridge(np, 1, 0, &panel, &bridge);
+	if (ret)
+		return ret;
+
+	if (panel) {
+		bridge = devm_drm_panel_bridge_add_typed(dev, panel,
+							 DRM_MODE_CONNECTOR_DPI);
+		if (IS_ERR(bridge))
+			return PTR_ERR(bridge);
+	}
+
+	priv->output.bridge = bridge;
+	priv->output.panel = panel;
+
+	/* get input ep (port0/endpoint0) */
+	ret = -EINVAL;
+	ep = of_graph_get_endpoint_by_regs(np, 0, 0);
+	if (ep) {
+		ret = of_property_read_u32(ep, "bus-width", &priv->bus_width);
+		of_node_put(ep);
+	}
+
+	if (ret)
+		priv->bus_width = 24;
+
+	priv->bridge.of_node = np;
+	priv->bridge.timings = &default_tegra_cpu_bridge_timings;
+
+	drm_bridge_add(&priv->bridge);
+
+	platform_set_drvdata(pdev, priv);
+
+	return 0;
+}
+
+static void tegra_cpu_bridge_remove(struct platform_device *pdev)
+{
+	struct tegra_cpu_bridge_priv *priv = platform_get_drvdata(pdev);
+
+	drm_bridge_remove(&priv->bridge);
+	if (priv->output.panel)
+		drm_panel_bridge_remove(priv->output.bridge);
+}
+
+static const struct of_device_id tegra_cpu_bridge_of_match[] = {
+	{ .compatible = "nvidia,tegra-8bit-cpu" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tegra_cpu_bridge_of_match);
+
+static struct platform_driver tegra_cpu_bridge_driver = {
+	.driver = {
+		.name = "tegra-cpu-bridge",
+		.of_match_table = tegra_cpu_bridge_of_match,
+	},
+	.probe = tegra_cpu_bridge_probe,
+	.remove = tegra_cpu_bridge_remove,
+};
+module_platform_driver(tegra_cpu_bridge_driver);
+
+MODULE_AUTHOR("Svyatoslav Ryhel <clamor95@gmail.com>");
+MODULE_DESCRIPTION("Nvidia Tegra20/30 RGB to MIPI-DBI bridge driver");
+MODULE_LICENSE("GPL");
-- 
2.53.0

Re: [PATCH v1 4/6] drm/tegra: Add support for 8-bit CPU interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Wed, Sep 30, 2026 at 10:05:33AM +0300, Svyatoslav Ryhel wrote:
> The display controller in Tegra20/30 SoCs features an 8-bit SPI interface
> that closely resembles the MIPI DBI Type B protocol and is referred to as
> '8-bit CPU'. Each display controller provides two such interfaces, which
> can be used to send MIPI DCS commands to initialize and control the panel
> while image data is transmitted via 16/18/24-line RGB.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  drivers/gpu/drm/tegra/Kconfig      |   7 +
>  drivers/gpu/drm/tegra/Makefile     |   1 +
>  drivers/gpu/drm/tegra/cpu-bridge.c | 427 +++++++++++++++++++++++++++++
>  3 files changed, 435 insertions(+)
>  create mode 100644 drivers/gpu/drm/tegra/cpu-bridge.c

This doesn't need to be a separate driver. It should all live in dc.c.
Or maybe even rgb.c, since it uses pretty much the same pins and is
quite similar to it.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 4/6] drm/tegra: Add support for 8-bit CPU interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 11:48 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 10:05:33AM +0300, Svyatoslav Ryhel wrote:
> > The display controller in Tegra20/30 SoCs features an 8-bit SPI interface
> > that closely resembles the MIPI DBI Type B protocol and is referred to as
> > '8-bit CPU'. Each display controller provides two such interfaces, which
> > can be used to send MIPI DCS commands to initialize and control the panel
> > while image data is transmitted via 16/18/24-line RGB.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  drivers/gpu/drm/tegra/Kconfig      |   7 +
> >  drivers/gpu/drm/tegra/Makefile     |   1 +
> >  drivers/gpu/drm/tegra/cpu-bridge.c | 427 +++++++++++++++++++++++++++++
> >  3 files changed, 435 insertions(+)
> >  create mode 100644 drivers/gpu/drm/tegra/cpu-bridge.c
>
> This doesn't need to be a separate driver. It should all live in dc.c.
> Or maybe even rgb.c, since it uses pretty much the same pins and is
> quite similar to it.
>

I don't mind moving this to dc or rgb, my intention was to avoid
bloating them with smth that is not used often and is present only on
Tegra20 and Tegra30.

> Thierry

Re: [PATCH v1 4/6] drm/tegra: Add support for 8-bit CPU interface

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Wed, Sep 30, 2026 at 12:02:14PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 11:48 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 10:05:33AM +0300, Svyatoslav Ryhel wrote:
> > > The display controller in Tegra20/30 SoCs features an 8-bit SPI interface
> > > that closely resembles the MIPI DBI Type B protocol and is referred to as
> > > '8-bit CPU'. Each display controller provides two such interfaces, which
> > > can be used to send MIPI DCS commands to initialize and control the panel
> > > while image data is transmitted via 16/18/24-line RGB.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > >  drivers/gpu/drm/tegra/Kconfig      |   7 +
> > >  drivers/gpu/drm/tegra/Makefile     |   1 +
> > >  drivers/gpu/drm/tegra/cpu-bridge.c | 427 +++++++++++++++++++++++++++++
> > >  3 files changed, 435 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/tegra/cpu-bridge.c
> >
> > This doesn't need to be a separate driver. It should all live in dc.c.
> > Or maybe even rgb.c, since it uses pretty much the same pins and is
> > quite similar to it.
> >
> 
> I don't mind moving this to dc or rgb, my intention was to avoid
> bloating them with smth that is not used often and is present only on
> Tegra20 and Tegra30.

I don't think we've ever used rgb beyond Tegra30, so I wouldn't worry
about that. Even with this integrated into rgb.c, we'll end up with
around 1000 lines of code in that file, which is still quite manageable.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v1 5/6] dt-bindings: display: panel: Document Hitachi TX10D07VM0BAA and LG LH400WV3 panels

[Svyatoslav Ryhel]

Document Hitachi TX10D07VM0BAA and LG LH400WV3 MIPI DBI 4" WVGA panels
found in LG Optimus 2X P990.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 .../display/panel/hit,tx10d07vm0baa.yaml      | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/hit,tx10d07vm0baa.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/hit,tx10d07vm0baa.yaml b/Documentation/devicetree/bindings/display/panel/hit,tx10d07vm0baa.yaml
new file mode 100644
index 0000000000000..ab839d9e4e111
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/hit,tx10d07vm0baa.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/hit,tx10d07vm0baa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hitachi/LG 4" WVGA TFT LCD panel
+
+maintainers:
+  - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - hit,tx10d07vm0baa
+          - lg,lh400wv3-sd04
+
+  avci-supply: true
+  iovcc-supply: true
+
+  reset-gpios: true
+
+  backlight: true
+  port: true
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    panel {
+        compatible = "lg,lh400wv3-sd04";
+
+        reset-gpios = <&gpio 175 GPIO_ACTIVE_LOW>;
+
+        avci-supply = <&vcc_2v8_lcd>;
+        iovcc-supply = <&iovcc_1v8_lcd>;
+
+        backlight = <&backlight>;
+
+        port {
+            endpoint {
+                remote-endpoint = <&dbi_out>;
+            };
+        };
+    };
+...
-- 
2.53.0

[PATCH v1 6/6] drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI panel driver

[Svyatoslav Ryhel]

Add a driver for panels used in LG Optimus 2X P990. Both panels are 4"
WVGA MIPI DBI Type B linked to DRM encoder via RGB to DBI bridge.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 drivers/gpu/drm/panel/Kconfig                 |  14 +
 drivers/gpu/drm/panel/Makefile                |   1 +
 .../drm/panel/panel-hitachi-tx10d07vm0baa.c   | 396 ++++++++++++++++++
 3 files changed, 411 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 747f47347521a..47962197a9c76 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -273,6 +273,20 @@ config DRM_PANEL_HIMAX_HX8394
 
 	  If M is selected the module will be called panel-himax-hx8394.
 
+config DRM_PANEL_HITACHI_TX10D07VM0BAA
+	tristate "Hitachi TX10D07VM0BAA and LG LH400WV3 MIPI DBI panels"
+	depends on OF
+	depends on BACKLIGHT_CLASS_DEVICE
+	select DRM_MIPI_DBI
+	select VIDEOMODE_HELPERS
+	help
+	  Say Y here if you want to enable support for the HITACHI
+	  TX10D07VM0BAA and LG LH400WV3 MIPI DBI panels found in the
+	  LG Optimus 2X P990 smartphone.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called panel-hitachi-tx10d07vm0baa.
+
 config DRM_PANEL_HYDIS_HV101HD1
 	tristate "Hydis HV101HD1 panel"
 	depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f2c9c80a218f0..414267a49d922 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112B) += panel-himax-hx83112b.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX83121A) += panel-himax-hx83121a.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
+obj-$(CONFIG_DRM_PANEL_HITACHI_TX10D07VM0BAA) += panel-hitachi-tx10d07vm0baa.o
 obj-$(CONFIG_DRM_PANEL_HYDIS_HV101HD1) += panel-hydis-hv101hd1.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI7807S) += panel-ilitek-ili7807s.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI7836A) += panel-ilitek-ili7836a.o
diff --git a/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c b/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
new file mode 100644
index 0000000000000..d2c3b63649288
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/array_size.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/media-bus-format.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+
+#include <video/mipi_display.h>
+
+#include <drm/drm_mipi_dbi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_probe_helper.h>
+
+enum panel_dbi_id {
+	PANEL_DBI_NONE,
+	PANEL_DBI_TX10D07VM0BAA,
+	PANEL_DBI_LH400WV3,
+};
+
+static const struct regulator_bulk_data panel_dbi_supplies[] = {
+	{ .supply = "avci" }, { .supply = "iovcc" },
+};
+
+struct panel_dbi {
+	struct drm_panel panel;
+	struct mipi_dbi *dbi;
+
+	struct regulator_bulk_data *supplies;
+	struct gpio_desc *reset_gpio;
+};
+
+static inline struct panel_dbi *to_panel_dbi(struct drm_panel *panel)
+{
+	return container_of(panel, struct panel_dbi, panel);
+}
+
+#define panel_dbi_command(priv, cmd, seq...) \
+({ \
+	const u8 d[] = { seq }; \
+	struct drm_panel *panel = &(priv)->panel; \
+	struct device *dev = panel->dev; \
+	int ret; \
+	ret = mipi_dbi_command_stackbuf((priv)->dbi, cmd, d, ARRAY_SIZE(d)); \
+	if (ret) \
+		dev_err_ratelimited(dev, "error %d when sending command %#02x\n", ret, cmd); \
+	ret; \
+})
+
+static int panel_dbi_prepare(struct drm_panel *panel)
+{
+	struct panel_dbi *priv = to_panel_dbi(panel);
+	struct platform_device *bridge_pdev;
+	struct device_node *bridge_node;
+	struct device *dev = panel->dev;
+	int ret;
+
+	bridge_node = of_graph_get_remote_node(dev_of_node(dev), 0, 0);
+	if (!bridge_node)
+		return -ENODEV;
+
+	bridge_pdev = of_find_device_by_node(bridge_node);
+	of_node_put(bridge_node);
+	if (!bridge_pdev)
+		return -ENODEV;
+
+	priv->dbi = platform_get_drvdata(bridge_pdev);
+	if (!priv->dbi)
+		return -ENODEV;
+
+	gpiod_set_value_cansleep(priv->reset_gpio, 1);
+
+	ret = regulator_bulk_enable(ARRAY_SIZE(panel_dbi_supplies), priv->supplies);
+	if (ret) {
+		dev_err(dev, "failed to enable power supplies: %d\n", ret);
+		return ret;
+	}
+
+	usleep_range(1000, 2000);
+
+	gpiod_set_value_cansleep(priv->reset_gpio, 0);
+
+	usleep_range(10000, 11000);
+
+	return 0;
+};
+
+static int panel_dbi_unprepare(struct drm_panel *panel)
+{
+	struct panel_dbi *priv = to_panel_dbi(panel);
+
+	gpiod_set_value_cansleep(priv->reset_gpio, 1);
+	regulator_bulk_disable(ARRAY_SIZE(panel_dbi_supplies), priv->supplies);
+
+	msleep(50);
+
+	return 0;
+}
+
+static const struct drm_display_mode panel_dbi_mode = {
+	.clock = (480 + 10 + 10 + 10) * (800 + 4 + 4 + 4) * 60 / 1000,
+	.hdisplay = 480,
+	.hsync_start = 480 + 10,
+	.hsync_end = 480 + 10 + 10,
+	.htotal = 480 + 10 + 10 + 10,
+	.vdisplay = 800,
+	.vsync_start = 800 + 4,
+	.vsync_end = 800 + 4 + 4,
+	.vtotal = 800 + 4 + 4 + 4,
+	.width_mm = 86,
+	.height_mm = 52,
+	.type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static int panel_dbi_get_modes(struct drm_panel *panel,
+			       struct drm_connector *connector)
+{
+	u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+
+	drm_display_info_set_bus_formats(&connector->display_info,
+					 &bus_format, 1);
+
+	connector->display_info.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
+					    DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE |
+					    DRM_BUS_FLAG_DE_HIGH |
+					    DRM_BUS_FLAG_DATA_LSB_TO_MSB;
+
+	return drm_connector_helper_get_modes_fixed(connector, &panel_dbi_mode);
+}
+
+static int hitachi_tx10d07vm0baa_enable(struct drm_panel *panel)
+{
+	struct panel_dbi *priv = to_panel_dbi(panel);
+
+	panel_dbi_command(priv, MIPI_DCS_SET_PARTIAL_ROWS, 0x00, 0x00, 0x03, 0x1f);
+	panel_dbi_command(priv, MIPI_DCS_SET_SCROLL_AREA, 0x00, 0x00, 0x03, 0x20,
+			  0x00, 0x00);
+
+	panel_dbi_command(priv, MIPI_DCS_SET_ADDRESS_MODE, 0x0a);
+	panel_dbi_command(priv, MIPI_DCS_SET_SCROLL_START, 0x00, 0x00);
+
+	panel_dbi_command(priv, MIPI_DCS_SET_PIXEL_FORMAT, MIPI_DCS_PIXEL_FMT_24BIT);
+	panel_dbi_command(priv, MIPI_DCS_SET_TEAR_SCANLINE, 0x00, 0x00);
+
+	panel_dbi_command(priv, 0x71, 0x00);		/* Ex_Vsync_en */
+
+	panel_dbi_command(priv, 0xb2, 0x00);		/* VCSEL */
+	panel_dbi_command(priv, 0xb4, 0xaa);		/* setvgmpm */
+	panel_dbi_command(priv, 0xb5, 0x33);		/* rbias1 */
+	panel_dbi_command(priv, 0xb6, 0x03);		/* rbias2 */
+
+	panel_dbi_command(priv, 0xb7, 0x1a, 0x33, 0x03, 0x03,
+			  0x03, 0x00, 0x00, 0x01, 0x02, 0x00,
+			  0x00, 0x04, 0x00, 0x01, 0x01, 0x01);	/* set_ddvdhp */
+	panel_dbi_command(priv, 0xb8, 0x1c, 0x53, 0x03, 0x03,
+			  0x00, 0x01, 0x02, 0x00, 0x00, 0x04,
+			  0x00, 0x01, 0x01);			/* set_ddvdhm */
+
+	panel_dbi_command(priv, 0xb9, 0x0a, 0x01, 0x01, 0x00,
+			  0x00, 0x00, 0x02, 0x00, 0x02, 0x01);	/* set_vgh */
+	panel_dbi_command(priv, 0xba, 0x0f, 0x01, 0x01, 0x00,
+			  0x00, 0x00, 0x02, 0x00, 0x02, 0x01);	/* set_vgl */
+	panel_dbi_command(priv, 0xbb, 0x00, 0x00, 0x00, 0x00,
+			  0x01, 0x02, 0x01);			/* set_vcl */
+
+	panel_dbi_command(priv, 0xc1, 0x01);		/* number of lines */
+	panel_dbi_command(priv, 0xc2, 0x08);		/* number of fp lines */
+	panel_dbi_command(priv, 0xc3, 0x04);		/* gateset(1) */
+	panel_dbi_command(priv, 0xc4, 0x4c);		/* 1h period */
+	panel_dbi_command(priv, 0xc5, 0x03);		/* source precharge */
+	panel_dbi_command(priv, 0xc6, 0xc4, 0x04);	/* source precharge timing */
+	panel_dbi_command(priv, 0xc7, 0x00);		/* source level */
+	panel_dbi_command(priv, 0xc8, 0x02);		/* number of bp lines */
+	panel_dbi_command(priv, 0xc9, 0x10);		/* gateset(2) */
+	panel_dbi_command(priv, 0xca, 0x04, 0x04);	/* gateset(3) */
+	panel_dbi_command(priv, 0xcb, 0x03);		/* gateset(4) */
+	panel_dbi_command(priv, 0xcc, 0x12);		/* gateset(5) */
+	panel_dbi_command(priv, 0xcd, 0x12);		/* gateset(6) */
+	panel_dbi_command(priv, 0xce, 0x30);		/* gateset(7) */
+	panel_dbi_command(priv, 0xcf, 0x30);		/* gateset(8) */
+	panel_dbi_command(priv, 0xd0, 0x40);		/* gateset(9) */
+	panel_dbi_command(priv, 0xd1, 0x22);		/* flhw */
+	panel_dbi_command(priv, 0xd2, 0x22);		/* vckhw */
+	panel_dbi_command(priv, 0xd3, 0x04);		/* flt */
+	panel_dbi_command(priv, 0xd4, 0x14);		/* tctrl */
+	panel_dbi_command(priv, 0xd6, 0x02);		/* dotinv */
+	panel_dbi_command(priv, 0xd7, 0x00);		/* on/off sequence period */
+
+	panel_dbi_command(priv, 0xd8, 0x01, 0x05, 0x06, 0x0d,
+			  0x18, 0x09, 0x22, 0x23, 0x00);		/* ponseqa */
+	panel_dbi_command(priv, 0xd9, 0x24, 0x01);			/* ponseqb */
+	panel_dbi_command(priv, 0xde, 0x09, 0x0f, 0x21, 0x12,
+			  0x04);					/* ponseqc */
+
+	panel_dbi_command(priv, 0xdf, 0x02, 0x06, 0x06, 0x06,
+			  0x06, 0x00);					/* pofseqa */
+	panel_dbi_command(priv, 0xe0, 0x01);				/* pofseqb */
+
+	panel_dbi_command(priv, MIPI_DCS_SET_DISPLAY_BRIGHTNESS, 0xff);
+	panel_dbi_command(priv, MIPI_DCS_WRITE_CONTROL_DISPLAY, 0x40);
+
+	panel_dbi_command(priv, 0xe2, 0x00, 0x00);		/* cabc pwm */
+	panel_dbi_command(priv, 0xe3, 0x03);			/* cabc */
+	panel_dbi_command(priv, 0xe4, 0x66, 0x7b, 0x90, 0xa5,
+			  0xbb, 0xc7, 0xe1, 0xe5);		/* cabc brightness */
+	panel_dbi_command(priv, 0xe5, 0xc5, 0xc5, 0xc9, 0xc9,
+			  0xd1, 0xe1, 0xf1, 0xfe);		/* cabc brightness */
+	panel_dbi_command(priv, 0xe7, 0x2a);			/* cabc */
+	panel_dbi_command(priv, 0xe8, 0x00);			/* brt_rev */
+	panel_dbi_command(priv, 0xe9, 0x00);			/* tefreq */
+
+	panel_dbi_command(priv, 0xea, 0x01);			/* high speed ram */
+
+	panel_dbi_command(priv, 0xeb, 0x00, 0x33, 0x0e, 0x15,
+			  0xb7, 0x78, 0x88, 0x0f);		/* gamma setting r pos */
+	panel_dbi_command(priv, 0xec, 0x00, 0x33, 0x0e, 0x15,
+			  0xb7, 0x78, 0x88, 0x0f);		/* gamma setting r neg */
+	panel_dbi_command(priv, 0xed, 0x00, 0x33, 0x0e, 0x15,
+			  0xb7, 0x78, 0x88, 0x0f);		/* gamma setting g pos */
+	panel_dbi_command(priv, 0xee, 0x00, 0x33, 0x0e, 0x15,
+			  0xb7, 0x78, 0x88, 0x0f);		/* gamma setting g neg */
+	panel_dbi_command(priv, 0xef, 0x00, 0x33, 0x0e, 0x15,
+			  0xb7, 0x78, 0x88, 0x0f);		/* gamma setting b pos */
+	panel_dbi_command(priv, 0xf0, 0x00, 0x33, 0x0e, 0x15,
+			  0xb7, 0x78, 0x88, 0x0f);		/* gamma setting b neg */
+
+	panel_dbi_command(priv, MIPI_DCS_EXIT_SLEEP_MODE);
+	msleep(110);
+
+	panel_dbi_command(priv, MIPI_DCS_SET_DISPLAY_ON);
+
+	return 0;
+}
+
+static int hitachi_tx10d07vm0baa_disable(struct drm_panel *panel)
+{
+	struct panel_dbi *priv = to_panel_dbi(panel);
+
+	panel_dbi_command(priv, MIPI_DCS_SET_DISPLAY_OFF);
+	msleep(35);
+
+	panel_dbi_command(priv, MIPI_DCS_ENTER_SLEEP_MODE);
+	msleep(50);
+
+	return 0;
+}
+
+static const struct drm_panel_funcs hitachi_tx10d07vm0baa_panel_funcs = {
+	.prepare = panel_dbi_prepare,
+	.enable = hitachi_tx10d07vm0baa_enable,
+	.disable = hitachi_tx10d07vm0baa_disable,
+	.unprepare = panel_dbi_unprepare,
+	.get_modes = panel_dbi_get_modes,
+};
+
+static int lg_lh400wv3_enable(struct drm_panel *panel)
+{
+	struct panel_dbi *priv = to_panel_dbi(panel);
+
+	panel_dbi_command(priv, MIPI_DCS_EXIT_INVERT_MODE);
+	panel_dbi_command(priv, MIPI_DCS_SET_TEAR_ON);
+
+	panel_dbi_command(priv, MIPI_DCS_SET_PIXEL_FORMAT, MIPI_DCS_PIXEL_FMT_24BIT |
+			  MIPI_DCS_PIXEL_FMT_24BIT << 4);
+
+	panel_dbi_command(priv, 0xb2, 0x00, 0xc8);
+	panel_dbi_command(priv, 0xb3, 0x00);
+	panel_dbi_command(priv, 0xb4, 0x04);
+	panel_dbi_command(priv, 0xb5, 0x42, 0x10, 0x10, 0x00, 0x20);
+	panel_dbi_command(priv, 0xb6, 0x0b, 0x0f, 0x3c, 0x13, 0x13, 0xe8);
+	panel_dbi_command(priv, 0xb7, 0x4c, 0x06, 0x0c, 0x00, 0x00);
+
+	panel_dbi_command(priv, 0xc0, 0x01, 0x11);
+	panel_dbi_command(priv, 0xc3, 0x07, 0x03, 0x04, 0x04, 0x04);
+	panel_dbi_command(priv, 0xc4, 0x12, 0x24, 0x18, 0x18, 0x02, 0x49);
+	panel_dbi_command(priv, 0xc5, 0x65);
+	panel_dbi_command(priv, 0xc6, 0x41, 0x63);
+
+	panel_dbi_command(priv, 0xd0, 0x00, 0x46, 0x74, 0x32, 0x1d, 0x03, 0x51, 0x15, 0x04);
+	panel_dbi_command(priv, 0xd1, 0x00, 0x46, 0x74, 0x32, 0x1d, 0x03, 0x51, 0x15, 0x04);
+	panel_dbi_command(priv, 0xd2, 0x00, 0x46, 0x74, 0x32, 0x1f, 0x03, 0x51, 0x15, 0x04);
+	panel_dbi_command(priv, 0xd3, 0x00, 0x46, 0x74, 0x32, 0x1f, 0x03, 0x51, 0x15, 0x04);
+	panel_dbi_command(priv, 0xd4, 0x01, 0x46, 0x74, 0x25, 0x00, 0x03, 0x51, 0x15, 0x04);
+	panel_dbi_command(priv, 0xd5, 0x01, 0x46, 0x74, 0x25, 0x00, 0x03, 0x51, 0x15, 0x04);
+
+	panel_dbi_command(priv, MIPI_DCS_SET_COLUMN_ADDRESS, 0x00, 0x00, 0x01, 0xdf);
+	panel_dbi_command(priv, MIPI_DCS_SET_PAGE_ADDRESS, 0x00, 0x00, 0x03, 0x1f);
+
+	panel_dbi_command(priv, MIPI_DCS_EXIT_SLEEP_MODE);
+	msleep(120);
+
+	panel_dbi_command(priv, MIPI_DCS_WRITE_MEMORY_START);
+	panel_dbi_command(priv, MIPI_DCS_SET_DISPLAY_ON);
+
+	return 0;
+}
+
+static int lg_lh400wv3_disable(struct drm_panel *panel)
+{
+	struct panel_dbi *priv = to_panel_dbi(panel);
+
+	panel_dbi_command(priv, MIPI_DCS_SET_DISPLAY_OFF);
+	panel_dbi_command(priv, MIPI_DCS_ENTER_SLEEP_MODE);
+	msleep(150);
+
+	panel_dbi_command(priv, 0xc1, 0x01);
+	usleep_range(10000, 11000);
+
+	return 0;
+};
+
+static const struct drm_panel_funcs lg_lh400wv3_panel_funcs = {
+	.prepare = panel_dbi_prepare,
+	.enable = lg_lh400wv3_enable,
+	.disable = lg_lh400wv3_disable,
+	.unprepare = panel_dbi_unprepare,
+	.get_modes = panel_dbi_get_modes,
+};
+
+static int panel_dbi_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct drm_panel_funcs *panel_dbi_funcs;
+	struct panel_dbi *priv;
+	enum panel_dbi_id id;
+	int ret;
+
+	id = (uintptr_t)of_device_get_match_data(dev);
+
+	switch (id) {
+	case PANEL_DBI_TX10D07VM0BAA:
+		panel_dbi_funcs = &hitachi_tx10d07vm0baa_panel_funcs;
+		break;
+
+	case PANEL_DBI_LH400WV3:
+		panel_dbi_funcs = &lg_lh400wv3_panel_funcs;
+		break;
+
+	default:
+		return dev_err_probe(dev, -ENODEV, "Unknown device %d\n", id);
+	}
+
+	priv = devm_drm_panel_alloc(dev, struct panel_dbi, panel,
+				    panel_dbi_funcs, DRM_MODE_CONNECTOR_DPI);
+	if (IS_ERR(priv))
+		return PTR_ERR(priv);
+
+	ret = devm_regulator_bulk_get_const(dev, ARRAY_SIZE(panel_dbi_supplies),
+					    panel_dbi_supplies, &priv->supplies);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to get supplies\n");
+
+	priv->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(priv->reset_gpio))
+		return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
+				     "Failed to get reset gpio\n");
+
+	ret = drm_panel_of_backlight(&priv->panel);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to get backlight\n");
+
+	ret = devm_drm_panel_add(dev, &priv->panel);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to add panel\n");
+
+	platform_set_drvdata(pdev, priv);
+
+	return 0;
+}
+
+static const struct of_device_id panel_dbi_of_match[] = {
+	{ .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
+	{ .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, panel_dbi_of_match);
+
+static struct platform_driver panel_dbi_driver = {
+	.driver = {
+		.name = "panel-hitachi-tx10d07vm0baa",
+		.of_match_table = panel_dbi_of_match,
+	},
+	.probe = panel_dbi_probe,
+};
+module_platform_driver(panel_dbi_driver);
+
+MODULE_AUTHOR("Svyatoslav Ryhel <clamor95@gmail.com>");
+MODULE_DESCRIPTION("HITACHI TX10D07VM0BAA and LG LH400WV3-SD04 DBI panels driver");
+MODULE_LICENSE("GPL");
-- 
2.53.0

Re: [PATCH v1 6/6] drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI panel driver

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6615 bytes --]

On Wed, Sep 30, 2026 at 10:05:35AM +0300, Svyatoslav Ryhel wrote:
> Add a driver for panels used in LG Optimus 2X P990. Both panels are 4"
> WVGA MIPI DBI Type B linked to DRM encoder via RGB to DBI bridge.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  drivers/gpu/drm/panel/Kconfig                 |  14 +
>  drivers/gpu/drm/panel/Makefile                |   1 +
>  .../drm/panel/panel-hitachi-tx10d07vm0baa.c   | 396 ++++++++++++++++++
>  3 files changed, 411 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 747f47347521a..47962197a9c76 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -273,6 +273,20 @@ config DRM_PANEL_HIMAX_HX8394
>  
>  	  If M is selected the module will be called panel-himax-hx8394.
>  
> +config DRM_PANEL_HITACHI_TX10D07VM0BAA
> +	tristate "Hitachi TX10D07VM0BAA and LG LH400WV3 MIPI DBI panels"
> +	depends on OF
> +	depends on BACKLIGHT_CLASS_DEVICE
> +	select DRM_MIPI_DBI
> +	select VIDEOMODE_HELPERS
> +	help
> +	  Say Y here if you want to enable support for the HITACHI
> +	  TX10D07VM0BAA and LG LH400WV3 MIPI DBI panels found in the
> +	  LG Optimus 2X P990 smartphone.
> +
> +	  To compile this driver as a module, choose M here: the module will
> +	  be called panel-hitachi-tx10d07vm0baa.
> +
>  config DRM_PANEL_HYDIS_HV101HD1
>  	tristate "Hydis HV101HD1 panel"
>  	depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index f2c9c80a218f0..414267a49d922 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
>  obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112B) += panel-himax-hx83112b.o
>  obj-$(CONFIG_DRM_PANEL_HIMAX_HX83121A) += panel-himax-hx83121a.o
>  obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
> +obj-$(CONFIG_DRM_PANEL_HITACHI_TX10D07VM0BAA) += panel-hitachi-tx10d07vm0baa.o
>  obj-$(CONFIG_DRM_PANEL_HYDIS_HV101HD1) += panel-hydis-hv101hd1.o
>  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI7807S) += panel-ilitek-ili7807s.o
>  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI7836A) += panel-ilitek-ili7836a.o
> diff --git a/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c b/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
> new file mode 100644
> index 0000000000000..d2c3b63649288
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
> @@ -0,0 +1,396 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/array_size.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/media-bus-format.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <video/mipi_display.h>
> +
> +#include <drm/drm_mipi_dbi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_probe_helper.h>
> +
> +enum panel_dbi_id {
> +	PANEL_DBI_NONE,
> +	PANEL_DBI_TX10D07VM0BAA,
> +	PANEL_DBI_LH400WV3,
> +};
> +
> +static const struct regulator_bulk_data panel_dbi_supplies[] = {
> +	{ .supply = "avci" }, { .supply = "iovcc" },
> +};
> +
> +struct panel_dbi {
> +	struct drm_panel panel;
> +	struct mipi_dbi *dbi;
> +
> +	struct regulator_bulk_data *supplies;
> +	struct gpio_desc *reset_gpio;
> +};
> +
> +static inline struct panel_dbi *to_panel_dbi(struct drm_panel *panel)
> +{
> +	return container_of(panel, struct panel_dbi, panel);
> +}
> +
> +#define panel_dbi_command(priv, cmd, seq...) \
> +({ \
> +	const u8 d[] = { seq }; \
> +	struct drm_panel *panel = &(priv)->panel; \
> +	struct device *dev = panel->dev; \
> +	int ret; \
> +	ret = mipi_dbi_command_stackbuf((priv)->dbi, cmd, d, ARRAY_SIZE(d)); \
> +	if (ret) \
> +		dev_err_ratelimited(dev, "error %d when sending command %#02x\n", ret, cmd); \
> +	ret; \
> +})
> +

[...]
> +static int panel_dbi_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	const struct drm_panel_funcs *panel_dbi_funcs;
> +	struct panel_dbi *priv;
> +	enum panel_dbi_id id;
> +	int ret;
> +
> +	id = (uintptr_t)of_device_get_match_data(dev);
> +
> +	switch (id) {
> +	case PANEL_DBI_TX10D07VM0BAA:
> +		panel_dbi_funcs = &hitachi_tx10d07vm0baa_panel_funcs;
> +		break;
> +
> +	case PANEL_DBI_LH400WV3:
> +		panel_dbi_funcs = &lg_lh400wv3_panel_funcs;
> +		break;
> +
> +	default:
> +		return dev_err_probe(dev, -ENODEV, "Unknown device %d\n", id);
> +	}

This is a bit pointless. The only reason you need that default here is
because you have an enum that is "none" but that PANEL_DBI_NONE is never
even used.

> +
> +	priv = devm_drm_panel_alloc(dev, struct panel_dbi, panel,
> +				    panel_dbi_funcs, DRM_MODE_CONNECTOR_DPI);
> +	if (IS_ERR(priv))
> +		return PTR_ERR(priv);
> +
> +	ret = devm_regulator_bulk_get_const(dev, ARRAY_SIZE(panel_dbi_supplies),
> +					    panel_dbi_supplies, &priv->supplies);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to get supplies\n");
> +
> +	priv->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> +	if (IS_ERR(priv->reset_gpio))
> +		return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
> +				     "Failed to get reset gpio\n");
> +
> +	ret = drm_panel_of_backlight(&priv->panel);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to get backlight\n");
> +
> +	ret = devm_drm_panel_add(dev, &priv->panel);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to add panel\n");
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id panel_dbi_of_match[] = {
> +	{ .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
> +	{ .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },

Why the detour through that PANEL_DB_* enum? You could just pass the
panel funcs pointers directly via .data here.

Also, looking at the enable/disable sequences these are in fact two
different drivers, with the only commonality being that they happen to
be used in the same device. Rolling them both into one driver seems a
bit odd. If you really want to avoid duplication, maybe they should go
into some kind of "simple" or "generic" DBI driver.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 6/6] drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI panel driver

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 12:02 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 10:05:35AM +0300, Svyatoslav Ryhel wrote:
> > Add a driver for panels used in LG Optimus 2X P990. Both panels are 4"
> > WVGA MIPI DBI Type B linked to DRM encoder via RGB to DBI bridge.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  drivers/gpu/drm/panel/Kconfig                 |  14 +
> >  drivers/gpu/drm/panel/Makefile                |   1 +
> >  .../drm/panel/panel-hitachi-tx10d07vm0baa.c   | 396 ++++++++++++++++++
> >  3 files changed, 411 insertions(+)
> >  create mode 100644 drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index 747f47347521a..47962197a9c76 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -273,6 +273,20 @@ config DRM_PANEL_HIMAX_HX8394
> >
> >         If M is selected the module will be called panel-himax-hx8394.
> >
> > +config DRM_PANEL_HITACHI_TX10D07VM0BAA
> > +     tristate "Hitachi TX10D07VM0BAA and LG LH400WV3 MIPI DBI panels"
> > +     depends on OF
> > +     depends on BACKLIGHT_CLASS_DEVICE
> > +     select DRM_MIPI_DBI
> > +     select VIDEOMODE_HELPERS
> > +     help
> > +       Say Y here if you want to enable support for the HITACHI
> > +       TX10D07VM0BAA and LG LH400WV3 MIPI DBI panels found in the
> > +       LG Optimus 2X P990 smartphone.
> > +
> > +       To compile this driver as a module, choose M here: the module will
> > +       be called panel-hitachi-tx10d07vm0baa.
> > +
> >  config DRM_PANEL_HYDIS_HV101HD1
> >       tristate "Hydis HV101HD1 panel"
> >       depends on OF
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index f2c9c80a218f0..414267a49d922 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -27,6 +27,7 @@ obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
> >  obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112B) += panel-himax-hx83112b.o
> >  obj-$(CONFIG_DRM_PANEL_HIMAX_HX83121A) += panel-himax-hx83121a.o
> >  obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
> > +obj-$(CONFIG_DRM_PANEL_HITACHI_TX10D07VM0BAA) += panel-hitachi-tx10d07vm0baa.o
> >  obj-$(CONFIG_DRM_PANEL_HYDIS_HV101HD1) += panel-hydis-hv101hd1.o
> >  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI7807S) += panel-ilitek-ili7807s.o
> >  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI7836A) += panel-ilitek-ili7836a.o
> > diff --git a/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c b/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
> > new file mode 100644
> > index 0000000000000..d2c3b63649288
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-hitachi-tx10d07vm0baa.c
> > @@ -0,0 +1,396 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +
> > +#include <linux/array_size.h>
> > +#include <linux/delay.h>
> > +#include <linux/err.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/media-bus-format.h>
> > +#include <linux/module.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/property.h>
> > +#include <linux/regulator/consumer.h>
> > +
> > +#include <video/mipi_display.h>
> > +
> > +#include <drm/drm_mipi_dbi.h>
> > +#include <drm/drm_modes.h>
> > +#include <drm/drm_of.h>
> > +#include <drm/drm_panel.h>
> > +#include <drm/drm_probe_helper.h>
> > +
> > +enum panel_dbi_id {
> > +     PANEL_DBI_NONE,
> > +     PANEL_DBI_TX10D07VM0BAA,
> > +     PANEL_DBI_LH400WV3,
> > +};
> > +
> > +static const struct regulator_bulk_data panel_dbi_supplies[] = {
> > +     { .supply = "avci" }, { .supply = "iovcc" },
> > +};
> > +
> > +struct panel_dbi {
> > +     struct drm_panel panel;
> > +     struct mipi_dbi *dbi;
> > +
> > +     struct regulator_bulk_data *supplies;
> > +     struct gpio_desc *reset_gpio;
> > +};
> > +
> > +static inline struct panel_dbi *to_panel_dbi(struct drm_panel *panel)
> > +{
> > +     return container_of(panel, struct panel_dbi, panel);
> > +}
> > +
> > +#define panel_dbi_command(priv, cmd, seq...) \
> > +({ \
> > +     const u8 d[] = { seq }; \
> > +     struct drm_panel *panel = &(priv)->panel; \
> > +     struct device *dev = panel->dev; \
> > +     int ret; \
> > +     ret = mipi_dbi_command_stackbuf((priv)->dbi, cmd, d, ARRAY_SIZE(d)); \
> > +     if (ret) \
> > +             dev_err_ratelimited(dev, "error %d when sending command %#02x\n", ret, cmd); \
> > +     ret; \
> > +})
> > +
>
> [...]
> > +static int panel_dbi_probe(struct platform_device *pdev)
> > +{
> > +     struct device *dev = &pdev->dev;
> > +     const struct drm_panel_funcs *panel_dbi_funcs;
> > +     struct panel_dbi *priv;
> > +     enum panel_dbi_id id;
> > +     int ret;
> > +
> > +     id = (uintptr_t)of_device_get_match_data(dev);
> > +
> > +     switch (id) {
> > +     case PANEL_DBI_TX10D07VM0BAA:
> > +             panel_dbi_funcs = &hitachi_tx10d07vm0baa_panel_funcs;
> > +             break;
> > +
> > +     case PANEL_DBI_LH400WV3:
> > +             panel_dbi_funcs = &lg_lh400wv3_panel_funcs;
> > +             break;
> > +
> > +     default:
> > +             return dev_err_probe(dev, -ENODEV, "Unknown device %d\n", id);
> > +     }
>
> This is a bit pointless. The only reason you need that default here is
> because you have an enum that is "none" but that PANEL_DBI_NONE is never
> even used.
>
> > +
> > +     priv = devm_drm_panel_alloc(dev, struct panel_dbi, panel,
> > +                                 panel_dbi_funcs, DRM_MODE_CONNECTOR_DPI);
> > +     if (IS_ERR(priv))
> > +             return PTR_ERR(priv);
> > +
> > +     ret = devm_regulator_bulk_get_const(dev, ARRAY_SIZE(panel_dbi_supplies),
> > +                                         panel_dbi_supplies, &priv->supplies);
> > +     if (ret)
> > +             return dev_err_probe(dev, ret, "Failed to get supplies\n");
> > +
> > +     priv->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> > +     if (IS_ERR(priv->reset_gpio))
> > +             return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
> > +                                  "Failed to get reset gpio\n");
> > +
> > +     ret = drm_panel_of_backlight(&priv->panel);
> > +     if (ret)
> > +             return dev_err_probe(dev, ret, "Failed to get backlight\n");
> > +
> > +     ret = devm_drm_panel_add(dev, &priv->panel);
> > +     if (ret)
> > +             return dev_err_probe(dev, ret, "Failed to add panel\n");
> > +
> > +     platform_set_drvdata(pdev, priv);
> > +
> > +     return 0;
> > +}
> > +
> > +static const struct of_device_id panel_dbi_of_match[] = {
> > +     { .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
> > +     { .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },
>
> Why the detour through that PANEL_DB_* enum? You could just pass the
> panel funcs pointers directly via .data here.
>

Passing API/OPS via .data is discouraged.

> Also, looking at the enable/disable sequences these are in fact two
> different drivers, with the only commonality being that they happen to
> be used in the same device. Rolling them both into one driver seems a
> bit odd.

I did this to simplify maintainance. Both panels are used in the LG
Optimus 2X. My assumption is that LG switched one to another at some
point, hence they share same timings, controls and supplies, but
differ in en/disable sequence. Additionally, these are the the only
DBI Type B-only panels in the kernel, from what I can see.

> If you really want to avoid duplication, maybe they should go
> into some kind of "simple" or "generic" DBI driver.

DBI Type B is not well supported in the kernel.

>
> Thierry

Re: [PATCH v1 6/6] drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI panel driver

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

On Wed, Sep 30, 2026 at 12:08:41PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 12:02 Thierry Reding <thierry.reding@kernel.org> пише:
> > On Wed, Sep 30, 2026 at 10:05:35AM +0300, Svyatoslav Ryhel wrote:
[...]
> > > +static const struct of_device_id panel_dbi_of_match[] = {
> > > +     { .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
> > > +     { .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },
> >
> > Why the detour through that PANEL_DB_* enum? You could just pass the
> > panel funcs pointers directly via .data here.
> >
> 
> Passing API/OPS via .data is discouraged.

No it's not. We do it all the time.

> > Also, looking at the enable/disable sequences these are in fact two
> > different drivers, with the only commonality being that they happen to
> > be used in the same device. Rolling them both into one driver seems a
> > bit odd.
> 
> I did this to simplify maintainance. Both panels are used in the LG
> Optimus 2X. My assumption is that LG switched one to another at some
> point, hence they share same timings, controls and supplies, but
> differ in en/disable sequence. Additionally, these are the the only
> DBI Type B-only panels in the kernel, from what I can see.

That's just one more reason to put them into more of a generic driver,
which would allow people to find it and extend/improve it as needed.

> > If you really want to avoid duplication, maybe they should go
> > into some kind of "simple" or "generic" DBI driver.
> 
> DBI Type B is not well supported in the kernel.

Well, you always start somewhere.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 6/6] drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI panel driver

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 13:23 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 12:08:41PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 12:02 Thierry Reding <thierry.reding@kernel.org> пише:
> > > On Wed, Sep 30, 2026 at 10:05:35AM +0300, Svyatoslav Ryhel wrote:
> [...]
> > > > +static const struct of_device_id panel_dbi_of_match[] = {
> > > > +     { .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
> > > > +     { .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },
> > >
> > > Why the detour through that PANEL_DB_* enum? You could just pass the
> > > panel funcs pointers directly via .data here.
> > >
> >
> > Passing API/OPS via .data is discouraged.
>
> No it's not. We do it all the time.
>

I have had some controversial experience with MFD, with passing cell
composition. If DRM subsystem allows this, I am more then happy to
pass panel ops directly.

> > > Also, looking at the enable/disable sequences these are in fact two
> > > different drivers, with the only commonality being that they happen to
> > > be used in the same device. Rolling them both into one driver seems a
> > > bit odd.
> >
> > I did this to simplify maintainance. Both panels are used in the LG
> > Optimus 2X. My assumption is that LG switched one to another at some
> > point, hence they share same timings, controls and supplies, but
> > differ in en/disable sequence. Additionally, these are the the only
> > DBI Type B-only panels in the kernel, from what I can see.
>
> That's just one more reason to put them into more of a generic driver,
> which would allow people to find it and extend/improve it as needed.
>

This driver cannot be "generic". Both panels don't fall into any
category of being "generic". They are grouped solely cause they share
same timings, controls and supplies (only these 2 panels, other will
definitely differ) and are used in the same device. I have no problems
in splitting them into 2 distinct drivers.

> > > If you really want to avoid duplication, maybe they should go
> > > into some kind of "simple" or "generic" DBI driver.
> >
> > DBI Type B is not well supported in the kernel.
>
> Well, you always start somewhere.
>

I don't think that DBI Type B needs some deep and fundamental support.
Even for its time it does not seem to be common, not saying today.
More a curiosity.

> Thierry

Re: [PATCH v1 6/6] drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI panel driver

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

On Wed, Sep 30, 2026 at 01:34:19PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 13:23 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 12:08:41PM +0300, Svyatoslav Ryhel wrote:
> > > ср, 30 вер. 2026 р. о 12:02 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > On Wed, Sep 30, 2026 at 10:05:35AM +0300, Svyatoslav Ryhel wrote:
> > [...]
> > > > > +static const struct of_device_id panel_dbi_of_match[] = {
> > > > > +     { .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
> > > > > +     { .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },
> > > >
> > > > Why the detour through that PANEL_DB_* enum? You could just pass the
> > > > panel funcs pointers directly via .data here.
> > > >
> > >
> > > Passing API/OPS via .data is discouraged.
> >
> > No it's not. We do it all the time.
> >
> 
> I have had some controversial experience with MFD, with passing cell
> composition. If DRM subsystem allows this, I am more then happy to
> pass panel ops directly.
> 
> > > > Also, looking at the enable/disable sequences these are in fact two
> > > > different drivers, with the only commonality being that they happen to
> > > > be used in the same device. Rolling them both into one driver seems a
> > > > bit odd.
> > >
> > > I did this to simplify maintainance. Both panels are used in the LG
> > > Optimus 2X. My assumption is that LG switched one to another at some
> > > point, hence they share same timings, controls and supplies, but
> > > differ in en/disable sequence. Additionally, these are the the only
> > > DBI Type B-only panels in the kernel, from what I can see.
> >
> > That's just one more reason to put them into more of a generic driver,
> > which would allow people to find it and extend/improve it as needed.
> >
> 
> This driver cannot be "generic". Both panels don't fall into any
> category of being "generic". They are grouped solely cause they share
> same timings, controls and supplies (only these 2 panels, other will
> definitely differ) and are used in the same device. I have no problems
> in splitting them into 2 distinct drivers.

The driver can still be mostly generic. And I suspect that the panels
might have different names for the supplies and controls as well, they
just happen to match in schematics or sources that you used as reference
because they are for the same device.

My point is, you can keep a lot of boilerplate in a generic DBI driver
and then parameterize the things that aren't the same across them. That
gives you the best of both worlds.

The reason why I objected is that you have a very specific name for the
driver file and the second panel doesn't match that at all, so it's
confusing.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 6/6] drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI panel driver

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 13:43 Thierry Reding <thierry.reding@kernel.org> пише:
>
> On Wed, Sep 30, 2026 at 01:34:19PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 13:23 Thierry Reding <thierry.reding@kernel.org> пише:
> > >
> > > On Wed, Sep 30, 2026 at 12:08:41PM +0300, Svyatoslav Ryhel wrote:
> > > > ср, 30 вер. 2026 р. о 12:02 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > > On Wed, Sep 30, 2026 at 10:05:35AM +0300, Svyatoslav Ryhel wrote:
> > > [...]
> > > > > > +static const struct of_device_id panel_dbi_of_match[] = {
> > > > > > +     { .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
> > > > > > +     { .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },
> > > > >
> > > > > Why the detour through that PANEL_DB_* enum? You could just pass the
> > > > > panel funcs pointers directly via .data here.
> > > > >
> > > >
> > > > Passing API/OPS via .data is discouraged.
> > >
> > > No it's not. We do it all the time.
> > >
> >
> > I have had some controversial experience with MFD, with passing cell
> > composition. If DRM subsystem allows this, I am more then happy to
> > pass panel ops directly.
> >
> > > > > Also, looking at the enable/disable sequences these are in fact two
> > > > > different drivers, with the only commonality being that they happen to
> > > > > be used in the same device. Rolling them both into one driver seems a
> > > > > bit odd.
> > > >
> > > > I did this to simplify maintainance. Both panels are used in the LG
> > > > Optimus 2X. My assumption is that LG switched one to another at some
> > > > point, hence they share same timings, controls and supplies, but
> > > > differ in en/disable sequence. Additionally, these are the the only
> > > > DBI Type B-only panels in the kernel, from what I can see.
> > >
> > > That's just one more reason to put them into more of a generic driver,
> > > which would allow people to find it and extend/improve it as needed.
> > >
> >
> > This driver cannot be "generic". Both panels don't fall into any
> > category of being "generic". They are grouped solely cause they share
> > same timings, controls and supplies (only these 2 panels, other will
> > definitely differ) and are used in the same device. I have no problems
> > in splitting them into 2 distinct drivers.
>
> The driver can still be mostly generic. And I suspect that the panels
> might have different names for the supplies and controls as well, they
> just happen to match in schematics or sources that you used as reference
> because they are for the same device.
>
> My point is, you can keep a lot of boilerplate in a generic DBI driver
> and then parameterize the things that aren't the same across them. That
> gives you the best of both worlds.
>
> The reason why I objected is that you have a very specific name for the
> driver file and the second panel doesn't match that at all, so it's
> confusing.
>

Noted. I will split them to remove confusion. I assume that schema can
remain common.

IMHO creating a generic DBI Type B panel driver does not wort it,
especially since these panels are more like non-simple DSI panels and
always require a dedicated en/disable sequence.

> Thierry

Re: [PATCH v1 6/6] drm/panel: Add Hitachi TX10D07VM0BAA and LG LH400WV3-SD04 MIPI DBI panel driver

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]

On Wed, Sep 30, 2026 at 01:48:02PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 13:43 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 01:34:19PM +0300, Svyatoslav Ryhel wrote:
> > > ср, 30 вер. 2026 р. о 13:23 Thierry Reding <thierry.reding@kernel.org> пише:
> > > >
> > > > On Wed, Sep 30, 2026 at 12:08:41PM +0300, Svyatoslav Ryhel wrote:
> > > > > ср, 30 вер. 2026 р. о 12:02 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > > > On Wed, Sep 30, 2026 at 10:05:35AM +0300, Svyatoslav Ryhel wrote:
> > > > [...]
> > > > > > > +static const struct of_device_id panel_dbi_of_match[] = {
> > > > > > > +     { .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
> > > > > > > +     { .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },
> > > > > >
> > > > > > Why the detour through that PANEL_DB_* enum? You could just pass the
> > > > > > panel funcs pointers directly via .data here.
> > > > > >
> > > > >
> > > > > Passing API/OPS via .data is discouraged.
> > > >
> > > > No it's not. We do it all the time.
> > > >
> > >
> > > I have had some controversial experience with MFD, with passing cell
> > > composition. If DRM subsystem allows this, I am more then happy to
> > > pass panel ops directly.
> > >
> > > > > > Also, looking at the enable/disable sequences these are in fact two
> > > > > > different drivers, with the only commonality being that they happen to
> > > > > > be used in the same device. Rolling them both into one driver seems a
> > > > > > bit odd.
> > > > >
> > > > > I did this to simplify maintainance. Both panels are used in the LG
> > > > > Optimus 2X. My assumption is that LG switched one to another at some
> > > > > point, hence they share same timings, controls and supplies, but
> > > > > differ in en/disable sequence. Additionally, these are the the only
> > > > > DBI Type B-only panels in the kernel, from what I can see.
> > > >
> > > > That's just one more reason to put them into more of a generic driver,
> > > > which would allow people to find it and extend/improve it as needed.
> > > >
> > >
> > > This driver cannot be "generic". Both panels don't fall into any
> > > category of being "generic". They are grouped solely cause they share
> > > same timings, controls and supplies (only these 2 panels, other will
> > > definitely differ) and are used in the same device. I have no problems
> > > in splitting them into 2 distinct drivers.
> >
> > The driver can still be mostly generic. And I suspect that the panels
> > might have different names for the supplies and controls as well, they
> > just happen to match in schematics or sources that you used as reference
> > because they are for the same device.
> >
> > My point is, you can keep a lot of boilerplate in a generic DBI driver
> > and then parameterize the things that aren't the same across them. That
> > gives you the best of both worlds.
> >
> > The reason why I objected is that you have a very specific name for the
> > driver file and the second panel doesn't match that at all, so it's
> > confusing.
> >
> 
> Noted. I will split them to remove confusion. I assume that schema can
> remain common.

Works for me.

> IMHO creating a generic DBI Type B panel driver does not wort it,
> especially since these panels are more like non-simple DSI panels and
> always require a dedicated en/disable sequence.

But that's not a great reason. Note that you can have a generic driver
that describes radically different panels. It's all a matter of
parameterization. You can have very different *-supply property names
and enable/disable sequences, all in the same driver. What matters at
the driver level is the general structure (i.e. you're device has a
backlight, one or more power supplies, a DBI command sequence, a reset
GPIO, ...).

You managed to make them work in one driver, whether that's called
panel-dbi.c or panel-hitachi-tx10d07vm0baa.c doesn't matter. If there's
ever a DBI driver that doesn't match the structure of whatever you
introduce, we can improve or add another driver.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]