[PATCH v7 1/3] dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC subnode to schema and example
Alexander Stein
alexander.stein at ew.tq-group.com
Thu Dec 18 23:45:57 PST 2025
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 at 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 at nxp.com>
> > > > > [m.felsch at pengutronix.de: port to v6.18-rc1]
> > > > > [m.felsch at pengutronix.de: add bus-width]
> > > > > Signed-off-by: Marco Felsch <m.felsch at 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/
More information about the linux-arm-kernel
mailing list