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 <[email protected]> > > > > > > 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 <[email protected]> > > > [[email protected]: port to v6.18-rc1] > > > [[email protected]: add bus-width] > > > Signed-off-by: Marco Felsch <[email protected]> > > > --- > > > .../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/[email protected]/ > [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/
signature.asc
Description: This is a digitally signed message part.
