[PATCH v4 0/4] drm: mxsfb: Support LCDIF interface bus width

[PATCH v4 0/4] drm: mxsfb: Support LCDIF interface bus width

[Francesco Dolcini]

From: Francesco Dolcini <francesco.dolcini@toradex.com>

The width of the physical LCDIF output bus can differ from the input bus
format advertised by the downstream panel or bridge.

Such a distinction is required when the LCDIF bus width does not match the
width of the downstream display interface. For example, an 18-bit or
16-bit LCDIF bus can drive a 24-bit display by wiring the available color
bits to the appropriate display inputs. Configuring LCDIF solely from the
display's 24-bit format in this case selects the wrong LCD_DATABUS_WIDTH
mode, changing the color-bit assignment on the LCD_DATA pins and resulting
in incorrect colors.

Use the common OF graph endpoint bus-width property to describe the width
of the physical LCDIF output bus. Make the mxsfb driver derive the
corresponding media bus format from this property and use it in preference
to the format reported by the downstream display. When the property is
absent, the existing behavior is preserved.

Set the endpoint bus width for the Colibri iMX6ULL and Colibri iMX7 boards,
which route an 18-bit LCD interface.

v4:
 - use /schemas/graph.yaml#/$defs/port-base
 - add r-b and t-b tags
v3: https://lore.kernel.org/all/20260812132954.148571-1-francesco@dolcini.it/
 - use video-interfaces.yaml
v2: https://lore.kernel.org/all/20260723093813.180089-1-francesco@dolcini.it/
 - use the common bus-width property instead of the legacy interface-pix-fmt
v1: https://lore.kernel.org/all/20260717121847.488148-1-francesco@dolcini.it/

Francesco Dolcini (4):
  dt-bindings: lcdif: Add endpoint bus-width property
  drm: mxsfb: Add optional DPI output bus-width configuration
  ARM: dts: imx6ull-colibri: Set LCDIF bus-width
  ARM: dts: imx7-colibri: Set LCDIF bus-width

 .../bindings/display/fsl,lcdif.yaml           | 12 +++++++++-
 .../arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi |  1 +
 arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi   |  1 +
 drivers/gpu/drm/mxsfb/mxsfb_drv.c             | 24 +++++++++++++++++++
 drivers/gpu/drm/mxsfb/mxsfb_drv.h             |  2 ++
 drivers/gpu/drm/mxsfb/mxsfb_kms.c             | 12 ++++++++++
 6 files changed, 51 insertions(+), 1 deletion(-)

-- 
2.47.3

[PATCH v4 1/4] dt-bindings: lcdif: Add endpoint bus-width property

[Francesco Dolcini]

From: Francesco Dolcini <francesco.dolcini@toradex.com>

The DPI output of the LCD interface can be configured with a bus width
of 16, 18, or 24 bits. Introduce a bus-width property to the output
endpoint, specifying the number of parallel RGB bits connected.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
v4: use /schemas/graph.yaml#/$defs/port-base
v3: use video-interfaces.yaml
v2: use the common bus-width property instead of the legacy interface-pix-fmt
---
 .../devicetree/bindings/display/fsl,lcdif.yaml       | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 2dd0411ec651..89cea0c14cf1 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -68,9 +68,19 @@ properties:
     maxItems: 1
 
   port:
-    $ref: /schemas/graph.yaml#/properties/port
+    $ref: /schemas/graph.yaml#/$defs/port-base
+    unevaluatedProperties: false
     description: The LCDIF output port
 
+    properties:
+      endpoint:
+        $ref: /schemas/media/video-interfaces.yaml
+        unevaluatedProperties: false
+
+        properties:
+          bus-width:
+            enum: [ 16, 18, 24 ]
+
   display:
     $ref: /schemas/types.yaml#/definitions/phandle
     description: phandle to display panel
-- 
2.47.3

[PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Francesco Dolcini]

From: Francesco Dolcini <francesco.dolcini@toradex.com>

LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
format reported by the downstream panel or bridge describes the display
input, but it does not describe how the LCDIF data pins are physically
wired on the board.

These can differ. For example, a 16-bit LCDIF bus can be connected to a
24-bit display by wiring the available color bits to the corresponding
display inputs. In that case, using the display's 24-bit format to
configure LCDIF selects the wrong data-bus mode and changes the assignment
of color bits on the LCD_DATA pins.

Read the optional bus-width endpoint property from the LCDIF output port
and use it to select the media bus format used to configure LCDIF. This
allows the LCDIF bus mode to describe the physical interface
independently of the downstream display format.

