[PATCH v7 1/3] dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC subnode to schema and example
Marco Felsch
m.felsch at pengutronix.de
Fri Dec 19 01:50:46 PST 2025
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 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.
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 |
More information about the linux-arm-kernel
mailing list