| 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: <705773fc-5aba-4bff-b05e-272e1cd0262c@nxp.com>
Date: Mon, 8 Dec 2025 14:14:27 +0800
From: Liu Ying <victor.liu@....com>
To: Marco Felsch <m.felsch@...gutronix.de>, 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>
Cc: devicetree@...r.kernel.org, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v7 1/3] dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC
subnode to schema and example
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
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
> '#power-domain-cells':
> const: 1
>
> @@ -40,6 +46,60 @@ properties:
> minItems: 8
> maxItems: 10
>
> + bridge@60:
The dependency patch series mentioned in cover letter has two links in it's
cover letter. Reading the patch sets pointed by the two links, we may find
Krzysztof's comments - the child nodes of the blk-ctrl should be completely
documented.
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + const: nxp,imx93-pdfc
> +
> + reg:
> + maxItems: 1
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Input port node to receive pixel data.
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: Output port node to downstream pixel data receivers.
> +
> + 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?
> + 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
> + description:
> + Specify the physical parallel bus width.
> +
> + This property is optional if the display bus-width
> + matches the SoC bus-width, e.g. a 18-bit RGB666 (display)
> + is connected and all 18-bit data lanes are muxed to the
Per video-interfaces.yaml, s/data lanes/data lines/. "data lanes" is a
value for MIPI DSI/CSI, afaik.
> + parallel-output pads.
How about just saying that this property is optional and by default it's 24?
> +
> + This property must be set to 18 to cut only the LSBs
> + instead of the MSBs in case a 24-bit RGB888 display is
> + connected and only the lower 18-bit data lanes are muxed
> + to the parallel-output pads.
The __lower__ 18-bit? Isn't it the __MSB__ 6bit in each color component?
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - compatible
> + - reg
> + - ports
> +
> allOf:
> - if:
> properties:
> @@ -81,9 +141,12 @@ allOf:
> - const: isi
> - const: csi
> - const: dsi
> +
> required:
> - compatible
> - reg
> + - '#address-cells'
> + - '#size-cells'
> - power-domains
> - clocks
> - clock-names
> @@ -112,4 +175,33 @@ examples:
> clock-names = "apb", "axi", "nic", "disp", "cam",
> "pxp", "lcdif", "isi", "csi", "dsi";
> #power-domain-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bridge@60 {
> + compatible = "nxp,imx93-pdfc";
> + reg = <0x60 0x4>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + pdfc_from_lcdif: endpoint {
> + remote-endpoint = <&lcdif_to_pdfc>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + pdfc_to_panel: endpoint {
> + remote-endpoint = <&panel_from_pdfc>;
> + bus-width = <18>;
> + };
> + };
> + };
> + };
> };
>
--
Regards,
Liu Ying
Powered by blists - more mailing lists