When the optional property is absent, or it has an invalid value, continue
using the format reported by the downstream display device, preserving
the existing behavior. The code is not validating the DT for
correctness and just fall back to the previous behavior in case of
errors.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa6UL[L]x
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
v4: add r-b and t-b tags
v3: improve commit message and make it clear that the code assumes that
    the DT is correct, when the DT contains an invalid property value,
    the code safely fall-back to the previous behavior
v2: use the common bus-width property instead of the legacy interface-pix-fmt
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 24 ++++++++++++++++++++++++
 drivers/gpu/drm/mxsfb/mxsfb_drv.h |  2 ++
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 12 ++++++++++++
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 8b4a500347fb..f8ecc8bbd63c 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -12,7 +12,10 @@
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
+#include <linux/media-bus-format.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
 #include <linux/platform_device.h>
 #include <linux/property.h>
 #include <linux/pm_runtime.h>
@@ -211,7 +214,10 @@ static int mxsfb_load(struct drm_device *drm,
 		      const struct mxsfb_devdata *devdata)
 {
 	struct platform_device *pdev = to_platform_device(drm->dev);
+	struct device_node *np = pdev->dev.of_node;
 	struct mxsfb_drm_private *mxsfb;
+	struct device_node *ep;
+	u32 bus_width = 0;
 	int ret;
 
 	mxsfb = devm_kzalloc(&pdev->dev, sizeof(*mxsfb), GFP_KERNEL);
@@ -238,6 +244,24 @@ static int mxsfb_load(struct drm_device *drm,
 	if (IS_ERR(mxsfb->clk_disp_axi))
 		mxsfb->clk_disp_axi = NULL;
 
+	ep = of_graph_get_next_endpoint(np, NULL);
+	if (ep) {
+		of_property_read_u32(ep, "bus-width", &bus_width);
+		of_node_put(ep);
+	}
+
+	switch (bus_width) {
+	case 16:
+		mxsfb->bus_format = MEDIA_BUS_FMT_RGB565_1X16;
+		break;
+	case 18:
+		mxsfb->bus_format = MEDIA_BUS_FMT_RGB666_1X18;
+		break;
+	case 24:
+		mxsfb->bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+		break;
+	}
+
 	ret = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
 	if (ret)
 		return ret;
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index d160d921b25f..bdc47ce5be79 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -46,6 +46,8 @@ struct mxsfb_drm_private {
 	struct drm_connector		*connector;
 	struct drm_bridge		*bridge;
 
+	u32				bus_format;
+
 	bool				crc_active;
 };
 
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index d8ebebc5314b..1d78c486d147 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -386,6 +386,18 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
 	if (!bus_format)
 		bus_format = MEDIA_BUS_FMT_RGB888_1X24;
 
+	/*
+	 * Prefer the bus format derived from the OF graph endpoint "bus-width"
+	 * property when available. Otherwise, use the bus format reported by
+	 * the downstream bridge or panel.
+	 *
+	 * This supports mismatched display and interface bus widths, such as
+	 * a 24-bit panel connected through an 18-bit interface or an 18-bit
+	 * panel connected through a 24-bit interface.
+	 */
+	if (mxsfb->bus_format)
+		bus_format = mxsfb->bus_format;
+
 	mxsfb_crtc_mode_set_nofb(mxsfb, bridge_state, bus_format);
 
 	/* Write cur_buf as well to avoid an initial corrupt frame */
-- 
2.47.3

[PATCH v4 3/4] ARM: dts: imx6ull-colibri: Set LCDIF bus-width

[Francesco Dolcini]

From: Francesco Dolcini <francesco.dolcini@toradex.com>

The lcd DPI interface on colibri imx6ull uses a 18-bit width bus, set
the bus-width property accordingly.

Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
v4: no changes
v3: no changes
v2: use the common bus-width property instead of the legacy interface-pix-fmt
---
 arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
index ec3c1e7301f4..1eb1cf2d7395 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
@@ -229,6 +229,7 @@ &lcdif {
 
 	port {
 		lcdif_out: endpoint {
+			bus-width = <18>;
 			remote-endpoint = <&lcd_panel_in>;
 		};
 	};
-- 
2.47.3

[PATCH v4 4/4] ARM: dts: imx7-colibri: Set LCDIF bus-width

[Francesco Dolcini]

From: Francesco Dolcini <francesco.dolcini@toradex.com>

The lcd DPI interface on colibri imx7 uses a 18-bit width bus, set
the bus-width property accordingly.

Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
v4: no changes
v3: no changes
v2: use the common bus-width property instead of the legacy interface-pix-fmt
---
 arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi
index 8666dcd7fe97..c4088d3c5ab1 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi
@@ -537,6 +537,7 @@ &lcdif {
 
 	port {
 		lcdif_out: endpoint {
+			bus-width = <18>;
 			remote-endpoint = <&lcd_panel_in>;
 		};
 	};
-- 
2.47.3

Re: [PATCH v4 1/4] dt-bindings: lcdif: Add endpoint bus-width property

[Alexander Stein]

Am Donnerstag, 13. August 2026, 11:28:31 CEST schrieb Francesco Dolcini:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
> 
> The DPI output of the LCD interface can be configured with a bus width
> of 16, 18, or 24 bits. Introduce a bus-width property to the output
> endpoint, specifying the number of parallel RGB bits connected.
> 
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>

Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com>

> ---
> v4: use /schemas/graph.yaml#/$defs/port-base
> v3: use video-interfaces.yaml
> v2: use the common bus-width property instead of the legacy interface-pix-fmt
> ---
>  .../devicetree/bindings/display/fsl,lcdif.yaml       | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index 2dd0411ec651..89cea0c14cf1 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -68,9 +68,19 @@ properties:
>      maxItems: 1
>  
>    port:
> -    $ref: /schemas/graph.yaml#/properties/port
> +    $ref: /schemas/graph.yaml#/$defs/port-base
> +    unevaluatedProperties: false
>      description: The LCDIF output port
>  
> +    properties:
> +      endpoint:
> +        $ref: /schemas/media/video-interfaces.yaml
> +        unevaluatedProperties: false
> +
> +        properties:
> +          bus-width:
> +            enum: [ 16, 18, 24 ]
> +
>    display:
>      $ref: /schemas/types.yaml#/definitions/phandle
>      description: phandle to display panel
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v4 1/4] dt-bindings: lcdif: Add endpoint bus-width property

[Krzysztof Kozlowski]

On Thu, Aug 13, 2026 at 11:28:31AM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
> 
> The DPI output of the LCD interface can be configured with a bus width
> of 16, 18, or 24 bits. Introduce a bus-width property to the output
> endpoint, specifying the number of parallel RGB bits connected.
> 
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
> ---
> v4: use /schemas/graph.yaml#/$defs/port-base
> v3: use video-interfaces.yaml
> v2: use the common bus-width property instead of the legacy interface-pix-fmt
> ---
>  .../devicetree/bindings/display/fsl,lcdif.yaml       | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Frank Li]

On Thu, Aug 13, 2026 at 11:28:32AM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
> format reported by the downstream panel or bridge describes the display
> input, but it does not describe how the LCDIF data pins are physically
> wired on the board.
>
> These can differ. For example, a 16-bit LCDIF bus can be connected to a
> 24-bit display by wiring the available color bits to the corresponding
> display inputs. In that case, using the display's 24-bit format to
> configure LCDIF selects the wrong data-bus mode and changes the assignment
> of color bits on the LCD_DATA pins.
>
> Read the optional bus-width endpoint property from the LCDIF output port
> and use it to select the media bus format used to configure LCDIF. This
> allows the LCDIF bus mode to describe the physical interface
> independently of the downstream display format.
>
> When the optional property is absent, or it has an invalid value, continue
> using the format reported by the downstream display device, preserving
> the existing behavior. The code is not validating the DT for
> correctness and just fall back to the previous behavior in case of
> errors.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa6UL[L]x
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
> ---

Marek Vasut & Stefan Agner:

	Are you pick this patches?

Frank

> v4: add r-b and t-b tags
> v3: improve commit message and make it clear that the code assumes that
>     the DT is correct, when the DT contains an invalid property value,
>     the code safely fall-back to the previous behavior
> v2: use the common bus-width property instead of the legacy interface-pix-fmt
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 24 ++++++++++++++++++++++++
>  drivers/gpu/drm/mxsfb/mxsfb_drv.h |  2 ++
>  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 12 ++++++++++++
>  3 files changed, 38 insertions(+)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 8b4a500347fb..f8ecc8bbd63c 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -12,7 +12,10 @@
>  #include <linux/clk.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/io.h>
> +#include <linux/media-bus-format.h>
>  #include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_graph.h>
>  #include <linux/platform_device.h>
>  #include <linux/property.h>
>  #include <linux/pm_runtime.h>
> @@ -211,7 +214,10 @@ static int mxsfb_load(struct drm_device *drm,
>  		      const struct mxsfb_devdata *devdata)
>  {
>  	struct platform_device *pdev = to_platform_device(drm->dev);
> +	struct device_node *np = pdev->dev.of_node;
>  	struct mxsfb_drm_private *mxsfb;
> +	struct device_node *ep;
> +	u32 bus_width = 0;
>  	int ret;
>
>  	mxsfb = devm_kzalloc(&pdev->dev, sizeof(*mxsfb), GFP_KERNEL);
> @@ -238,6 +244,24 @@ static int mxsfb_load(struct drm_device *drm,
>  	if (IS_ERR(mxsfb->clk_disp_axi))
>  		mxsfb->clk_disp_axi = NULL;
>
> +	ep = of_graph_get_next_endpoint(np, NULL);
> +	if (ep) {
> +		of_property_read_u32(ep, "bus-width", &bus_width);
> +		of_node_put(ep);
> +	}
> +
> +	switch (bus_width) {
> +	case 16:
> +		mxsfb->bus_format = MEDIA_BUS_FMT_RGB565_1X16;
> +		break;
> +	case 18:
> +		mxsfb->bus_format = MEDIA_BUS_FMT_RGB666_1X18;
> +		break;
> +	case 24:
> +		mxsfb->bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> +		break;
> +	}
> +
>  	ret = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
>  	if (ret)
>  		return ret;
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> index d160d921b25f..bdc47ce5be79 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> @@ -46,6 +46,8 @@ struct mxsfb_drm_private {
>  	struct drm_connector		*connector;
>  	struct drm_bridge		*bridge;
>
> +	u32				bus_format;
> +
>  	bool				crc_active;
>  };
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> index d8ebebc5314b..1d78c486d147 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> @@ -386,6 +386,18 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
>  	if (!bus_format)
>  		bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>
> +	/*
> +	 * Prefer the bus format derived from the OF graph endpoint "bus-width"
> +	 * property when available. Otherwise, use the bus format reported by
> +	 * the downstream bridge or panel.
> +	 *
> +	 * This supports mismatched display and interface bus widths, such as
> +	 * a 24-bit panel connected through an 18-bit interface or an 18-bit
> +	 * panel connected through a 24-bit interface.
> +	 */
> +	if (mxsfb->bus_format)
> +		bus_format = mxsfb->bus_format;
> +
>  	mxsfb_crtc_mode_set_nofb(mxsfb, bridge_state, bus_format);
>
>  	/* Write cur_buf as well to avoid an initial corrupt frame */
> --
> 2.47.3
>
>

Re: [PATCH v4 0/4] drm: mxsfb: Support LCDIF interface bus width

[Francesco Dolcini]

+ some more DRM maintainers/reviewers

Hello,
just a gentle ping to the DRM bridge maintainers.

On Thu, Aug 13, 2026 at 11:28:30AM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
> 
> The width of the physical LCDIF output bus can differ from the input bus
> format advertised by the downstream panel or bridge.
> 
> Such a distinction is required when the LCDIF bus width does not match the
> width of the downstream display interface. For example, an 18-bit or
> 16-bit LCDIF bus can drive a 24-bit display by wiring the available color
> bits to the appropriate display inputs. Configuring LCDIF solely from the
> display's 24-bit format in this case selects the wrong LCD_DATABUS_WIDTH
> mode, changing the color-bit assignment on the LCD_DATA pins and resulting
> in incorrect colors.
> 
> Use the common OF graph endpoint bus-width property to describe the width
> of the physical LCDIF output bus. Make the mxsfb driver derive the
> corresponding media bus format from this property and use it in preference
> to the format reported by the downstream display. When the property is
> absent, the existing behavior is preserved.
> 
> Set the endpoint bus width for the Colibri iMX6ULL and Colibri iMX7 boards,
> which route an 18-bit LCD interface.

The first two patches in this series should go through drm-misc-next.
Please let me know if any changes are still needed. Otherwise, could they be
picked up?

Thanks,
Francesco

Re: [PATCH v4 1/4] dt-bindings: lcdif: Add endpoint bus-width property

[Luca Ceresoli]

On Thu, 13 Aug 2026 11:28:31 +0200, Francesco Dolcini <francesco@dolcini.it> wrote:
> The DPI output of the LCD interface can be configured with a bus width
> of 16, 18, or 24 bits. Introduce a bus-width property to the output
> endpoint, specifying the number of parallel RGB bits connected.

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

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

Re: [PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Luca Ceresoli]

Hi Francesco,

> LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
> format reported by the downstream panel or bridge describes the display
> input, but it does not describe how the LCDIF data pins are physically
> wired on the board.
>
> These can differ. For example, a 16-bit LCDIF bus can be connected to a
> 24-bit display by wiring the available color bits to the corresponding
> display inputs. In that case, using the display's 24-bit format to
> configure LCDIF selects the wrong data-bus mode and changes the assignment
> of color bits on the LCD_DATA pins.
>
> Read the optional bus-width endpoint property from the LCDIF output port
> and use it to select the media bus format used to configure LCDIF. This
> allows the LCDIF bus mode to describe the physical interface
> independently of the downstream display format.
>
> When the optional property is absent, or it has an invalid value, continue
> using the format reported by the downstream display device, preserving
> the existing behavior. The code is not validating the DT for
> correctness and just fall back to the previous behavior in case of
> errors.

Why? Generally speaking errors are better spotted immediately, not ignored
silently.

Otherwise looks good. I also tested on i.MX8MP with no regressions.

Luca

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

Re: [PATCH v4 3/4] ARM: dts: imx6ull-colibri: Set LCDIF bus-width

[Luca Ceresoli]

Hi Francesco,

> The lcd DPI interface on colibri imx6ull uses a 18-bit width bus, set
> the bus-width property accordingly.
>
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> diff --git a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
> index ec3c1e7301f4..1eb1cf2d7395 100644
> --- a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
> +++ b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
> @@ -229,6 +229,7 @@ &lcdif {
>
>  	port {
>  		lcdif_out: endpoint {
> +			bus-width = <18>;

I don't know the hardware in detail, but the datasheet [0] mentions 16, 18
and 24 bits, and says "Up to 24-bit color (18-bit recommended)". More
details in ection 5.6.1.

This patch would force 18 bits, but "recommended" suggests 24 bits makes
sense in some cases, no?

Can you elaborate on this?

Same for patch 4.

[0] https://docs.toradex.com/104446-colibri-arm-som-imx6ull-datasheet.pdf

Luca

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

Re: [PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Francesco Dolcini]

Hello Luca,

On Wed, Sep 16, 2026 at 10:42:13AM +0200, Luca Ceresoli wrote:
> > LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
> > format reported by the downstream panel or bridge describes the display
> > input, but it does not describe how the LCDIF data pins are physically
> > wired on the board.
> >
> > These can differ. For example, a 16-bit LCDIF bus can be connected to a
> > 24-bit display by wiring the available color bits to the corresponding
> > display inputs. In that case, using the display's 24-bit format to
> > configure LCDIF selects the wrong data-bus mode and changes the assignment
> > of color bits on the LCD_DATA pins.
> >
> > Read the optional bus-width endpoint property from the LCDIF output port
> > and use it to select the media bus format used to configure LCDIF. This
> > allows the LCDIF bus mode to describe the physical interface
> > independently of the downstream display format.
> >
> > When the optional property is absent, or it has an invalid value, continue
> > using the format reported by the downstream display device, preserving
> > the existing behavior. The code is not validating the DT for
> > correctness and just fall back to the previous behavior in case of
> > errors.
> 
> Why? Generally speaking errors are better spotted immediately, not ignored
> silently.

My understanding is that the C driver code should not validate the DT
and that this is the general recommendation when parsing properties from
the DT.

The DT checker is going to spot errors in the DT even earlier and in a
static way.

So the decision is to just fall-back to the previous driver behavior
when this property was not supported at all.

Francesco

Re: [PATCH v4 3/4] ARM: dts: imx6ull-colibri: Set LCDIF bus-width

[Francesco Dolcini]

Hi Luca,
thanks for the review.

On Wed, Sep 16, 2026 at 10:42:13AM +0200, Luca Ceresoli wrote:
> > The lcd DPI interface on colibri imx6ull uses a 18-bit width bus, set
> > the bus-width property accordingly.
> >
> > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
> >
> > diff --git a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
> > index ec3c1e7301f4..1eb1cf2d7395 100644
> > --- a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
> > +++ b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
> > @@ -229,6 +229,7 @@ &lcdif {
> >
> >  	port {
> >  		lcdif_out: endpoint {
> > +			bus-width = <18>;
> 
> I don't know the hardware in detail, but the datasheet [0] mentions 16, 18
> and 24 bits, and says "Up to 24-bit color (18-bit recommended)". More
> details in ection 5.6.1.
> 
> This patch would force 18 bits, but "recommended" suggests 24 bits makes
> sense in some cases, no?
> 
> Can you elaborate on this?

The colibri family standard defines only 18-bit for the parallel RGB
interface on the edge connector, the additional 6-bit are mapped on
different pins that are not on fixed position, depend on the actual SoM
and can also be not present at all. The standard/generic colibri family
carrier boards can only rely on the 18-bits being available therefore.

24-bit is possible and makes sense only on a specific combo
carrier+module, and not as a generic SoM feature. Assuming you would
have such combo you should just override the property on the carrier
board dts file deviating from the standard colibri family.

let me know if you want such detailed explanation in the commit message

Francesco

Re: [PATCH v4 3/4] ARM: dts: imx6ull-colibri: Set LCDIF bus-width

[Luca Ceresoli]

Hi Francesco,

On Wed Sep 16, 2026 at 11:22 AM CEST, Francesco Dolcini wrote:
> Hi Luca,
> thanks for the review.
>
> On Wed, Sep 16, 2026 at 10:42:13AM +0200, Luca Ceresoli wrote:
>> > The lcd DPI interface on colibri imx6ull uses a 18-bit width bus, set
>> > the bus-width property accordingly.
>> >
>> > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
>> >
>> > diff --git a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
>> > index ec3c1e7301f4..1eb1cf2d7395 100644
>> > --- a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
>> > +++ b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
>> > @@ -229,6 +229,7 @@ &lcdif {
>> >
>> >  	port {
>> >  		lcdif_out: endpoint {
>> > +			bus-width = <18>;
>>
>> I don't know the hardware in detail, but the datasheet [0] mentions 16, 18
>> and 24 bits, and says "Up to 24-bit color (18-bit recommended)". More
>> details in ection 5.6.1.
>>
>> This patch would force 18 bits, but "recommended" suggests 24 bits makes
>> sense in some cases, no?
>>
>> Can you elaborate on this?
>
> The colibri family standard defines only 18-bit for the parallel RGB
> interface on the edge connector, the additional 6-bit are mapped on
> different pins that are not on fixed position, depend on the actual SoM
> and can also be not present at all. The standard/generic colibri family
> carrier boards can only rely on the 18-bits being available therefore.
>
> 24-bit is possible and makes sense only on a specific combo
> carrier+module, and not as a generic SoM feature. Assuming you would
> have such combo you should just override the property on the carrier
> board dts file deviating from the standard colibri family.

Ah, that's clear now, thanks!

> let me know if you want such detailed explanation in the commit message

Yes please. With that added you can add:
+Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

Same for patch 4.

Luca

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

Re: [PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Luca Ceresoli]

On Wed Sep 16, 2026 at 11:15 AM CEST, Francesco Dolcini wrote:
> Hello Luca,
>
> On Wed, Sep 16, 2026 at 10:42:13AM +0200, Luca Ceresoli wrote:
>> > LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
>> > format reported by the downstream panel or bridge describes the display
>> > input, but it does not describe how the LCDIF data pins are physically
>> > wired on the board.
>> >
>> > These can differ. For example, a 16-bit LCDIF bus can be connected to a
>> > 24-bit display by wiring the available color bits to the corresponding
>> > display inputs. In that case, using the display's 24-bit format to
>> > configure LCDIF selects the wrong data-bus mode and changes the assignment
>> > of color bits on the LCD_DATA pins.
>> >
>> > Read the optional bus-width endpoint property from the LCDIF output port
>> > and use it to select the media bus format used to configure LCDIF. This
>> > allows the LCDIF bus mode to describe the physical interface
>> > independently of the downstream display format.
>> >
>> > When the optional property is absent, or it has an invalid value, continue
>> > using the format reported by the downstream display device, preserving
>> > the existing behavior. The code is not validating the DT for
>> > correctness and just fall back to the previous behavior in case of
>> > errors.
>>
>> Why? Generally speaking errors are better spotted immediately, not ignored
>> silently.
>
> My understanding is that the C driver code should not validate the DT
> and that this is the general recommendation when parsing properties from
> the DT.
>
> The DT checker is going to spot errors in the DT even earlier and in a
> static way.

Drivers typically check for invalid values.

And people writing their private dts can do mistakes and not run the static
checks. Bad on their side, sure, but having a runtime error would be useful
there.

Also consider potential regressions. Say someone has an invalid value in
their product, say bus-width = <15>, which works because the default 18
which gets used as a fallback happens to be the correct value for their
hardware. Some years later we implement the new bus-width = <15>, and then
that user upgrades to a newer kernel and their display won't work because
it will start using that incorrect bus-witch = <15>. Better stopping this
before it starts, IMO.

Luca

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

Re: [PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Francesco Dolcini]

On Wed, Sep 16, 2026 at 01:19:08PM +0200, Luca Ceresoli wrote:
> On Wed Sep 16, 2026 at 11:15 AM CEST, Francesco Dolcini wrote:
> > Hello Luca,
> >
> > On Wed, Sep 16, 2026 at 10:42:13AM +0200, Luca Ceresoli wrote:
> >> > LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
> >> > format reported by the downstream panel or bridge describes the display
> >> > input, but it does not describe how the LCDIF data pins are physically
> >> > wired on the board.
> >> >
> >> > These can differ. For example, a 16-bit LCDIF bus can be connected to a
> >> > 24-bit display by wiring the available color bits to the corresponding
> >> > display inputs. In that case, using the display's 24-bit format to
> >> > configure LCDIF selects the wrong data-bus mode and changes the assignment
> >> > of color bits on the LCD_DATA pins.
> >> >
> >> > Read the optional bus-width endpoint property from the LCDIF output port
> >> > and use it to select the media bus format used to configure LCDIF. This
> >> > allows the LCDIF bus mode to describe the physical interface
> >> > independently of the downstream display format.
> >> >
> >> > When the optional property is absent, or it has an invalid value, continue
> >> > using the format reported by the downstream display device, preserving
> >> > the existing behavior. The code is not validating the DT for
> >> > correctness and just fall back to the previous behavior in case of
> >> > errors.
> >>
> >> Why? Generally speaking errors are better spotted immediately, not ignored
> >> silently.
> >
> > My understanding is that the C driver code should not validate the DT
> > and that this is the general recommendation when parsing properties from
> > the DT.
> >
> > The DT checker is going to spot errors in the DT even earlier and in a
> > static way.
> 
> Drivers typically check for invalid values.
> 
> And people writing their private dts can do mistakes and not run the static
> checks. Bad on their side, sure, but having a runtime error would be useful
> there.

Understood. I would personally not do it. I can add the required error
checking code. No other DRM maintainer/reviewer commented so far, so I
am taking this as a request.

What should I do in case there is an invalid value? Fail or have a
warning message?

> Also consider potential regressions. Say someone has an invalid value in
> their product, say bus-width = <15>, which works because the default 18
> which gets used as a fallback happens to be the correct value for their
> hardware. Some years later we implement the new bus-width = <15>, and then
> that user upgrades to a newer kernel and their display won't work because
> it will start using that incorrect bus-witch = <15>. Better stopping this
> before it starts, IMO.

I do not see this situation honestly, if you have a wrong value, e.g. 15
bits, before this patch is ignored, and after this patch is also
ignored ...

The default in the code is equivalent to the bus-width property not
present, and therefore we use whatever is coming from the panel aka the
next bridge.

Francesco

Re: [PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Luca Ceresoli]

On Wed Sep 16, 2026 at 1:43 PM CEST, Francesco Dolcini wrote:
> On Wed, Sep 16, 2026 at 01:19:08PM +0200, Luca Ceresoli wrote:
>> On Wed Sep 16, 2026 at 11:15 AM CEST, Francesco Dolcini wrote:
>> > Hello Luca,
>> >
>> > On Wed, Sep 16, 2026 at 10:42:13AM +0200, Luca Ceresoli wrote:
>> >> > LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
>> >> > format reported by the downstream panel or bridge describes the display
>> >> > input, but it does not describe how the LCDIF data pins are physically
>> >> > wired on the board.
>> >> >
>> >> > These can differ. For example, a 16-bit LCDIF bus can be connected to a
>> >> > 24-bit display by wiring the available color bits to the corresponding
>> >> > display inputs. In that case, using the display's 24-bit format to
>> >> > configure LCDIF selects the wrong data-bus mode and changes the assignment
>> >> > of color bits on the LCD_DATA pins.
>> >> >
>> >> > Read the optional bus-width endpoint property from the LCDIF output port
>> >> > and use it to select the media bus format used to configure LCDIF. This
>> >> > allows the LCDIF bus mode to describe the physical interface
>> >> > independently of the downstream display format.
>> >> >
>> >> > When the optional property is absent, or it has an invalid value, continue
>> >> > using the format reported by the downstream display device, preserving
>> >> > the existing behavior. The code is not validating the DT for
>> >> > correctness and just fall back to the previous behavior in case of
>> >> > errors.
>> >>
>> >> Why? Generally speaking errors are better spotted immediately, not ignored
>> >> silently.
>> >
>> > My understanding is that the C driver code should not validate the DT
>> > and that this is the general recommendation when parsing properties from
>> > the DT.
>> >
>> > The DT checker is going to spot errors in the DT even earlier and in a
>> > static way.
>>
>> Drivers typically check for invalid values.
>>
>> And people writing their private dts can do mistakes and not run the static
>> checks. Bad on their side, sure, but having a runtime error would be useful
>> there.
>
> Understood. I would personally not do it. I can add the required error
> checking code. No other DRM maintainer/reviewer commented so far, so I
> am taking this as a request.
>
> What should I do in case there is an invalid value? Fail or have a
> warning message?

Just fail. You are in the probe path, so it's OK.

>> Also consider potential regressions. Say someone has an invalid value in
>> their product, say bus-width = <15>, which works because the default 18
>> which gets used as a fallback happens to be the correct value for their
>> hardware. Some years later we implement the new bus-width = <15>, and then
>> that user upgrades to a newer kernel and their display won't work because
>> it will start using that incorrect bus-witch = <15>. Better stopping this
>> before it starts, IMO.
>
> I do not see this situation honestly, if you have a wrong value, e.g. 15
> bits, before this patch is ignored, and after this patch is also
> ignored ...

There is no problem with the code in this patch alone.

The problem is when in two years in the future we do implement 15
bits. (That's an example to explain the principle, I don't expect it to
happen with this driver.) But imagine in the future we add:

	switch (bus_width) {
    +	case 15:
    +		mxsfb->bus_format = MEDIA_BUS_FMT_RGB555_1X15;
    +		break;
	case 16:
		mxsfb->bus_format = MEDIA_BUS_FMT_RGB565_1X16;
		break;

At that point the device in the wild with the incorrect 'bus-width = <15>'
will start using RGB555 and fail, because they really have a 18 bit panel
which worked thanks to the automagic "if DT is wrong, let's go with the
default". That's a regression for that device.

Reporting an error from day 0 means 'bus-width = <15>' will be blocked, the
device won't probe and the mistake in the device tree gets fixed before
shipping.

I hope it's clearer now.

Cheers,
Luca

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

Re: [PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Luca Ceresoli]

On Wed Sep 16, 2026 at 4:30 PM CEST, Luca Ceresoli wrote:
> On Wed Sep 16, 2026 at 1:43 PM CEST, Francesco Dolcini wrote:
>> On Wed, Sep 16, 2026 at 01:19:08PM +0200, Luca Ceresoli wrote:
>>> On Wed Sep 16, 2026 at 11:15 AM CEST, Francesco Dolcini wrote:
>>> > Hello Luca,
>>> >
>>> > On Wed, Sep 16, 2026 at 10:42:13AM +0200, Luca Ceresoli wrote:
>>> >> > LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
>>> >> > format reported by the downstream panel or bridge describes the display
>>> >> > input, but it does not describe how the LCDIF data pins are physically
>>> >> > wired on the board.
>>> >> >
>>> >> > These can differ. For example, a 16-bit LCDIF bus can be connected to a
>>> >> > 24-bit display by wiring the available color bits to the corresponding
>>> >> > display inputs. In that case, using the display's 24-bit format to
>>> >> > configure LCDIF selects the wrong data-bus mode and changes the assignment
>>> >> > of color bits on the LCD_DATA pins.
>>> >> >
>>> >> > Read the optional bus-width endpoint property from the LCDIF output port
>>> >> > and use it to select the media bus format used to configure LCDIF. This
>>> >> > allows the LCDIF bus mode to describe the physical interface
>>> >> > independently of the downstream display format.
>>> >> >
>>> >> > When the optional property is absent, or it has an invalid value, continue
>>> >> > using the format reported by the downstream display device, preserving
>>> >> > the existing behavior. The code is not validating the DT for
>>> >> > correctness and just fall back to the previous behavior in case of
>>> >> > errors.
>>> >>
>>> >> Why? Generally speaking errors are better spotted immediately, not ignored
>>> >> silently.
>>> >
>>> > My understanding is that the C driver code should not validate the DT
>>> > and that this is the general recommendation when parsing properties from
>>> > the DT.
>>> >
>>> > The DT checker is going to spot errors in the DT even earlier and in a
>>> > static way.

Ah, I forgot... I fully agree static build-time checks are way better than
runtime error checking code. But they are not done as a mandatory and
unconditional step during a build, and so not everybody runs them. Moreover
checks are added over time, so even if all checks pass today some might
fail in the future.

As a result there are plenty of devices out there with invalid dtbs, and
they just work by chance.

It's the hard reality I'm afraid. :(

Luca

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