| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20251218190841.pmn3kwghq6lxsfl4@pengutronix.de>
Date: Thu, 18 Dec 2025 20:08:41 +0100
From: Marco Felsch <m.felsch@...gutronix.de>
To: Alexander Stein <alexander.stein@...tq-group.com>
Cc: Liu Ying <victor.liu@....com>, dri-devel@...ts.freedesktop.org,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>, Peng Fan <peng.fan@....com>,
Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <neil.armstrong@...aro.org>,
Robert Foss <rfoss@...nel.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
devicetree@...r.kernel.org, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/3] dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC
subnode to schema and example
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@....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@....com>
> > > > [m.felsch@...gutronix.de: port to v6.18-rc1]
> > > > [m.felsch@...gutronix.de: add bus-width]
> > > > Signed-off-by: Marco Felsch <m.felsch@...gutronix.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 |
Powered by blists - more mailing lists