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.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
[m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++
1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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
@@ -26,6 +26,12 @@ properties:
reg:
maxItems: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
'#power-domain-cells':
const: 1
@@ -40,6 +46,60 @@ properties:
minItems: 8
maxItems: 10
+ bridge@60:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: nxp,imx93-pdfc
+
+ reg:
+ maxItems: 1
+
+ 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/graph.yaml#/$defs/endpoint-base
+ 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 lanes 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
+ - reg
+ - ports
+
allOf:
- if:
properties:
@@ -81,9 +141,12 @@ allOf:
- const: isi
- const: csi
- const: dsi
+
required:
- compatible
- reg
+ - '#address-cells'
+ - '#size-cells'
- power-domains
- clocks
- clock-names
@@ -112,4 +175,33 @@ examples:
clock-names = "apb", "axi", "nic", "disp", "cam",
"pxp", "lcdif", "isi", "csi", "dsi";
#power-domain-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bridge@60 {
+ compatible = "nxp,imx93-pdfc";
+ reg = <0x60 0x4>;
+
+ 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.3Hi Marco,
On 12/02/2025, Marco Felsch wrote:
> 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.
>
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++
> 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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
> @@ -26,6 +26,12 @@ properties:
> reg:
> maxItems: 1
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
> '#power-domain-cells':
> const: 1
>
> @@ -40,6 +46,60 @@ properties:
> minItems: 8
> maxItems: 10
>
> + bridge@60:
The dependency patch series mentioned in cover letter has two links in it's
cover letter. Reading the patch sets pointed by the two links, we may find
Krzysztof's comments - the child nodes of the blk-ctrl should be completely
documented.
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + const: nxp,imx93-pdfc
> +
> + reg:
> + maxItems: 1
> +
> + 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/graph.yaml#/$defs/endpoint-base
> + unevaluatedProperties: false
> +
> + properties:
> + bus-width:
In v1-v5, I thought the output bus format can be determined by the sink
device(a panel or a bridge) hence properties like bus-width were not needed.
But, if this property is really needed, then reference video-interfaces.yaml
since bus-width is documented there. Should we reference bus-type defined
in video-interfaces.yaml too?
> + enum: [ 16, 18, 24 ]
The PARALLEL_DISP_FORMAT field of DISPLAY_MUX register says this IP supports
below formats. It seems that the enum here may tell RGB888, RGB666 and RGB565.
How can we tell RGB555, YCbCr 24 bits and YUV444 then?
000b RGB888 -> RGB888
001b RGB888 -> RGB666
010b RGB565 -> RGB565
011b RGB555 -> RGB555
100b YUV -> YCbCr 24 bits
101b YUV -> YUV444
> + 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 lanes are muxed to the
Per video-interfaces.yaml, s/data lanes/data lines/. "data lanes" is a
value for MIPI DSI/CSI, afaik.
> + parallel-output pads.
How about just saying that this property is optional and by default it's 24?
> +
> + 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.
The __lower__ 18-bit? Isn't it the __MSB__ 6bit in each color component?
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - compatible
> + - reg
> + - ports
> +
> allOf:
> - if:
> properties:
> @@ -81,9 +141,12 @@ allOf:
> - const: isi
> - const: csi
> - const: dsi
> +
> required:
> - compatible
> - reg
> + - '#address-cells'
> + - '#size-cells'
> - power-domains
> - clocks
> - clock-names
> @@ -112,4 +175,33 @@ examples:
> clock-names = "apb", "axi", "nic", "disp", "cam",
> "pxp", "lcdif", "isi", "csi", "dsi";
> #power-domain-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bridge@60 {
> + compatible = "nxp,imx93-pdfc";
> + reg = <0x60 0x4>;
> +
> + 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>;
> + };
> + };
> + };
> + };
> };
>
--
Regards,
Liu Ying
Hi Liu,
sorry I didn't fully answer you please see below.
On 25-12-08, Liu Ying wrote:
> Hi Marco,
>
> On 12/02/2025, Marco Felsch wrote:
> > 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.
> >
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++
> > 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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
> > @@ -26,6 +26,12 @@ properties:
> > reg:
> > maxItems: 1
...
> > + properties:
> > + endpoint:
> > + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + bus-width:
>
> In v1-v5, I thought the output bus format can be determined by the sink
> device(a panel or a bridge) hence properties like bus-width were not needed.
> But, if this property is really needed, then reference video-interfaces.yaml
> since bus-width is documented there. Should we reference bus-type defined
> in video-interfaces.yaml too?
You're right, the bus-width should be determined by the connected panel.
But there are cases where a 24-bit panel is connected but only the lower
18-bits are muxed. I added the bus-width property to handle this case.
In the end most users don't have to specify this since the correct
bus-width is coming from the panel bus-fmt.
> > + enum: [ 16, 18, 24 ]
>
> The PARALLEL_DISP_FORMAT field of DISPLAY_MUX register says this IP supports
> below formats. It seems that the enum here may tell RGB888, RGB666 and RGB565.
> How can we tell RGB555, YCbCr 24 bits and YUV444 then?
>
> 000b RGB888 -> RGB888
> 001b RGB888 -> RGB666
> 010b RGB565 -> RGB565
> 011b RGB555 -> RGB555
> 100b YUV -> YCbCr 24 bits
> 101b YUV -> YUV444
This enum is about the physical bus width. RGB565 == 16-bit, YUV ==
24-bit.
That said, I don't think that you need to specify the bus-fmt since this
is coming from the panel. As said above, my itension with the bus-width
property is to provide integrators (dts-writers) a possibility to limit
the physical available bus width.
> > + 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 lanes are muxed to the
>
> Per video-interfaces.yaml, s/data lanes/data lines/. "data lanes" is a
> value for MIPI DSI/CSI, afaik.
I can go with "lines" if this is the preferred naming convention for
DRM.
> > + parallel-output pads.
>
> How about just saying that this property is optional and by default it's 24?
I wanted to make it clear what this property does.
> > + 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.
>
> The __lower__ 18-bit? Isn't it the __MSB__ 6bit in each color component?
No, the LSB are cut, this is why it's so important to use this property
if you connected a external 24-bit display to the lower data
lines[17-0].
If you don't specify this property, the MSBs are cut/lost which is far
worse than using the LSB information.
Regards,
Marco
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - compatible
> > + - reg
> > + - ports
> > +
> > allOf:
> > - if:
> > properties:
> > @@ -81,9 +141,12 @@ allOf:
> > - const: isi
> > - const: csi
> > - const: dsi
> > +
> > required:
> > - compatible
> > - reg
> > + - '#address-cells'
> > + - '#size-cells'
> > - power-domains
> > - clocks
> > - clock-names
> > @@ -112,4 +175,33 @@ examples:
> > clock-names = "apb", "axi", "nic", "disp", "cam",
> > "pxp", "lcdif", "isi", "csi", "dsi";
> > #power-domain-cells = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + bridge@60 {
> > + compatible = "nxp,imx93-pdfc";
> > + reg = <0x60 0x4>;
> > +
> > + 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>;
> > + };
> > + };
> > + };
> > + };
> > };
> >
>
>
> --
> Regards,
> Liu Ying
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Hi, Am Montag, 15. Dezember 2025, 18:54:36 CET schrieb Marco Felsch: > Hi Liu, > > sorry I didn't fully answer you please see below. > > On 25-12-08, Liu Ying wrote: > > Hi Marco, > > > > On 12/02/2025, Marco Felsch wrote: > > > 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. > > > > > > Signed-off-by: Liu Ying <victor.liu@nxp.com> > > > [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++ > > > 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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 > > > @@ -26,6 +26,12 @@ properties: > > > reg: > > > maxItems: 1 > > ... > > > > + properties: > > > + endpoint: > > > + $ref: /schemas/graph.yaml#/$defs/endpoint-base > > > + unevaluatedProperties: false > > > + > > > + properties: > > > + bus-width: > > > > In v1-v5, I thought the output bus format can be determined by the sink > > device(a panel or a bridge) hence properties like bus-width were not needed. > > But, if this property is really needed, then reference video-interfaces.yaml > > since bus-width is documented there. Should we reference bus-type defined > > in video-interfaces.yaml too? > > You're right, the bus-width should be determined by the connected panel. > But there are cases where a 24-bit panel is connected but only the lower > 18-bits are muxed. I added the bus-width property to handle this case. > In the end most users don't have to specify this since the correct > bus-width is coming from the panel bus-fmt. > > > > + enum: [ 16, 18, 24 ] > > > > The PARALLEL_DISP_FORMAT field of DISPLAY_MUX register says this IP supports > > below formats. It seems that the enum here may tell RGB888, RGB666 and RGB565. > > How can we tell RGB555, YCbCr 24 bits and YUV444 then? > > > > 000b RGB888 -> RGB888 > > 001b RGB888 -> RGB666 > > 010b RGB565 -> RGB565 > > 011b RGB555 -> RGB555 > > 100b YUV -> YCbCr 24 bits > > 101b YUV -> YUV444 > > This enum is about the physical bus width. RGB565 == 16-bit, YUV == > 24-bit. > > That said, I don't think that you need to specify the bus-fmt since this > is coming from the panel. As said above, my itension with the bus-width > property is to provide integrators (dts-writers) a possibility to limit > the physical available bus width. Mh, isn't [1] exactly about this? Not sure about the outcome at that time. Best regards, Alexander [1] https://lore.kernel.org/all/20250304101530.969920-1-victor.liu@nxp.com/ > [snip] -- 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/
Hi Alexander,
On 25-12-16, Alexander Stein wrote:
> Hi,
>
> Am Montag, 15. Dezember 2025, 18:54:36 CET schrieb Marco Felsch:
> > Hi Liu,
> >
> > sorry I didn't fully answer you please see below.
> >
> > On 25-12-08, Liu Ying wrote:
> > > Hi Marco,
> > >
> > > On 12/02/2025, Marco Felsch wrote:
> > > > 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.
> > > >
> > > > Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > > > [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++
> > > > 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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
> > > > @@ -26,6 +26,12 @@ properties:
> > > > reg:
> > > > maxItems: 1
> >
> > ...
> >
> > > > + properties:
> > > > + endpoint:
> > > > + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> > > > + unevaluatedProperties: false
> > > > +
> > > > + properties:
> > > > + bus-width:
> > >
> > > In v1-v5, I thought the output bus format can be determined by the sink
> > > device(a panel or a bridge) hence properties like bus-width were not needed.
> > > But, if this property is really needed, then reference video-interfaces.yaml
> > > since bus-width is documented there. Should we reference bus-type defined
> > > in video-interfaces.yaml too?
> >
> > You're right, the bus-width should be determined by the connected panel.
> > But there are cases where a 24-bit panel is connected but only the lower
> > 18-bits are muxed. I added the bus-width property to handle this case.
> > In the end most users don't have to specify this since the correct
> > bus-width is coming from the panel bus-fmt.
> >
> > > > + enum: [ 16, 18, 24 ]
> > >
> > > The PARALLEL_DISP_FORMAT field of DISPLAY_MUX register says this IP supports
> > > below formats. It seems that the enum here may tell RGB888, RGB666 and RGB565.
> > > How can we tell RGB555, YCbCr 24 bits and YUV444 then?
> > >
> > > 000b RGB888 -> RGB888
> > > 001b RGB888 -> RGB666
> > > 010b RGB565 -> RGB565
> > > 011b RGB555 -> RGB555
> > > 100b YUV -> YCbCr 24 bits
> > > 101b YUV -> YUV444
> >
> > This enum is about the physical bus width. RGB565 == 16-bit, YUV ==
> > 24-bit.
> >
> > That said, I don't think that you need to specify the bus-fmt since this
> > is coming from the panel. As said above, my itension with the bus-width
> > property is to provide integrators (dts-writers) a possibility to limit
> > the physical available bus width.
>
> Mh, isn't [1] exactly about this? Not sure about the outcome at that time.
Thanks for the pointer, I wasn't aware of this discussion. I skimmed
through the dt-bindings thread and I agree with Rob and Maxime.
We do have the bus-width endpoint property already. This property is
alredy used by media and drm bridge drivers. Why not making use of for
this simple bridge driver too?
Furthermore I doubt, that a simple drm-bridge MEDIA_BUS_FMT_* convert
driver solves all the problem in a generic way for all platforms, all
connectors, all routing options.
If the i.MX93 NXP-EVKs in [1] would have connected the upper LCD_DAT*
pads instead of the lower ones, there would be no conversion needed by
the PDFC bridge driver, albeit the physical bus is cut to 18-bit width
due to the RPi ext. header limit, which is expanded to 24-bit again later on
via the Adafruit board panel FPC connector.
In such scenario the output width of the PDFC has to be 24-bit else
you would lose not only the two LSBs but also the two MSBs for each
channel. I tried to visualize what I meant for the blue channel:
24-bit PDFC bridge
------------------
+----+----+----+----+----+----+----+----+
LCDIF | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 |
+----+----+----+----+----+----+----+----+
| | | | | | | |
+----+----+----+----+----+----+----+----+
PDFC | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 |
+----+----+----+----+----+----+----+----+
| | | | | |
+----+----+----+----+----+----+----+----+
SOC_PAD | xx | xx | D2 | D3 | D4 | D5 | D6 | D7 |
+----+----+----+----+----+----+----+----+
| | | | | |
+----+----+----+----+----+----+----+----+
ext. | xx | xx | B2 | B3 | B4 | B5 | B6 | B7 |
HDR +----+----+----+----+----+----+----+----+
| | | | | |
| | | | | |
| | | | | |
+-----------------------------+ |
| +-----------------------------+
| | | | | | | |
+----+----+----+----+----+----+----+----+
Ada. | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 |
FPC +----+----+----+----+----+----+----+----+
18-bit PDFC bridge
------------------
+----+----+----+----+----+----+----+----+
LCDIF | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 |
+----+----+----+----+----+----+----+----+
| | | | | | | |
+----+----+----+----+----+----+----+----+
PDFC | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 |
+----+----+----+----+----+----+----+----+
| | | | | |
+---------+ | | | | |
| +---------+ | | | |
| | +---------+ | | |
| | | +---------+ | |
| | | | +---------+ |
| | | | | +---------+
| | | | | |
+----+----+----+----+----+----+----+----+
SOC_PAD | xx | xx | D2 | D3 | D4 | D5 | D6 | D7 |
+----+----+----+----+----+----+----+----+
| | | | | |
+----+----+----+----+----+----+----+----+
ext. | xx | xx | B2 | B3 | B4 | B5 | B6 | B7 |
HDR +----+----+----+----+----+----+----+----+
| | | | | |
| | | | | |
| | | | | |
+-----------------------------+ |
| +-----------------------------+
| | | | | | | |
+----+----+----+----+----+----+----+----+
Ada. | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 |
FPC +----+----+----+----+----+----+----+----+
The mapping can get quite difficult for a single SoC already, just by
using a slighlty different HW routing (the upper D[ata] pads).
Therefore I would keep it simple and device/ip specific (in this case
PDFC specific) by making use of the bus-width. Specifying the bus-width
property could be also wrong albeit it's the case physically, as you can
see in my above example.
Therefore the bus-width property must have a good description.
Regards,
Marco
> Best regards,
> Alexander
>
> [1] https://lore.kernel.org/all/20250304101530.969920-1-victor.liu@nxp.com/
>
> > [snip]
> --
> 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/
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Hi Marco, Am Donnerstag, 18. Dezember 2025, 20:08:41 CET schrieb Marco Felsch: > Hi Alexander, > > On 25-12-16, Alexander Stein wrote: > > Hi, > > > > Am Montag, 15. Dezember 2025, 18:54:36 CET schrieb Marco Felsch: > > > Hi Liu, > > > > > > sorry I didn't fully answer you please see below. > > > > > > On 25-12-08, Liu Ying wrote: > > > > Hi Marco, > > > > > > > > On 12/02/2025, Marco Felsch wrote: > > > > > 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. > > > > > > > > > > Signed-off-by: Liu Ying <victor.liu@nxp.com> > > > > > [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++ > > > > > 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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 > > > > > @@ -26,6 +26,12 @@ properties: > > > > > reg: > > > > > maxItems: 1 > > > > > > ... > > > > > > > > + properties: > > > > > + endpoint: > > > > > + $ref: /schemas/graph.yaml#/$defs/endpoint-base > > > > > + unevaluatedProperties: false > > > > > + > > > > > + properties: > > > > > + bus-width: > > > > > > > > In v1-v5, I thought the output bus format can be determined by the sink > > > > device(a panel or a bridge) hence properties like bus-width were not needed. > > > > But, if this property is really needed, then reference video-interfaces.yaml > > > > since bus-width is documented there. Should we reference bus-type defined > > > > in video-interfaces.yaml too? > > > > > > You're right, the bus-width should be determined by the connected panel. > > > But there are cases where a 24-bit panel is connected but only the lower > > > 18-bits are muxed. I added the bus-width property to handle this case. > > > In the end most users don't have to specify this since the correct > > > bus-width is coming from the panel bus-fmt. > > > > > > > > + enum: [ 16, 18, 24 ] > > > > > > > > The PARALLEL_DISP_FORMAT field of DISPLAY_MUX register says this IP supports > > > > below formats. It seems that the enum here may tell RGB888, RGB666 and RGB565. > > > > How can we tell RGB555, YCbCr 24 bits and YUV444 then? > > > > > > > > 000b RGB888 -> RGB888 > > > > 001b RGB888 -> RGB666 > > > > 010b RGB565 -> RGB565 > > > > 011b RGB555 -> RGB555 > > > > 100b YUV -> YCbCr 24 bits > > > > 101b YUV -> YUV444 > > > > > > This enum is about the physical bus width. RGB565 == 16-bit, YUV == > > > 24-bit. > > > > > > That said, I don't think that you need to specify the bus-fmt since this > > > is coming from the panel. As said above, my itension with the bus-width > > > property is to provide integrators (dts-writers) a possibility to limit > > > the physical available bus width. > > > > Mh, isn't [1] exactly about this? Not sure about the outcome at that time. > > Thanks for the pointer, I wasn't aware of this discussion. I skimmed > through the dt-bindings thread and I agree with Rob and Maxime. > > We do have the bus-width endpoint property already. This property is > alredy used by media and drm bridge drivers. Why not making use of for > this simple bridge driver too? > > Furthermore I doubt, that a simple drm-bridge MEDIA_BUS_FMT_* convert > driver solves all the problem in a generic way for all platforms, all > connectors, all routing options. Nobody knows what new hardware comes up with ¯\_ (ツ)_/¯ Anyway we already have a similar problem on our MBa6ULx mainboard. Current downstream workaround is to clone the display timings but change the bus format. See [1]. Although I would like to get rid of it. This is just the display connector on the mainboard causing the shift. Best regards Alexander [1] https://github.com/tq-systems/linux-tqmaxx/commit/777c02480182d3054264aaaf80e1dbc40a02cfc1 > If the i.MX93 NXP-EVKs in [1] would have connected the upper LCD_DAT* > pads instead of the lower ones, there would be no conversion needed by > the PDFC bridge driver, albeit the physical bus is cut to 18-bit width > due to the RPi ext. header limit, which is expanded to 24-bit again later on > via the Adafruit board panel FPC connector. > > In such scenario the output width of the PDFC has to be 24-bit else > you would lose not only the two LSBs but also the two MSBs for each > channel. I tried to visualize what I meant for the blue channel: > > 24-bit PDFC bridge > ------------------ > +----+----+----+----+----+----+----+----+ > LCDIF | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > +----+----+----+----+----+----+----+----+ > | | | | | | | | > +----+----+----+----+----+----+----+----+ > PDFC | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > +----+----+----+----+----+----+----+----+ > | | | | | | > +----+----+----+----+----+----+----+----+ > SOC_PAD | xx | xx | D2 | D3 | D4 | D5 | D6 | D7 | > +----+----+----+----+----+----+----+----+ > | | | | | | > +----+----+----+----+----+----+----+----+ > ext. | xx | xx | B2 | B3 | B4 | B5 | B6 | B7 | > HDR +----+----+----+----+----+----+----+----+ > | | | | | | > | | | | | | > | | | | | | > +-----------------------------+ | > | +-----------------------------+ > | | | | | | | | > +----+----+----+----+----+----+----+----+ > Ada. | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > FPC +----+----+----+----+----+----+----+----+ > > 18-bit PDFC bridge > ------------------ > +----+----+----+----+----+----+----+----+ > LCDIF | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > +----+----+----+----+----+----+----+----+ > | | | | | | | | > +----+----+----+----+----+----+----+----+ > PDFC | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > +----+----+----+----+----+----+----+----+ > | | | | | | > +---------+ | | | | | > | +---------+ | | | | > | | +---------+ | | | > | | | +---------+ | | > | | | | +---------+ | > | | | | | +---------+ > | | | | | | > +----+----+----+----+----+----+----+----+ > SOC_PAD | xx | xx | D2 | D3 | D4 | D5 | D6 | D7 | > +----+----+----+----+----+----+----+----+ > | | | | | | > +----+----+----+----+----+----+----+----+ > ext. | xx | xx | B2 | B3 | B4 | B5 | B6 | B7 | > HDR +----+----+----+----+----+----+----+----+ > | | | | | | > | | | | | | > | | | | | | > +-----------------------------+ | > | +-----------------------------+ > | | | | | | | | > +----+----+----+----+----+----+----+----+ > Ada. | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > FPC +----+----+----+----+----+----+----+----+ > > > The mapping can get quite difficult for a single SoC already, just by > using a slighlty different HW routing (the upper D[ata] pads). > > Therefore I would keep it simple and device/ip specific (in this case > PDFC specific) by making use of the bus-width. Specifying the bus-width > property could be also wrong albeit it's the case physically, as you can > see in my above example. > > Therefore the bus-width property must have a good description. > > Regards, > Marco > > > Best regards, > > Alexander > > > > [1] https://lore.kernel.org/all/20250304101530.969920-1-victor.liu@nxp.com/ > > > > > [snip] > > > > -- 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/
On 25-12-19, Alexander Stein wrote: > Hi Marco, > > Am Donnerstag, 18. Dezember 2025, 20:08:41 CET schrieb Marco Felsch: > > Hi Alexander, > > > > On 25-12-16, Alexander Stein wrote: > > > Hi, > > > > > > Am Montag, 15. Dezember 2025, 18:54:36 CET schrieb Marco Felsch: > > > > Hi Liu, > > > > > > > > sorry I didn't fully answer you please see below. > > > > > > > > On 25-12-08, Liu Ying wrote: > > > > > Hi Marco, > > > > > > > > > > On 12/02/2025, Marco Felsch wrote: > > > > > > 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. > > > > > > > > > > > > Signed-off-by: Liu Ying <victor.liu@nxp.com> > > > > > > [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++ > > > > > > 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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 > > > > > > @@ -26,6 +26,12 @@ properties: > > > > > > reg: > > > > > > maxItems: 1 > > > > > > > > ... > > > > > > > > > > + properties: > > > > > > + endpoint: > > > > > > + $ref: /schemas/graph.yaml#/$defs/endpoint-base > > > > > > + unevaluatedProperties: false > > > > > > + > > > > > > + properties: > > > > > > + bus-width: > > > > > > > > > > In v1-v5, I thought the output bus format can be determined by the sink > > > > > device(a panel or a bridge) hence properties like bus-width were not needed. > > > > > But, if this property is really needed, then reference video-interfaces.yaml > > > > > since bus-width is documented there. Should we reference bus-type defined > > > > > in video-interfaces.yaml too? > > > > > > > > You're right, the bus-width should be determined by the connected panel. > > > > But there are cases where a 24-bit panel is connected but only the lower > > > > 18-bits are muxed. I added the bus-width property to handle this case. > > > > In the end most users don't have to specify this since the correct > > > > bus-width is coming from the panel bus-fmt. > > > > > > > > > > + enum: [ 16, 18, 24 ] > > > > > > > > > > The PARALLEL_DISP_FORMAT field of DISPLAY_MUX register says this IP supports > > > > > below formats. It seems that the enum here may tell RGB888, RGB666 and RGB565. > > > > > How can we tell RGB555, YCbCr 24 bits and YUV444 then? > > > > > > > > > > 000b RGB888 -> RGB888 > > > > > 001b RGB888 -> RGB666 > > > > > 010b RGB565 -> RGB565 > > > > > 011b RGB555 -> RGB555 > > > > > 100b YUV -> YCbCr 24 bits > > > > > 101b YUV -> YUV444 > > > > > > > > This enum is about the physical bus width. RGB565 == 16-bit, YUV == > > > > 24-bit. > > > > > > > > That said, I don't think that you need to specify the bus-fmt since this > > > > is coming from the panel. As said above, my itension with the bus-width > > > > property is to provide integrators (dts-writers) a possibility to limit > > > > the physical available bus width. > > > > > > Mh, isn't [1] exactly about this? Not sure about the outcome at that time. > > > > Thanks for the pointer, I wasn't aware of this discussion. I skimmed > > through the dt-bindings thread and I agree with Rob and Maxime. > > > > We do have the bus-width endpoint property already. This property is > > alredy used by media and drm bridge drivers. Why not making use of for > > this simple bridge driver too? > > > > Furthermore I doubt, that a simple drm-bridge MEDIA_BUS_FMT_* convert > > driver solves all the problem in a generic way for all platforms, all > > connectors, all routing options. > > Nobody knows what new hardware comes up with ¯\_ (ツ)_/¯ > Anyway we already have a similar problem on our MBa6ULx mainboard. > Current downstream workaround is to clone the display timings but > change the bus format. See [1]. Although I would like to get rid of it. > This is just the display connector on the mainboard causing the shift. I had something similiar in mind as a quick and dirty hack. However, I think that the same abbroach used here for the PDFC bridge could be used for the panel endpoint node to enforce a specific bus width. Another solution could be to add the bus-fmt support to the panel of desciption, so you can describe your panel within the OF. Regards, Marco > Best regards > Alexander > > [1] https://github.com/tq-systems/linux-tqmaxx/commit/777c02480182d3054264aaaf80e1dbc40a02cfc1 > > > If the i.MX93 NXP-EVKs in [1] would have connected the upper LCD_DAT* > > pads instead of the lower ones, there would be no conversion needed by > > the PDFC bridge driver, albeit the physical bus is cut to 18-bit width > > due to the RPi ext. header limit, which is expanded to 24-bit again later on > > via the Adafruit board panel FPC connector. > > > > In such scenario the output width of the PDFC has to be 24-bit else > > you would lose not only the two LSBs but also the two MSBs for each > > channel. I tried to visualize what I meant for the blue channel: > > > > 24-bit PDFC bridge > > ------------------ > > +----+----+----+----+----+----+----+----+ > > LCDIF | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > > +----+----+----+----+----+----+----+----+ > > | | | | | | | | > > +----+----+----+----+----+----+----+----+ > > PDFC | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > > +----+----+----+----+----+----+----+----+ > > | | | | | | > > +----+----+----+----+----+----+----+----+ > > SOC_PAD | xx | xx | D2 | D3 | D4 | D5 | D6 | D7 | > > +----+----+----+----+----+----+----+----+ > > | | | | | | > > +----+----+----+----+----+----+----+----+ > > ext. | xx | xx | B2 | B3 | B4 | B5 | B6 | B7 | > > HDR +----+----+----+----+----+----+----+----+ > > | | | | | | > > | | | | | | > > | | | | | | > > +-----------------------------+ | > > | +-----------------------------+ > > | | | | | | | | > > +----+----+----+----+----+----+----+----+ > > Ada. | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > > FPC +----+----+----+----+----+----+----+----+ > > > > 18-bit PDFC bridge > > ------------------ > > +----+----+----+----+----+----+----+----+ > > LCDIF | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > > +----+----+----+----+----+----+----+----+ > > | | | | | | | | > > +----+----+----+----+----+----+----+----+ > > PDFC | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > > +----+----+----+----+----+----+----+----+ > > | | | | | | > > +---------+ | | | | | > > | +---------+ | | | | > > | | +---------+ | | | > > | | | +---------+ | | > > | | | | +---------+ | > > | | | | | +---------+ > > | | | | | | > > +----+----+----+----+----+----+----+----+ > > SOC_PAD | xx | xx | D2 | D3 | D4 | D5 | D6 | D7 | > > +----+----+----+----+----+----+----+----+ > > | | | | | | > > +----+----+----+----+----+----+----+----+ > > ext. | xx | xx | B2 | B3 | B4 | B5 | B6 | B7 | > > HDR +----+----+----+----+----+----+----+----+ > > | | | | | | > > | | | | | | > > | | | | | | > > +-----------------------------+ | > > | +-----------------------------+ > > | | | | | | | | > > +----+----+----+----+----+----+----+----+ > > Ada. | B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | > > FPC +----+----+----+----+----+----+----+----+ > > > > > > The mapping can get quite difficult for a single SoC already, just by > > using a slighlty different HW routing (the upper D[ata] pads). > > > > Therefore I would keep it simple and device/ip specific (in this case > > PDFC specific) by making use of the bus-width. Specifying the bus-width > > property could be also wrong albeit it's the case physically, as you can > > see in my above example. > > > > Therefore the bus-width property must have a good description. > > > > Regards, > > Marco > > > > > Best regards, > > > Alexander > > > > > > [1] https://lore.kernel.org/all/20250304101530.969920-1-victor.liu@nxp.com/ > > > > > > > [snip] > > > > > > > > > > > -- > 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/ > > > -- #gernperDu #CallMeByMyFirstName Pengutronix e.K. | | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Hi Liu,
On 25-12-08, Liu Ying wrote:
> Hi Marco,
>
> On 12/02/2025, Marco Felsch wrote:
> > 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.
> >
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++
> > 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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
> > @@ -26,6 +26,12 @@ properties:
> > reg:
> > maxItems: 1
> >
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 1
> > +
> > '#power-domain-cells':
> > const: 1
> >
> > @@ -40,6 +46,60 @@ properties:
> > minItems: 8
> > maxItems: 10
> >
> > + bridge@60:
>
> The dependency patch series mentioned in cover letter has two links in it's
> cover letter. Reading the patch sets pointed by the two links, we may find
> Krzysztof's comments - the child nodes of the blk-ctrl should be completely
> documented.
Thanks for pointing this out.
@Krzysztof
Requesting to add everything seems not feasible if everything added
should be tested too.
I don't see why everything should be added in one step, since the base
.dtsi isn't added in one step too.
The different devices (parallel-out bridge, DSI bridge, LVDS bridge,
CSI) logically don't belong together, ableit all device use the same
syscon as parent.
Regards,
Marco
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + compatible:
> > + const: nxp,imx93-pdfc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + 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/graph.yaml#/$defs/endpoint-base
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + bus-width:
>
> In v1-v5, I thought the output bus format can be determined by the sink
> device(a panel or a bridge) hence properties like bus-width were not needed.
> But, if this property is really needed, then reference video-interfaces.yaml
> since bus-width is documented there. Should we reference bus-type defined
> in video-interfaces.yaml too?
>
> > + enum: [ 16, 18, 24 ]
>
> The PARALLEL_DISP_FORMAT field of DISPLAY_MUX register says this IP supports
> below formats. It seems that the enum here may tell RGB888, RGB666 and RGB565.
> How can we tell RGB555, YCbCr 24 bits and YUV444 then?
>
> 000b RGB888 -> RGB888
> 001b RGB888 -> RGB666
> 010b RGB565 -> RGB565
> 011b RGB555 -> RGB555
> 100b YUV -> YCbCr 24 bits
> 101b YUV -> YUV444
>
> > + 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 lanes are muxed to the
>
> Per video-interfaces.yaml, s/data lanes/data lines/. "data lanes" is a
> value for MIPI DSI/CSI, afaik.
>
> > + parallel-output pads.
>
> How about just saying that this property is optional and by default it's 24?
>
> > +
> > + 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.
>
> The __lower__ 18-bit? Isn't it the __MSB__ 6bit in each color component?
>
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - compatible
> > + - reg
> > + - ports
> > +
> > allOf:
> > - if:
> > properties:
> > @@ -81,9 +141,12 @@ allOf:
> > - const: isi
> > - const: csi
> > - const: dsi
> > +
> > required:
> > - compatible
> > - reg
> > + - '#address-cells'
> > + - '#size-cells'
> > - power-domains
> > - clocks
> > - clock-names
> > @@ -112,4 +175,33 @@ examples:
> > clock-names = "apb", "axi", "nic", "disp", "cam",
> > "pxp", "lcdif", "isi", "csi", "dsi";
> > #power-domain-cells = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + bridge@60 {
> > + compatible = "nxp,imx93-pdfc";
> > + reg = <0x60 0x4>;
> > +
> > + 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>;
> > + };
> > + };
> > + };
> > + };
> > };
> >
>
>
> --
> Regards,
> Liu Ying
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
On 15/12/2025 17:17, Marco Felsch wrote: > Hi Liu, > > On 25-12-08, Liu Ying wrote: >> Hi Marco, >> >> On 12/02/2025, Marco Felsch wrote: >>> 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. >>> >>> Signed-off-by: Liu Ying <victor.liu@nxp.com> >>> [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++ >>> 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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 >>> @@ -26,6 +26,12 @@ properties: >>> reg: >>> maxItems: 1 >>> >>> + '#address-cells': >>> + const: 1 >>> + >>> + '#size-cells': >>> + const: 1 >>> + >>> '#power-domain-cells': >>> const: 1 >>> >>> @@ -40,6 +46,60 @@ properties: >>> minItems: 8 >>> maxItems: 10 >>> >>> + bridge@60: >> >> The dependency patch series mentioned in cover letter has two links in it's >> cover letter. Reading the patch sets pointed by the two links, we may find >> Krzysztof's comments - the child nodes of the blk-ctrl should be completely >> documented. > > Thanks for pointing this out. > > @Krzysztof > Requesting to add everything seems not feasible if everything added > should be tested too. > I don't see why everything should be added in one step, since the base > .dtsi isn't added in one step too. Because otherwise we do not see entire picture and people post incorrect bindings, claiming they are complete picture, like messing nodes with addressing and nodes without. So sure, if you do not want to post complete picture, we cannot review that complete picture, therefore YOU MUST POST CORRECT CODE. I will not be taking excuses later "we did not know that such code is not allowed". You must know all rules. Best regards, Krzysztof
Hi Krzysztof, Rob, On 25-12-18, Krzysztof Kozlowski wrote: > On 15/12/2025 17:17, Marco Felsch wrote: > > Hi Liu, > > > > On 25-12-08, Liu Ying wrote: > >> Hi Marco, > >> > >> On 12/02/2025, Marco Felsch wrote: > >>> 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. > >>> > >>> Signed-off-by: Liu Ying <victor.liu@nxp.com> > >>> [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++ > >>> 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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 > >>> @@ -26,6 +26,12 @@ properties: > >>> reg: > >>> maxItems: 1 > >>> > >>> + '#address-cells': > >>> + const: 1 > >>> + > >>> + '#size-cells': > >>> + const: 1 > >>> + > >>> '#power-domain-cells': > >>> const: 1 > >>> > >>> @@ -40,6 +46,60 @@ properties: > >>> minItems: 8 > >>> maxItems: 10 > >>> > >>> + bridge@60: > >> > >> The dependency patch series mentioned in cover letter has two links in it's > >> cover letter. Reading the patch sets pointed by the two links, we may find > >> Krzysztof's comments - the child nodes of the blk-ctrl should be completely > >> documented. > > > > Thanks for pointing this out. > > > > @Krzysztof > > Requesting to add everything seems not feasible if everything added > > should be tested too. > > I don't see why everything should be added in one step, since the base > > .dtsi isn't added in one step too. > > Because otherwise we do not see entire picture and people post incorrect > bindings, claiming they are complete picture, like messing nodes with > addressing and nodes without. So sure, if you do not want to post > complete picture, we cannot review that complete picture, therefore YOU > MUST POST CORRECT CODE. > > I will not be taking excuses later "we did not know that such code is > not allowed". You must know all rules. We discussed the ranges/reg usage internally as well with the following outcome: - Situation With i.MX8M SoCs NXP introduced MIX domains. Each domain has a so called BLK-CTRL IP. There is no common register layout for the BLK-CTRL IPs. In addition to this, the register fields within one register may not related to the same IP. Please see my below example: The DISP_MUX register configures the DPI output routed to physical SoC pads as well as the internal MIPI-DSI DPI behavior. This PDFC bridge binding is only interested in the first part, not the 2nd. In other words, the BLK-CTRL IP can be seen as a bunch of loose register fields. - Our outcome To be future compatible and extentible, we believe that the best abstraction is the syscon, no mappings (no ranges/regs). A BLK-CTRL sub-device has no address, just the node name. The driver needs to rely on the syscon parent device. All register(-field) handling is done within the sub-device driver. This way new functionallity like MIPI-DSI PLL clock provider driver can be added easily. I will adapt this patchset accordingly, if you agree to rely on the syscon (no regs/ranges). Regards, Marco > > > Best regards, > Krzysztof > -- #gernperDu #CallMeByMyFirstName Pengutronix e.K. | | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
> We discussed the ranges/reg usage internally as well with the following
> outcome:
>
> - Situation
>
> With i.MX8M SoCs NXP introduced MIX domains. Each domain has a so
> called BLK-CTRL IP. There is no common register layout for the
> BLK-CTRL IPs. In addition to this, the register fields within one
> register may not related to the same IP. Please see my below example:
>
> The DISP_MUX register configures the DPI output routed to physical
> SoC pads as well as the internal MIPI-DSI DPI behavior. This PDFC
> bridge binding is only interested in the first part, not the 2nd.
>
> In other words, the BLK-CTRL IP can be seen as a bunch of loose
> register fields.
Why do hardware engineers keep on insisting on doing this. And why
don't software engineers when asked to review the proposed registers
push back and say No?
I know this is out of you hands, but it is something we should
encourage software engineers at SoC vendors to do. Otherwise we will
have to continually live with such a mess.
Andrew
On 25-12-18, Krzysztof Kozlowski wrote:
> On 15/12/2025 17:17, Marco Felsch wrote:
> > Hi Liu,
> >
> > On 25-12-08, Liu Ying wrote:
> >> Hi Marco,
> >>
> >> On 12/02/2025, Marco Felsch wrote:
> >>> 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.
> >>>
> >>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>> [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++
> >>> 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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
> >>> @@ -26,6 +26,12 @@ properties:
> >>> reg:
> >>> maxItems: 1
> >>>
> >>> + '#address-cells':
> >>> + const: 1
> >>> +
> >>> + '#size-cells':
> >>> + const: 1
> >>> +
> >>> '#power-domain-cells':
> >>> const: 1
> >>>
> >>> @@ -40,6 +46,60 @@ properties:
> >>> minItems: 8
> >>> maxItems: 10
> >>>
> >>> + bridge@60:
> >>
> >> The dependency patch series mentioned in cover letter has two links in it's
> >> cover letter. Reading the patch sets pointed by the two links, we may find
> >> Krzysztof's comments - the child nodes of the blk-ctrl should be completely
> >> documented.
> >
> > Thanks for pointing this out.
> >
> > @Krzysztof
> > Requesting to add everything seems not feasible if everything added
> > should be tested too.
> > I don't see why everything should be added in one step, since the base
> > .dtsi isn't added in one step too.
>
> Because otherwise we do not see entire picture and people post incorrect
> bindings, claiming they are complete picture, like messing nodes with
> addressing and nodes without. So sure, if you do not want to post
> complete picture, we cannot review that complete picture, therefore YOU
> MUST POST CORRECT CODE.
It's not that we don't want to post the complete code, it's rather that
we don't have the projects to cover the complete MEDIA_MIX blk-ctrl.
Albeit it's a very simple IP with just a few (25) registers, all of them
do have a complete different purpose:
- control the AXI QoS and IP Cache
- control the bus NIC settings
- control the camera parallel-input setup
- control the LVDS bridge (LDB) setup
- control the parallel-output (DPI) setup + the MIPI DSI input setup
- control the MIPI DSI PLL Setup
> I will not be taking excuses later "we did not know that such code is
> not allowed". You must know all rules.
I get your point and there are only two options IMHO:
1st) Step-by-step
2nd) Big-Bang
Step-by-step:
------------
+ Mainline support as fast as possible for each component
+/- Contributors must be trusted that everything is communicated openly
- Unforeseen issues which may require DT adaptions
Big-Bang
--------
+ Everything bindings + code can be checked by the maintainers
+/- Less trust required, since everything is added but still min. trust
required
- Unforeseen issues which may require DT adaptions
- No mainline support at all or very late
I can only speak for myself, I don't want to hide anything from you or
other maintainers. But I can't guarantee that everything is 100% correct
and bug-free. I'm quite sure that no one can make such promises.
E.g. I didn't test the simultaneous DPI + DSI + LVDS output. It would be
part of this patchset, if I would have tested this.
Regards,
Marco
> Best regards,
> Krzysztof
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
On Tue, Dec 02, 2025 at 02:32:58PM +0100, Marco Felsch wrote:
> 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.
>
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++
> 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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
> @@ -26,6 +26,12 @@ properties:
> reg:
> maxItems: 1
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
And 'ranges' needed.
> '#power-domain-cells':
> const: 1
>
> @@ -40,6 +46,60 @@ properties:
> minItems: 8
> maxItems: 10
>
> + bridge@60:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + const: nxp,imx93-pdfc
> +
> + reg:
> + maxItems: 1
> +
> + 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/graph.yaml#/$defs/endpoint-base
> + 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 lanes 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
> + - reg
> + - ports
> +
> allOf:
> - if:
> properties:
> @@ -81,9 +141,12 @@ allOf:
> - const: isi
> - const: csi
> - const: dsi
> +
> required:
> - compatible
> - reg
> + - '#address-cells'
> + - '#size-cells'
> - power-domains
> - clocks
> - clock-names
> @@ -112,4 +175,33 @@ examples:
> clock-names = "apb", "axi", "nic", "disp", "cam",
> "pxp", "lcdif", "isi", "csi", "dsi";
> #power-domain-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bridge@60 {
> + compatible = "nxp,imx93-pdfc";
> + reg = <0x60 0x4>;
> +
> + 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
>
On 25-12-07, Rob Herring wrote:
> On Tue, Dec 02, 2025 at 02:32:58PM +0100, Marco Felsch wrote:
> > 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.
> >
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > [m.felsch@pengutronix.de: port to v6.18-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 | 92 ++++++++++++++++++++++
> > 1 file changed, 92 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..6e2d86d9341c75108b492bcbabc8a560d8e707cd 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
> > @@ -26,6 +26,12 @@ properties:
> > reg:
> > maxItems: 1
> >
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 1
> > +
>
> And 'ranges' needed.
I dropped this due to the response from Krzysztof:
https://lore.kernel.org/linux-arm-kernel/c7129d8e-87de-444c-be52-b2eedf03585f@kernel.org/
Regards,
Marco
> > '#power-domain-cells':
> > const: 1
> >
> > @@ -40,6 +46,60 @@ properties:
> > minItems: 8
> > maxItems: 10
> >
> > + bridge@60:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + compatible:
> > + const: nxp,imx93-pdfc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + 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/graph.yaml#/$defs/endpoint-base
> > + 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 lanes 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
> > + - reg
> > + - ports
> > +
> > allOf:
> > - if:
> > properties:
> > @@ -81,9 +141,12 @@ allOf:
> > - const: isi
> > - const: csi
> > - const: dsi
> > +
> > required:
> > - compatible
> > - reg
> > + - '#address-cells'
> > + - '#size-cells'
> > - power-domains
> > - clocks
> > - clock-names
> > @@ -112,4 +175,33 @@ examples:
> > clock-names = "apb", "axi", "nic", "disp", "cam",
> > "pxp", "lcdif", "isi", "csi", "dsi";
> > #power-domain-cells = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + bridge@60 {
> > + compatible = "nxp,imx93-pdfc";
> > + reg = <0x60 0x4>;
> > +
> > + 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
> >
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
© 2016 - 2026 Red Hat, Inc.