From: Liu Ying <victor.liu@nxp.com>
i.MX93 SoC mediamix blk-ctrl contains one DISPLAY_MUX register which
configures parallel display format by using the "PARALLEL_DISP_FORMAT"
field. Document the Parallel Display Format Configuration(PDFC) subnode
and add the subnode to example.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
[m.felsch@pengutronix.de: port to v7.0-rc1]
[m.felsch@pengutronix.de: add bus-width]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
.../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 78 ++++++++++++++++++++++
1 file changed, 78 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
index 34aea58094e55365a2f9c86092f637e533f954ff..d828c2e82965c7a4cd69a67136047d83c96b0a35 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
@@ -40,6 +40,58 @@ properties:
minItems: 8
maxItems: 10
+ dpi-bridge:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - nxp,imx91-pdfc
+ - nxp,imx93-pdfc
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port node to receive pixel data.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Output port node to downstream pixel data receivers.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-width:
+ enum: [ 16, 18, 24 ]
+ description:
+ Specify the physical parallel bus width.
+
+ This property is optional if the display bus-width
+ matches the SoC bus-width, e.g. a 18-bit RGB666 (display)
+ is connected and all 18-bit data lines are muxed to the
+ parallel-output pads.
+
+ This property must be set to 18 to cut only the LSBs
+ instead of the MSBs in case a 24-bit RGB888 display is
+ connected and only the lower 18-bit data lanes are muxed
+ to the parallel-output pads.
+
+ required:
+ - port@0
+ - port@1
+
+ required:
+ - compatible
+ - ports
+
allOf:
- if:
properties:
@@ -112,4 +164,30 @@ examples:
clock-names = "apb", "axi", "nic", "disp", "cam",
"pxp", "lcdif", "isi", "csi", "dsi";
#power-domain-cells = <1>;
+
+ dpi-bridge {
+ compatible = "nxp,imx93-pdfc";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pdfc_from_lcdif: endpoint {
+ remote-endpoint = <&lcdif_to_pdfc>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pdfc_to_panel: endpoint {
+ remote-endpoint = <&panel_from_pdfc>;
+ bus-width = <18>;
+ };
+ };
+ };
+ };
};
--
2.47.3
From: Frank Li (AI-BOT) <frank.li@nxp.com> AI bot review and may be useless. This is a device tree bindings patch, not kernel C code. The YAML schema additions look structurally sound. A few observations: > + dpi-bridge: > + type: object > + additionalProperties: false > + > + properties: > + compatible: > + enum: > + - nxp,imx91-pdfc > + - nxp,imx93-pdfc The compatible strings should be documented in a separate vendor prefix file (nxp.yaml) if not already present. Verify they exist in Documentation/devicetree/bindings/vendor-prefixes.yaml. > + ports: > + $ref: /schemas/graph.yaml#/properties/ports > + > + properties: > + port@0: > + $ref: /schemas/graph.yaml#/properties/port > + description: Input port node to receive pixel data. > + > + port@1: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false The port@0 and port@1 both reference graph.yaml but use slightly different schemas ($defs/port-base vs #/properties/port). Ensure this inconsistency is intentional; typically both would use the same reference unless port@1 has special constraints. > + properties: > + bus-width: > + enum: [ 16, 18, 24 ] Line length is acceptable. The bus-width enum values are clear. > + This property must be set to 18 to cut only the LSBs > + instead of the MSBs in case a 24-bit RGB888 display is > + connected and only the lower 18-bit data lanes are muxed > + to the parallel-output pads. Documentation is thorough and explains the non-obvious behavior (LSB vs MSB truncation). Good. Overall: schema is well-structured, example is complete, and documentation is clear. No blocking issues detected.
On 03/03/2026 22:00, Frank Li wrote: > From: Frank Li (AI-BOT) <frank.li@nxp.com> > > AI bot review and may be useless. Then don't post it. Please post useful reviews. ... > > Overall: schema is well-structured, example is complete, and > documentation is clear. No blocking issues detected. What is the point of telling this? Just unnecessary traffic and mailbox pollution. Best regards, Krzysztof
On 03/03/2026 22:00, Frank Li wrote: > From: Frank Li (AI-BOT) <frank.li@nxp.com> > > AI bot review and may be useless. > > This is a device tree bindings patch, not kernel C code. The YAML > schema additions look structurally sound. A few observations: > >> + dpi-bridge: >> + type: object >> + additionalProperties: false >> + >> + properties: >> + compatible: >> + enum: >> + - nxp,imx91-pdfc >> + - nxp,imx93-pdfc > > The compatible strings should be documented in a separate vendor > prefix file (nxp.yaml) if not already present. Verify they exist > in Documentation/devicetree/bindings/vendor-prefixes.yaml. What?!?!? This is nonsense. Also, you are responding to an already reviewed patch. Best regards, Krzysztof
On Wed, Mar 04, 2026 at 04:49:27PM +0100, Krzysztof Kozlowski wrote: > On 03/03/2026 22:00, Frank Li wrote: > > From: Frank Li (AI-BOT) <frank.li@nxp.com> > > > > AI bot review and may be useless. > > > > This is a device tree bindings patch, not kernel C code. The YAML > > schema additions look structurally sound. A few observations: > > > >> + dpi-bridge: > >> + type: object > >> + additionalProperties: false > >> + > >> + properties: > >> + compatible: > >> + enum: > >> + - nxp,imx91-pdfc > >> + - nxp,imx93-pdfc > > > > The compatible strings should be documented in a separate vendor > > prefix file (nxp.yaml) if not already present. Verify they exist > > in Documentation/devicetree/bindings/vendor-prefixes.yaml. > > What?!?!? > > This is nonsense. > > Also, you are responding to an already reviewed patch. Sorry, I tested 22 patches of from imx and sent out intermediate result. Frank > > Best regards, > Krzysztof
© 2016 - 2026 Red Hat, Inc.