Re: [PATCH v7 1/3] dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC subnode to schema and example

[Alexander Stein <alexander.stein@ew.tq-group.com>]

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

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/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]