* [PATCH 0/5] Add RPROC support for the MX95-15x15-FRDM board
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Hi folks,
As you can see from the title, this series attempts to introduce/enable
RPROC support for the MX95-15x15-FRDM board.
For a while now, the imx_rproc driver has been using the reserved memory
DT nodes as the carveout names, which would force DT writers to go against
the DT specification's recommendation and use non-generic names (e.g.
"vdev0vring0", "vdev0vring1", etc...). This series also tries to fix this
issue by introducing the "memory-region-names" property and using it in
the imx_rproc driver to figure out the carveout names. The driver will
still allow the old way of doing things (i.e. no "memory-region-names"
property) but a warning will now be printed since this should be
discouraged.
Laurentiu Mihalcea (5):
dt-bindings: remoteproc: imx_rproc: document optional
"memory-region-names"
remoteproc: imx_rpoc: fix carveout name parsing
arm64: dts: freescale: imx95-toradex-smarc: move CM7 node to SoC DTSI
arm64: dts: freescale: imx95-15x15-frdm: remove common rmem regions
arm64: dts: freescale: add DT overlay for MX95-15x15-FRDM RPMSG usage
.../bindings/remoteproc/fsl,imx-rproc.yaml | 8 +++
arch/arm64/boot/dts/freescale/Makefile | 3 +
.../dts/freescale/imx95-15x15-frdm-rpmsg.dtso | 65 +++++++++++++++++++
.../boot/dts/freescale/imx95-15x15-frdm.dts | 21 ------
.../dts/freescale/imx95-toradex-smarc.dtsi | 14 ++--
arch/arm64/boot/dts/freescale/imx95.dtsi | 7 ++
drivers/remoteproc/imx_rproc.c | 7 +-
drivers/remoteproc/imx_rproc.h | 19 ++++++
8 files changed, 113 insertions(+), 31 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
--
2.43.0
^ permalink raw reply
* [PATCH 2/5] remoteproc: imx_rpoc: fix carveout name parsing
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The imx remoteproc driver assumes that the names of the reserved memory
regions reflect their usage (e.g. "vdevbuffer", "vdev0vring0", etc.). This
conflicts with the devicetree specification's recommendation, which states
that the names of the devicetree nodes should be generic.
Therefore, instead of relying on the node names, use the names passed via
the "memory-region-names" property if present. Otherwise, keep the old
behavior.
The definition of imx_rproc_rmem_to_resource() is added to a common place
as imx_dsp_rproc.c can also use it given that it suffers from the same
aforementioned problem.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 7 +++++--
drivers/remoteproc/imx_rproc.h | 19 +++++++++++++++++++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7f54322244ac..1ee1c658dcc1 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -672,7 +672,7 @@ static int imx_rproc_prepare(struct rproc *rproc)
int err;
struct resource res;
- err = of_reserved_mem_region_to_resource(np, i++, &res);
+ err = imx_rproc_rmem_to_resource(np, i++, &res);
if (err)
break;
@@ -850,11 +850,14 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (nph <= 0)
return 0;
+ if (!of_property_present(np, "memory-region-names"))
+ dev_warn(dev, "using node names for carveouts should be avoided\n");
+
/* remap optional addresses */
for (a = 0; a < nph; a++) {
struct resource res;
- err = of_reserved_mem_region_to_resource(np, a, &res);
+ err = imx_rproc_rmem_to_resource(np, a, &res);
if (err) {
dev_err(dev, "unable to resolve memory region\n");
return err;
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index 0d7d48352a10..58e9daa41afe 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -45,4 +45,23 @@ struct imx_rproc_dcfg {
u32 reset_vector_mask;
};
+static inline int imx_rproc_rmem_to_resource(struct device_node *np,
+ int index,
+ struct resource *res)
+{
+ int ret;
+
+ ret = of_reserved_mem_region_to_resource(np, index, res);
+ if (ret)
+ return ret;
+
+ /* "memory-region-names" is optional */
+ ret = of_property_read_string_index(np, "memory-region-names",
+ index, &res->name);
+ if (ret == -EINVAL)
+ return 0;
+
+ return ret;
+}
+
#endif /* _IMX_RPROC_H */
--
2.43.0
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Document the optional "memory-region-names" property.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index c18f71b64889..6679b10f9da5 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -62,6 +62,14 @@ properties:
minItems: 1
maxItems: 32
+ memory-region-names:
+ minItems: 1
+ maxItems: 32
+ items:
+ oneOf:
+ - const: rsc-table
+ - pattern: '^vdev[0-9](buffer|vring[0-9])$'
+
power-domains:
minItems: 2
maxItems: 8
--
2.43.0
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: freescale: imx95-15x15-frdm: remove common rmem regions
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Remove the reserved memory regions that are common to the MX95-19x19-EVK,
MX95-15x15-FRDM, and MX95-15x15-EVK platforms and are used for remoteproc.
At the moment, these regions are not used for anything and can be included
in an RPMSG-specific DTS.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../boot/dts/freescale/imx95-15x15-frdm.dts | 21 -------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
index 0f43e3be7058..f9b0e266754d 100644
--- a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
@@ -188,16 +188,6 @@ linux_cma: linux,cma {
linux,cma-default;
};
- vdev0vring0: memory@88000000 {
- reg = <0 0x88000000 0 0x8000>;
- no-map;
- };
-
- vdev0vring1: memory@88008000 {
- reg = <0 0x88008000 0 0x8000>;
- no-map;
- };
-
vdev1vring0: memory@88010000 {
reg = <0 0x88010000 0 0x8000>;
no-map;
@@ -208,17 +198,6 @@ vdev1vring1: memory@88018000 {
no-map;
};
- vdevbuffer: memory@88020000 {
- compatible = "shared-dma-pool";
- reg = <0 0x88020000 0 0x100000>;
- no-map;
- };
-
- rsc_table: memory@88220000 {
- reg = <0 0x88220000 0 0x1000>;
- no-map;
- };
-
vpu_boot: memory@a0000000 {
reg = <0 0xa0000000 0 0x100000>;
no-map;
--
2.43.0
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: freescale: imx95-toradex-smarc: move CM7 node to SoC DTSI
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The CM7 remoteproc configuration is common to multiple MX95-based
platforms (e.g. MX95-19x19-EVK, MX95-15x15-FRDM, SMARC-IMX95, etc.).
Therefore, move the node to the MX95 SoC DTSI. While at it, split the mbox
channels using <>.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 14 ++++++--------
arch/arm64/boot/dts/freescale/imx95.dtsi | 7 +++++++
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 7d760470201f..c94a63a3bf8f 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -145,14 +145,6 @@ reg_wifi_en: regulator-wifi-en {
startup-delay-us = <2000>;
};
- remoteproc-cm7 {
- compatible = "fsl,imx95-cm7";
- mboxes = <&mu7 0 1 &mu7 1 1 &mu7 3 1>;
- mbox-names = "tx", "rx", "rxdb";
- memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
- <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
- };
-
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -204,6 +196,12 @@ vdevbuffer: vdevbuffer@88020000 {
};
};
+&cm7 {
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
+ status = "okay";
+};
+
/* SMARC GBE0 */
&enetc_port0 {
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 3e35c956a4d7..f8760ac067fa 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -272,6 +272,13 @@ opp-1000000000 {
};
};
+ cm7: remoteproc-cm7 {
+ compatible = "fsl,imx95-cm7";
+ mboxes = <&mu7 0 1>, <&mu7 1 1>, <&mu7 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ status = "disabled";
+ };
+
clk_ext1: clock-ext1 {
compatible = "fixed-clock";
#clock-cells = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: freescale: add DT overlay for MX95-15x15-FRDM RPMSG usage
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add RPMSG DT overlay for the MX95-15x15-FRDM board. This overlay is meant
to be used with the mx95evkrpmsg system manager configuration for
remoteproc and audio over rpmsg-usecases.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 3 +
.../dts/freescale/imx95-15x15-frdm-rpmsg.dtso | 65 +++++++++++++++++++
2 files changed, 68 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 513f61eb27b8..a30a99e42426 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -521,6 +521,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx943-evk-pcie0-ep.dtb imx943-evk-pcie1-ep.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-ab2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm-rpmsg.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
@@ -539,6 +540,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-yavia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-zinnia.dtb
+imx95-15x15-frdm-rpmsg-dtbs = imx95-15x15-frdm.dtb imx95-15x15-frdm-rpmsg.dtbo
+
imx95-15x15-evk-pcie-dtbs += imx95-15x15-evk.dtb imx-m2-pcie.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
new file mode 100644
index 000000000000..b39444dde66e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ *
+ * This DT overlay is meant to be used alongside the mx95evkrpmsg SM
+ * configuration for remoteproc and audio over rpmsg.
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ vdev0vring0: memory@88000000 {
+ reg = <0 0x88000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: memory@88008000 {
+ reg = <0 0x88008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0buffer: memory@88020000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x88020000 0 0x100000>;
+ no-map;
+ };
+
+ rsc_table: memory@88220000 {
+ reg = <0 0x88220000 0 0x1000>;
+ no-map;
+ };
+ };
+
+ sound-micfil {
+ status = "disabled";
+ };
+};
+
+&cm7 {
+ memory-region = <&vdev0buffer>, <&vdev0vring0>,
+ <&vdev0vring1>, <&rsc_table>;
+ memory-region-names = "vdev0buffer", "vdev0vring0",
+ "vdev0vring1", "rsc-table";
+ status = "okay";
+};
+
+&edma1 {
+ /* reserved for M7 */
+ dma-channel-mask = <0x40>;
+};
+
+&edma2 {
+ /* reserved for M7 and V2X */
+ dma-channel-mask = <0xf>;
+};
+
+&micfil {
+ /* reserved for M7 */
+ status = "disabled";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH 1/1] arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in sound card as well
From: Alexander Stein @ 2026-05-22 11:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Alexander Stein, Shawn Guo
Cc: linux, devicetree, imx, linux-arm-kernel, linux-kernel
With deferrable card binding the sound card driver tries to
get the mclk configuration before it is setup in sai3 node.
Fix this by setting the mclk config for the sound card as well.
Fixes: d8f9d8126582 ("arm64: dts: imx8mp: Add analog audio output on i.MX8MP TQMa8MPxL/MBa8MPxL")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
index 890d1e525a489..1ea1da735762f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
@@ -246,6 +246,9 @@ sound {
"IN1_R", "Line In Jack",
"Line Out Jack", "LOL",
"Line Out Jack", "LOR";
+ assigned-clocks = <&clk IMX8MP_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
};
sound-hdmi {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 14/14] arm64: dts: imx8mp: add VC8000E encoder node
From: Fabio Estevam @ 2026-05-22 11:28 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux-media,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Nicolas Dufresne,
Benjamin Gaignard, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Marco Felsch, Michael Tretter
In-Reply-To: <20260522101653.2565125-15-paulk@sys-base.io>
Hi Paul,
Thanks for working on this.
On Fri, May 22, 2026 at 7:49 AM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> From: Marco Felsch <m.felsch@pengutronix.de>
>
> Add support for the Versilicon VC8000E multi-codec stateless encoder.
Typo: Verisilicon
> The IP integrated on the i.MX8MP supports H.264 and H.265 encoding.
>
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
You need to add your Signed-off-by tag as well.
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index a3de6604e29f..4e63c2b16c1a 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -2290,6 +2290,17 @@ vpu_g2: video-codec@38310000 {
> power-domains = <&vpumix_blk_ctrl IMX8MP_VPUBLK_PD_G2>;
> };
>
> + vpu_vc8000e: video-codec@38320000 {
> + compatible = "nxp,imx8mp-vpu-vc8000e";
This compatible must be documented in a dt-bindings yaml file.
^ permalink raw reply
* Re: [PATCH] media: rp1-cfe: Use IS_ERR() check for media_entity_remote_source_pad_unique()
From: Dave Stevenson @ 2026-05-22 10:14 UTC (permalink / raw)
To: Ingyu Jang
Cc: Tomi Valkeinen, Raspberry Pi Kernel Maintenance,
Mauro Carvalho Chehab, Florian Fainelli,
Broadcom internal kernel review list, linux-media,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260514193148.2357371-1-ingyujang25@korea.ac.kr>
On Thu, 14 May 2026 at 20:32, Ingyu Jang <ingyujang25@korea.ac.kr> wrote:
>
> * Spam *
> media_entity_remote_source_pad_unique() returns either a valid struct
> media_pad pointer or an error pointer (ERR_PTR(-ENOTUNIQ) or
> ERR_PTR(-ENOLINK)); it never returns NULL. The current NULL check
> therefore never triggers, and the "pad not connected" error path is
> unreachable.
>
> Replace the NULL check with an IS_ERR() check so the validation
> actually detects malformed media graphs.
>
> Signed-off-by: Ingyu Jang <ingyujang25@korea.ac.kr>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> ---
> drivers/media/platform/raspberrypi/rp1-cfe/cfe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c b/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
> index 8375ed3e97b9f..91e9fa0341e06 100644
> --- a/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
> +++ b/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
> @@ -1779,7 +1779,7 @@ static int cfe_video_link_validate(struct media_link *link)
> link->source->entity->name, link->source->index,
> link->sink->entity->name, link->sink->index);
>
> - if (!media_entity_remote_source_pad_unique(link->sink->entity)) {
> + if (IS_ERR(media_entity_remote_source_pad_unique(link->sink->entity))) {
> cfe_err(cfe, "video node %s pad not connected\n", vd->name);
> return -ENOTCONN;
> }
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v6 04/22] drm/display: scdc_helper: Add HDMI 2.0 scrambling management helpers
From: Cristian Ciocaltea @ 2026-05-22 11:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Heiko Stübner, Andy Yan, Luca Ceresoli, Daniel Stone, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260521-chestnut-harrier-of-enhancement-2bcfa2@penduick>
On 5/21/26 11:10 AM, Maxime Ripard wrote:
> On Wed, May 20, 2026 at 09:38:15PM +0300, Cristian Ciocaltea wrote:
>> Add drm_scdc_start_scrambling(), drm_scdc_stop_scrambling() and
>> drm_scdc_sync_status() helpers to manage the full lifecycle of HDMI 2.0
>> SCDC scrambling on both source and sink sides.
>>
>> drm_scdc_start_scrambling() configures SCDC scrambling and high TMDS
>> clock ratio and starts a periodic work item that monitors the sink's
>> SCDC scrambling status, retrying setup when the sink loses state.
>>
>> drm_scdc_stop_scrambling() tears down scrambling on both sides and
>> cancels the monitoring work.
>>
>> drm_scdc_sync_status() triggers a CRTC reset on reconnection to restore
>> SCDC state lost during sink disconnects within an active display
>> pipeline.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> drivers/gpu/drm/display/drm_scdc_helper.c | 235 +++++++++++++++++++++++++++++-
>> include/drm/display/drm_scdc_helper.h | 6 +-
>> 2 files changed, 236 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/display/drm_scdc_helper.c b/drivers/gpu/drm/display/drm_scdc_helper.c
>> index cb6632346aad..5bacb886d373 100644
>> --- a/drivers/gpu/drm/display/drm_scdc_helper.c
>> +++ b/drivers/gpu/drm/display/drm_scdc_helper.c
>> @@ -21,16 +21,22 @@
>> * DEALINGS IN THE SOFTWARE.
>> */
>>
>> +#include <linux/delay.h>
>> #include <linux/export.h>
>> #include <linux/i2c.h>
>> +#include <linux/minmax.h>
>> #include <linux/slab.h>
>> -#include <linux/delay.h>
>>
>> -#include <drm/display/drm_scdc_helper.h>
>> +#include <drm/drm_atomic.h>
>> +#include <drm/drm_atomic_helper.h>
>> +#include <drm/drm_bridge_helper.h>
>> #include <drm/drm_connector.h>
>> +#include <drm/drm_crtc.h>
>> #include <drm/drm_device.h>
>> #include <drm/drm_print.h>
>>
>> +#include <drm/display/drm_scdc_helper.h>
>> +
>> /**
>> * DOC: scdc helpers
>> *
>> @@ -50,10 +56,14 @@
>> * has to track the connector status changes using interrupts and
>> * restore the SCDC status. The typical solution for this is to trigger an
>> * empty modeset in drm_connector_helper_funcs.detect_ctx(), like what vc4 does
>> - * in vc4_hdmi_reset_link().
>> + * in vc4_hdmi_reset_link(). Alternatively, use the HDMI connector framework
>> + * which ensures drm_scdc_sync_status() is called in the context of
>> + * drm_atomic_helper_connector_hdmi_hotplug_ctx().
>> */
>>
>> -#define SCDC_I2C_SLAVE_ADDRESS 0x54
>> +#define SCDC_I2C_SLAVE_ADDRESS 0x54
>> +#define SCDC_MAX_SOURCE_VERSION 0x1
>> +#define SCDC_STATUS_POLL_DELAY_MS 3000
>>
>> #define drm_scdc_dbg(connector, fmt, ...) \
>> drm_dbg_kms((connector)->dev, "[CONNECTOR:%d:%s] " fmt, \
>> @@ -270,3 +280,220 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct drm_connector *connector,
>> return true;
>> }
>> EXPORT_SYMBOL(drm_scdc_set_high_tmds_clock_ratio);
>> +
>> +static int drm_scdc_setup_scrambler(struct drm_connector *connector)
>> +{
>> + bool done;
>> +
>> + done = drm_scdc_set_high_tmds_clock_ratio(connector, true);
>> + if (!done)
>> + return -EIO;
>> +
>> + done = drm_scdc_set_scrambling(connector, true);
>> + if (!done)
>> + return -EIO;
>> +
>> + schedule_delayed_work(&connector->hdmi.scdc_work,
>> + msecs_to_jiffies(SCDC_STATUS_POLL_DELAY_MS));
>> + return 0;
>> +}
>
> There's a very tight deadline in the spec to enable the scrambler
> relative to the video. Debouncing (I assume?) for three seconds break
> it. Drivers might not be able to do better, but it's really not
> something we should entertain at the framework level and we should call
> the callback straight-away.
In drm_scdc_start_scrambling() we call this function directly, the callback is
only meant to retry the call if the sink didn't set the scrambling for whatever
reason.
Or do you mean we shouldn't wait that long before retrying? vc4 uses 1s, I got
some mixed results in a few occasions and experimented with increased values,
but I'll revert or we can adjust to whatever you think it'd be more sensible.
>> +static void drm_scdc_monitor_scrambler(struct drm_connector *connector)
>> +{
>> + if (READ_ONCE(connector->hdmi.scrambler_enabled) &&
>> + !drm_scdc_get_scrambling_status(connector))
>> + drm_scdc_setup_scrambler(connector);
>> +}
>> +
>> +static int drm_scdc_reset_crtc(struct drm_connector *connector,
>> + struct drm_modeset_acquire_ctx *ctx)
>> +{
>> + struct drm_crtc *crtc;
>> + u8 config;
>> + int ret;
>> +
>> + if (!ctx || !connector->state)
>> + return 0;
>> +
>> + crtc = connector->state->crtc;
>> + if (!crtc || !crtc->state || !crtc->state->active)
>> + return 0;
>> +
>> + ret = drm_scdc_readb(connector->ddc, SCDC_TMDS_CONFIG, &config);
>> + if (ret) {
>> + drm_scdc_dbg(connector, "Failed to read TMDS config: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if ((config & SCDC_SCRAMBLING_ENABLE) &&
>> + (config & SCDC_TMDS_BIT_CLOCK_RATIO_BY_40))
>> + return 0;
>> +
>> + /*
>> + * Reset the CRTC to suspend TMDS transmission, conforming to HDMI 2.0
>> + * spec which requires scrambled data not to be sent before the sink is
>> + * configured, and TMDS clock to be suspended while changing the clock
>> + * ratio. The disable/re-enable cycle triggered by the reset should
>> + * call drm_scdc_start_scrambling() during re-enable, properly
>> + * configuring the sink before data transmission resumes.
>> + */
>> +
>> + drm_scdc_dbg(connector, "Resetting CRTC to restore SCDC status\n");
>> +
>> + ret = drm_atomic_helper_reset_crtc(crtc, ctx);
>> + if (ret && ret != -EDEADLOCK)
>> + drm_scdc_dbg(connector, "Failed to reset CRTC: %d\n", ret);
>> +
>> + return ret;
>> +}
>
> locking is a bit more involved than that, I'd suggest to take
> vc4_hdmi_reset_link() and turn it into a helper.
The current non-NULL ctx call chain goes through drm_helper_probe_detect_ctx()
-> .detect_ctx -> ... -> drm_scdc_sync_status() -> drm_scdc_reset_crtc(), and
the connection mutex is already held by drm_helper_probe_detect() in that path.
I'll make the helper safe under any caller by taking the connection_mutex via
the supplied ctx, since re-acquiring it with the same context when it is already
held should be a no-op. Moreover, the racy crtc->state->active early out could
be dropped: when the CRTC is inactive, drm_atomic_helper_reset_crtc() should
result in a no-op commit anyway, so the check is at best an optimisation.
This mirrors what drm_bridge_helper_reset_crtc() does.
>> +/**
>> + * drm_scdc_start_scrambling - activate scrambling and monitor SCDC status
>> + * @connector: connector
>> + *
>> + * Enables scrambling and high TMDS clock ratio on both source and sink sides.
>> + * Additionally, use a delayed work item to monitor the scrambling status on
>> + * the sink side and retry the operation, as some displays refuse to set the
>> + * scrambling bit right away.
>> + *
>> + * Returns:
>> + * Zero if scrambling is set successfully, an error code otherwise.
>> + */
>> +int drm_scdc_start_scrambling(struct drm_connector *connector)
>> +{
>> + struct drm_display_info *info = &connector->display_info;
>> + struct drm_connector_hdmi *hdmi = &connector->hdmi;
>> + int ret;
>> + u8 ver;
>> +
>> + if (!hdmi->funcs ||
>> + !hdmi->funcs->scrambler_src_enable ||
>> + !hdmi->funcs->scrambler_src_disable) {
>> + drm_scdc_dbg(connector, "Function not implemented, bailing.\n");
>> + return -EINVAL;
>> + }
>
> This case shouldn't be a thing. The driver must not probe if it's not set.
When advertising DRM_BRIDGE_OP_HDMI_SCRAMBLER, drm_bridge_connector_init() will
fail if the scrambler hooks are not provided. However, the check would be still
useful if one missed to set DRM_BRIDGE_OP_HDMI_SCRAMBLER before adding the
bridge. I'll try to also handle non-bridge usecases - pls see the proposal
below.
>> + if (!info->is_hdmi ||
>> + !info->hdmi.scdc.supported ||
>> + !info->hdmi.scdc.scrambling.supported) {
>> + drm_scdc_dbg(connector, "Sink doesn't support scrambling.\n");
>> + return -EINVAL;
>> + }
>
> You should also compute whether we actually need to enable the scrambler
> here, based on the mode, format and bpc.
I'm thinking to mirror the existing supported_formats / ycbcr_420_allowed
plumbing:
- Add a 'scrambling_supported' flag to struct drm_connector_hdmi and let
drm_bridge_connector_init() to propagates it from the HDMI bridge before
calling drmm_connector_hdmi_init().
- drmm_connector_hdmi_init() validates that the capability is consistent with
the provided callbacks: when scrambling_supported is true, both
scrambler_src_enable() and scrambler_src_disable() must be provided.
- Add a 'scrambling_needed' flag to struct drm_connector_hdmi_state to be set by
hdmi_compute_clock() based on the TMDS character rate and the source/sink
scrambling capabilities.
- Ensure hdmi_clock_valid() rejects modes having TMDS character rate exceeding
340 MHz when either the source or the sink lacks the required SCDC scrambling
capability.
> I'd also like to see what a !bridge user of this would look like. The
> vc4 driver has all the infrastructure you need already, so converting it
> to it would be great.
Sure, will do. I've just ordered a RPI5 board, so I should be able to properly
validate this.
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: clock: Add Amlogic A9 PLL clock controller
From: Jian Hu @ 2026-05-22 11:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <7c458070-a56a-4d49-89fc-efeb388beffc@kernel.org>
On 5/22/2026 5:16 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On 22/05/2026 08:20, Jian Hu wrote:
>> Hi Krzysztof,
>>
>> Thanks for your review.
>>
>> On 5/15/2026 4:09 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On Mon, May 11, 2026 at 08:47:24PM +0800, Jian Hu wrote:
>>>> Add the PLL clock controller dt-bindings for the Amlogic A9 SoC family.
>>>>
>>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>>> ---
>>>> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +++++++++++++++++++++
>>>> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +++++++++++
>>>> 2 files changed, 165 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>>> new file mode 100644
>>>> index 000000000000..4ee6013ba1a1
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>>> @@ -0,0 +1,110 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-pll-clkc.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Amlogic A9 Series PLL Clock Controller
>>>> +
>>>> +maintainers:
>>>> + - Neil Armstrong <neil.armstrong@linaro.org>
>>>> + - Jerome Brunet <jbrunet@baylibre.com>
>>>> + - Jian Hu <jian.hu@amlogic.com>
>>>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + enum:
>>>> + - amlogic,a9-gp0-pll
>>>> + - amlogic,a9-hifi0-pll
>>>> + - amlogic,a9-hifi1-pll
>>>> + - amlogic,a9-mclk0-pll
>>>> + - amlogic,a9-mclk1-pll
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + '#clock-cells':
>>>> + const: 1
>>>> +
>>>> + clocks:
>>>> + items:
>>>> + - description: pll input oscillator gate
>>>> + - description: fixed input clock source for mclk_sel_0
>>>> + - description: u3p2pll input clock source for mclk_sel_0 (optional)
>>> Second clock is also optional. Drop "(optional)" comment, just
>>> confusing.
>>
>> GP0 has only one parent clock, while MCLK has three.
>>
>> The second and third parent entries of GP0 are vacant,
>>
>> so they need to be marked optional.
>>
>> I will add the optional property for the second clock in the next revision.
> How? Read the previous feedback...
>
> Best regards,
> Krzysztof
My apologies, I misunderstood your previous comment.
I will drop "(optional)" from the clock descriptions.
It will be updated as:
clocks:
items:
- description: pll input oscillator gate
- description: fixed input clock source for mclk_sel_0
- description: u3p2pll input clock source for mclk_sel_0
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for i.MX93
From: Alexander Stein @ 2026-05-22 12:02 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil, G.N. Zhou (OSS), G.N. Zhou (OSS),
G.N. Zhou (OSS)
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, G.N. Zhou (OSS)
In-Reply-To: <AS8PR04MB9080844E610F8E8012647B39FA0F2@AS8PR04MB9080.eurprd04.prod.outlook.com>
Hi,
Am Freitag, 22. Mai 2026, 03:58:56 CEST schrieb G.N. Zhou (OSS):
> > > Thanks for testing. Regarding the lane stop state error on i.MX93 with
> > imx327:
> > >
> > > This error indicates the CSI-2 lanes are not in LP-11 (stop) state
> > > when expected. Please check:
> > >
> > > 1) Verify the sensor PHY is in LP-11 state before returning from the sensor's
> > > s_stream(1) call. The CSI-2 receiver expects lanes to be in stop state
> > > initially.
> >
> > Well, this might be tricky as I don't have D-PHY capable scopes.
> > I can successfully use this sensor on a imx8mp, so I am expecting this to be
> > okay.
> >
> > > 2) Check if the imx327 driver has a delay between starting the stream and
> > > returning from s_stream(). If the sensor transitions PHY out of LP-11
> > > state during this delay, the CSI driver's lane state check will fail
> > > when it runs later. The sensor should remain in LP-11 until the CSI
> > > controller completes its initialization.
> >
> > In imx290_set_stream() and subsequently imx290_start_streaming() setting
> > IMX290_XMSTA starts the stream. I expect this is the point when the sensors
> > switches from LP-11 to HS. But again, I can't verify.
>
> As mentioned in #2, I reviewed drivers/media/i2c/imx290.c and identified a 30ms
> delay that appears to be the root cause of this issue.
>
> The problem occurs because:
>
> The sensor exits LP-11 state and transitions to HS mode after IMX290_XMSTA is written
> The 30ms delay in s_stream() causes the function to return late
> By the time the CSI controller performs its lane state check, the sensor has already switched
> from LP-11 to HS mode, causing the check to fail。
This sounds wrong, see below.
>
> Proposed fix:
>
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index 21cbc81cb2ed..519aa336249a 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -1059,7 +1059,6 @@ static int imx290_start_streaming(struct imx290 *imx290,
>
> cci_write(imx290->regmap, IMX290_STANDBY, 0x00, &ret);
>
> - msleep(30);
>
> /* Start streaming */
> return cci_write(imx290->regmap, IMX290_XMSTA, 0x00, &ret);
>
> Removing this delay allows s_stream() to return immediately, giving the CSI controller
> time to complete its initialization before the sensor transitions PHY state.
>
> Could you test this patch and confirm if it resolves the lane state check failure?
Removing these 30ms does not fix the problem. Actually the delay change is
hardly measurable, as the i2c transfer take much more time. I added a message
for start/exit of imx290_enable_streams(). Just the transfers take >600ms.
--8<--
[ 40.507273] plane 0: bytesperline=3840 sizeimage=4147200
[ 40.512628] mxc-isi 4ae40000.isi: validating link "crossbar":2 -> "mxc_isi.0":0
[ 40.519945] mxc-isi 4ae40000.isi: validating stream "crossbar":2:0 -> "mxc_isi.0":0:0
[ 40.527789] mxc-isi 4ae40000.isi: validating link "dw-mipi-csi2rx 4ae00000.mipi-csi":1 -> "crossbar":0
[ 40.537105] mxc-isi 4ae40000.isi: validating stream "dw-mipi-csi2rx 4ae00000.mipi-csi":1:0 -> "crossbar":0:0
[ 40.546940] mxc-isi 4ae40000.isi: validating link "imx327 4-001a":0 -> "dw-mipi-csi2rx 4ae00000.mipi-csi":0
[ 40.556680] mxc-isi 4ae40000.isi: validating stream "imx327 4-001a":0:0 -> "dw-mipi-csi2rx 4ae00000.mipi-csi":0:0
[ 40.573332] mxc-isi 4ae40000.isi: enable streams "crossbar":2/0x1
[ 40.579446] mxc-isi 4ae40000.isi: collect_streams: "crossbar":2: found 0x1 enabled 0x0
[ 40.587373] imx290 4-001a: Frame descriptor on pad 0, type CSI-2
[ 40.593390] imx290 4-001a: stream 0, code 0x300f, length 0, flags 0x0000, vc 0, dt 0x2b
[ 40.601489] dw-mipi-csi2rx 4ae00000.mipi-csi: Frame descriptor on pad 1, type CSI-2
[ 40.609147] dw-mipi-csi2rx 4ae00000.mipi-csi: stream 0, code 0x300f, length 0, flags 0x0000, vc 0, dt 0x2b
[ 40.618894] mxc-isi 4ae40000.isi: enable streams "dw-mipi-csi2rx 4ae00000.mipi-csi":1/0x1
[ 40.627082] dw-mipi-csi2rx 4ae00000.mipi-csi: collect_streams: "dw-mipi-csi2rx 4ae00000.mipi-csi":1: found 0x1 enabled 0x0
[ 40.638184] mxc-isi 4ae40000.isi: enable streams "imx327 4-001a":0/0x1
[ 40.644728] imx290 4-001a: collect_streams: sub-device "imx327 4-001a" does not support streams
[ 40.653431] imx290 4-001a: imx290_enable_streams start
[ 41.294967] imx290 4-001a: imx290_enable_streams exit
[ 41.301064] dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003
[ 41.309884] mxc-isi 4ae40000.isi: disable streams "imx327 4-001a":0/0x1
[ 41.316534] imx290 4-001a: collect_streams: sub-device "imx327 4-001a" does not support streams
[ 41.361401] mxc-isi 4ae40000.isi: enable streams 1:0x1 failed: -110
[ 41.367690] mxc-isi 4ae40000.isi: failed to enable streams 0x1 on 'dw-mipi-csi2rx 4ae00000.mipi-csi':1: -110
[ 41.379854] mxc-isi 4ae40000.isi: enable streams 2:0x1 failed: -110
[ 41.387325] mxc-isi 4ae40000.isi: Failed to enable pipe 0
[ 41.399231] video0: VIDIOC_STREAMON: error -110: type=vid-cap-mplane
[ 41.408340] videodev: v4l2_release: video0: release
--8<--
Given this I would ague the CSI host initialization order is wrong. The
documentation for enable_streams states:
> The struct v4l2_subdev_pad_ops->enable_streams() and struct
> v4l2_subdev_pad_ops->disable_streams() callbacks are used by the receiver driver
> to control the transmitter driver's streaming state.
So IMHO calling enable_streams it is expected the sensors switched to
HS mode. Unfortunately even checking PHY stopstate before enabling the subdev
streams does not fix this error message.
There is still
> dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003
I also noticed that before the s_stream call (imx290_set_stream) call the
device is powered down. That might explaing that reversing the order will
not help.
Best regards,
Alexander
--
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/
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Andrew Lunn @ 2026-05-22 12:05 UTC (permalink / raw)
To: Anirudh Srinivasan
Cc: Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Joel Stanley
In-Reply-To: <CAJ13v3RtV+_P_ShfrM5vH+neT0cB6t5yAbqGiiw7S7Y8qpVY=Q@mail.gmail.com>
On Thu, May 21, 2026 at 10:49:24PM -0500, Anirudh Srinivasan wrote:
> Hi Andrew,
>
> On Tue, Mar 31, 2026 at 9:18 AM Anirudh Srinivasan
> <anirudhsriniv@gmail.com> wrote:
> >
> > Adds the DT nodes needed for ethernet support for Asus Kommando, with
> > phy mode set to rgmii-id.
> >
> > When this DT was originally added, the phy mode was set to rgmii (which
> > was incorrect). It was suggested to remove networking support from the
> > DT till the Aspeed networking driver was patched so that the correct phy
> > mode could be used.
> >
> > The discussion in [1] mentions that u-boot was inserting clk delays that
> > weren't needed, which resulted in needing to set the phy mode in linux
> > to rgmii incorrectly. The solution suggested there was to patch u-boot to
> > no longer insert these clk delays and use rgmii-id as the phy mode for
> > any future DTs added to linux.
> >
> > This DT was tested (on the OpenBMC u-boot fork [2]) with a u-boot DT
> > modified to insert clk delays of 0 (instead of patching u-boot itself).
> > [3] adds a u-boot DT for this device (without networking) and describes
> > how to patch it to add networking support. If this patched DT is used,
> > then networking works with rgmii-id phy mode in both u-boot and linux.
> >
> > [1] https://lore.kernel.org/linux-aspeed/ef88bb50-9f2c-458d-a7e5-dc5ecb9c777a@lunn.ch/
> > [2] https://github.com/openbmc/u-boot/tree/v2019.04-aspeed-openbmc
> > [3] https://lore.kernel.org/openbmc/20260328-asus-kommando-v2-1-2a656f8cd314@gmail.com/
> >
> > Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
> > ---
> > This patch is based off aspeed/arm/dt from bmc tree
> > ---
> > Changes in v2:
> > - Commit message now mentions that the u-boot tested against is the
> > openbmc u-boot fork
> > - Link to v1: https://lore.kernel.org/r/20260328-asus-kommando-networking-v1-1-66d308b88536@gmail.com
> > ---
> > .../dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > index ab7ad320067c1ddc0fea9ac386fd488c8ef28184..e0f7d92efa18ccbad2c336236c3b9d01b7de1bba 100644
> > --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > @@ -107,6 +107,24 @@ &gpio1 {
> > /*18E0 32*/ "","","","","","","","";
> > };
> >
> > +&mac2 {
> > + status = "okay";
> > +
> > + phy-mode = "rgmii-id";
> > + phy-handle = <ðphy2>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_rgmii3_default>;
> > +};
> > +
> > +&mdio2 {
> > + status = "okay";
> > +
> > + ethphy2: ethernet-phy@0 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
> > + };
> > +};
> > +
> > &vhub {
> > status = "okay";
> > };
> >
> > ---
> > base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
> > change-id: 20260328-asus-kommando-networking-5c0612aa6b8c
> >
> > Best regards,
> > --
> > Anirudh Srinivasan <anirudhsriniv@gmail.com>
> >
>
> While we're figuring out what to do with u-boot, what are your
> thoughts on getting this patch in so that the kernel DTS changes
> needed for networking land in this cycle?
>
> The current commit message might become somewhat outdated if the
> u-boot patch changes though, so not sure if that's okay.
The commit message explains "Why?", which is what is important. So it
should not matter if it becomes outdated. And the DT is correct, no
matter how the issue is solved.
So i'm O.K. with this.
Andrew
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: freescale: add DT overlay for MX95-15x15-FRDM RPMSG usage
From: Daniel Baluta @ 2026-05-22 12:11 UTC (permalink / raw)
To: Laurentiu Mihalcea, Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-6-laurentiumihalcea111@gmail.com>
On 5/22/26 14:18, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>
> Add RPMSG DT overlay for the MX95-15x15-FRDM board. This overlay is meant
> to be used with the mx95evkrpmsg system manager configuration for
> remoteproc and audio over rpmsg-usecases.
>
> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 3 +
> .../dts/freescale/imx95-15x15-frdm-rpmsg.dtso | 65 +++++++++++++++++++
> 2 files changed, 68 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 513f61eb27b8..a30a99e42426 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -521,6 +521,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx943-evk-pcie0-ep.dtb imx943-evk-pcie1-ep.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-ab2.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm-rpmsg.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
> @@ -539,6 +540,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-mallow.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-yavia.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-zinnia.dtb
>
> +imx95-15x15-frdm-rpmsg-dtbs = imx95-15x15-frdm.dtb imx95-15x15-frdm-rpmsg.dtbo
> +
> imx95-15x15-evk-pcie-dtbs += imx95-15x15-evk.dtb imx-m2-pcie.dtbo
> dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie.dtb
>
> diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
> new file mode 100644
> index 000000000000..b39444dde66e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2026 NXP
> + *
> + * This DT overlay is meant to be used alongside the mx95evkrpmsg SM
> + * configuration for remoteproc and audio over rpmsg.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&{/} {
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + vdev0vring0: memory@88000000 {
> + reg = <0 0x88000000 0 0x8000>;
> + no-map;
> + };
> +
> + vdev0vring1: memory@88008000 {
> + reg = <0 0x88008000 0 0x8000>;
> + no-map;
> + };
> +
> + vdev0buffer: memory@88020000 {
> + compatible = "shared-dma-pool";
> + reg = <0 0x88020000 0 0x100000>;
> + no-map;
> + };
> +
> + rsc_table: memory@88220000 {
> + reg = <0 0x88220000 0 0x1000>;
> + no-map;
> + };
> + };
> +
> + sound-micfil {
> + status = "disabled";
> + };
> +};
> +
> +&cm7 {
> + memory-region = <&vdev0buffer>, <&vdev0vring0>,
> + <&vdev0vring1>, <&rsc_table>;
> + memory-region-names = "vdev0buffer", "vdev0vring0",
> + "vdev0vring1", "rsc-table";
> + status = "okay";
> +};
> +
> +&edma1 {
> + /* reserved for M7 */
> + dma-channel-mask = <0x40>;
> +};
> +
> +&edma2 {
> + /* reserved for M7 and V2X */
> + dma-channel-mask = <0xf>;
> +};
> +
> +&micfil {
> + /* reserved for M7 */
> + status = "disabled";
> +};
For this usecase usually status needs to be set to "reserved".
Otherwise,
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
* [PATCH] stm: p_sys-t: Fix su_mutex held across wrong region in interval stores
From: Yingchao Deng @ 2026-05-22 12:08 UTC (permalink / raw)
To: Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Greg Kroah-Hartman
Cc: linux-arm-kernel, linux-kernel, quic_yingdeng, jie.gan,
jinlong.mao, tingwei.zhang, Yingchao Deng
subsys->su_mutex is used here to serialize attribute stores against
pdrv->output_open(), which copies the policy node under that mutex:
stp_policy_node_lookup() /* acquires su_mutex, returns holding it */
stm_output_assign()
pdrv->output_open() /* memcpy(&op->node, pn, ...) */
stp_policy_node_put() /* releases su_mutex */
The comment in stm_assign_first_policy() (core.c) makes the intent
explicit: "This allows the pdrv->output_open() in stm_output_assign()
to serialize against the attribute accessors."
sys_t_policy_ts_interval_store() and
sys_t_policy_clocksync_interval_store() however acquired su_mutex
only around the kstrtouint() parse step, a pure local-variable
operation with no shared state. The actual writes to pn->ts_interval
and pn->clocksync_interval were left outside the critical section,
defeating the serialization entirely.
Move the mutex_lock/unlock to bracket the pn field assignment instead.
Fixes: d69d5e83110f ("stm class: Add MIPI SyS-T protocol support")
Fixes: 39f10239df75 ("stm class: p_sys-t: Add support for CLOCKSYNC packets")
Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
---
drivers/hwtracing/stm/p_sys-t.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/stm/p_sys-t.c b/drivers/hwtracing/stm/p_sys-t.c
index bcbbc4d92325..077b62ca3f46 100644
--- a/drivers/hwtracing/stm/p_sys-t.c
+++ b/drivers/hwtracing/stm/p_sys-t.c
@@ -210,12 +210,11 @@ sys_t_policy_ts_interval_store(struct config_item *item, const char *page,
unsigned int ms;
int ret;
- mutex_lock(mutexp);
ret = kstrtouint(page, 10, &ms);
- mutex_unlock(mutexp);
-
if (!ret) {
+ mutex_lock(mutexp);
pn->ts_interval = msecs_to_jiffies(ms);
+ mutex_unlock(mutexp);
return count;
}
@@ -241,12 +240,12 @@ sys_t_policy_clocksync_interval_store(struct config_item *item,
unsigned int ms;
int ret;
- mutex_lock(mutexp);
ret = kstrtouint(page, 10, &ms);
- mutex_unlock(mutexp);
if (!ret) {
+ mutex_lock(mutexp);
pn->clocksync_interval = msecs_to_jiffies(ms);
+ mutex_unlock(mutexp);
return count;
}
---
base-commit: 80dd246accce631c328ea43294e53b2b2dd2aa32
change-id: 20260521-stm-bd597d74ee6d
Best regards,
--
Yingchao Deng <yingdeng@qti.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
From: Andrew Lunn @ 2026-05-22 12:14 UTC (permalink / raw)
To: Abid Ali
Cc: alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-kernel, linux-stm32, mcoquelin.stm32,
netdev, pabeni
In-Reply-To: <20260522065434.6231-1-dev.taqnialabs@gmail.com>
On Fri, May 22, 2026 at 06:54:34AM +0000, Abid Ali wrote:
> On Thu, May 21, 2026 at 20:44:53 +0200, Andrew Lunn wrote:
> > Thanks for the updated commit message.
> >
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>
> Much appreciated.
>
> Should I send a v3 with the Reviewed-by trailer added ?
No need. patchworks will pick it up when the Maintainer applies the
patch. You only need to append it if you need to send a new version of
the patch.
Andrew
^ permalink raw reply
* Re: [PATCH] crypto: atmel - use min3 to simplify atmel_sha_append_sg
From: Herbert Xu @ 2026-05-22 12:28 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512145123.303311-3-thorsten.blum@linux.dev>
On Tue, May 12, 2026 at 04:51:24PM +0200, Thorsten Blum wrote:
> Replace two consecutive min() calls with min3() to simplify the code.
>
> And since count is unsigned and cannot be less than zero, adjust the if
> check and update the comment accordingly.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-sha.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v15 01/28] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
From: Werner Sembach <wse@tuxedocomputers.com>
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports drm_mode_is_420_only() even on a non HDMI connection.
This patch also moves both checks in the same if-case. This eliminates an
extra else-if-case.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Tested-by: Andri Yngvason <andri@yngvason.is>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ba7f98a87808..dfe97897127c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6917,12 +6917,9 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
/* TODO: un-hardcode */
- if (drm_mode_is_420_only(info, mode_in)
- && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
- timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
- else if (drm_mode_is_420_also(info, mode_in)
- && aconnector
- && aconnector->force_yuv420_output)
+ if (drm_mode_is_420_only(info, mode_in) ||
+ (aconnector && aconnector->force_yuv420_output &&
+ drm_mode_is_420_also(info, mode_in)))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
else if ((connector->display_info.color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
&& aconnector
--
2.54.0
^ permalink raw reply related
* [PATCH v15 02/28] drm/display: hdmi-state-helper: Use default case for unsupported formats
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Cristian Ciocaltea
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
Switch statements that do not handle all possible values of an
enumeration will generate a warning during compilation. In preparation
for adding a COUNT value to the end of the enum, this needs to be dealt
with.
Add a default case to sink_supports_format_bpc's DRM_OUTPUT_COLOR_FORMAT
switch statement, and move the log-and-return unknown pixel format
handling into it.
No functional change.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index 4867edbf2622..3ba47564caad 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -541,10 +541,11 @@ sink_supports_format_bpc(const struct drm_connector *connector,
drm_dbg_kms(dev, "YUV444 format supported in that configuration.\n");
return true;
- }
- drm_dbg_kms(dev, "Unsupported pixel format.\n");
- return false;
+ default:
+ drm_dbg_kms(dev, "Unsupported pixel format.\n");
+ return false;
+ }
}
static enum drm_mode_status
--
2.54.0
^ permalink raw reply related
* [PATCH v15 00/28] Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason,
Cristian Ciocaltea, Marius Vlad, Dmitry Baryshkov, Andy Yan
Hello,
this is a follow-up to
https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
which in of itself is a follow-up to
https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/ where
a new DRM connector property has been added allowing users to
force a particular color format.
That in turn was actually also a follow-up from Werner Sembach's posted at
https://lore.kernel.org/dri-devel/20210630151018.330354-1-wse@tuxedocomputers.com/
As the number of cooks have reached critical mass, I'm hoping I'll be
the last person to touch this particular series.
We have an implementation in Weston at
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1825 that
adds support for this property. This patch series has been tested
against that MR on i915 (HDMI, DP), amdgpu (HDMI, DP) and on rockchip
(HDMI).
You can also manually test this with modetest like so, but beware that
this is a non-atomic invocation, so testing YUV420 like this will result
in weird outcomes if only some of the modes support YUV420:
$ modetest -s 115:1920x1080-60@NV12 -w 115:'color format':4
where 115 is the connector ID and '4' is the enum value for a particular
color format.
General notes on the approach taken by me: instead of silently switching
to a different format than was explicitly requested, or even worse,
outputting something to the sink the sink doesn't support, bubble up an
error to userspace instead. "color format" is a "I want this" type
property, not a "force this" type property, i.e. the kernel will respect
the limits imposed by the hardware.
Things I've tested:
- HDMI (YCbCr 4:4:4 + YCbCr 4:2:2 (8-bit) + RGB + Auto) on RK3588
- HDMI (YCbCr 4:4:4 + YCbCr 4:2:2 (8-bit) + RGB + Auto) on RK3576
- HDMI (YCbCr 4:4:4, YCbCr 4:2:0, RGB, Auto) + DP (YCbCr 4:4:4, RGB,
Auto) on Intel N97 (i915).
- HDMI (YCbCr 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0, RGB, Auto) + DP (YCbCr
4:4:4, RGB, Auto) on an AMD Radeon RX 550 (amdgpu).
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v15:
- Drop redundant drm_connector_color_format_valid() function
- dw-hdmi-qp-rockchip: make dw_hdmi_qp_rockchip_get_vop_format()'s
return type int, check bstate for IS_ERR rather than NULL, and pass up
error codes to caller
- rebase onto recent drm-tip, necessitating
s/drm_atomic_state/drm_atomic_commit/ in the KUnit tests
- Link to v14: https://patch.msgid.link/20260423-color-format-v14-0-449a419ccbd4@collabora.com
Changes in v14:
- i915: Check for source support of YCbCr444 in both the sink format
validation and when registering the properites on the connectors.
- i915: Split HDMI and DP implementations into separate patches, with
their own supported color formats masks.
- Link to v13: https://patch.msgid.link/20260413-color-format-v13-0-ab37d4dfba48@collabora.com
Changes in v13:
- Introduce a new drm_connector_funcs member that returns the
connector state's color format with additional bells and whistles.
- Implement this new func in drm_bridge_connector to return whatever the
HDMI implementation did if an HDMI bridge is present.
- Call into the drm_connector.h function wrapping this new func in the
recursive bridge chain bus format selection code.
- Link to v12: https://patch.msgid.link/20260409-color-format-v12-0-ce84e1817a27@collabora.com
Changes in v12:
- Rebase on top of Ville's i915 format selection cleanup series
- i915: Reimplement based on new format selection code. Drop the DP-MST
implementation, as sinks with different sets of supported formats
complicate the matter.
- Adjust documentation on drm_connector_color_format enum values to
mention quantization ranges.
- Add documentation to drm-kms page to document the string values for
the property. Mostly the same documentation as the enum values, but
from a more userspace-centric perspective. This is done in the patch
that introduces the property, but I didn't drop the existing R-b as
it isn't a functional change.
- Update documentation of "colorspace" property to mention that "color
format" property controls the output format.
- amdgpu: Remove property from DP-MST, as it's unclear whether it'd work
properly with sinks that have different sets of supported formats
- Link to v11: https://patch.msgid.link/20260324-color-format-v11-0-605559af4fb4@collabora.com
Changes in v11:
- amdgpu: fix property registration on DP-MST
- i915: fix property registration on DP-MST
- rebase on drm-tip, which includes Maxime's refactor series that was
previously declared a dependency of this series
- Link to v10: https://lore.kernel.org/r/20260305-color-format-v10-0-a58c68a11868@collabora.com
Changes in v10:
- Make DRM_OUTPUT_COLOR_FORMAT_COUNT and
DRM_CONNECTOR_COLOR_FORMAT_COUNT part of the enum definition (thanks
to Maxime)
- Preemptively avoid the warning that would be generated by the
enumification of DRM_OUTPUT_COLOR_FORMAT_COUNT by modifying the
problematic switch statement in drm_hdmi_state_helper's
sink_supports_format_bpc.
- drm/bridge: Change HDMI check from checking for the last bridge having
a DRM_BRIDGE_OP_HDMI in ops to checking if last_bridge->type is HDMIA.
This is not quite the suggestion Dmitry had, but according to the
documentation of the drm_bridge.type member, and the
display-connector.c code, it should be correct.
- Combine drm_mode_create_color_format_property and
drm_connector_attach_color_format_property into one function named the
latter. (thanks to Dmitry Baryshkov)
- Change author of 'drm: Add new general DRM property "color format"'
to myself as it has by now changed quite a bit, and add Andri and
Werner as Co-developed-by, as per Andri's suggestion.
- hdmi-state-helper: Rework hdmi_compute_config to make code flow more
obvious, and drop Dmitry's R-b as a consequence (thanks to Maxime)
- Move dw-hdmi-qp's atomic_get_output_bus_fmts into
drm_bridge_helper.c, along with kernel doc string (thanks to Dmitry)
- Future-proof the aforementioned get_output_bus_fmts use of hweight8 on
the supported_formats bitmask with a BUILD_BUG_ON.
- Add a KUnit test for the HDMI output bus formats helper
- Link to v9: https://lore.kernel.org/r/20260227-color-format-v9-0-658c3b9db7ef@collabora.com
Changes in v9:
- Document what the "AUTO" behaviour is in the color format enum (thanks
to Maxime)
- drm/bridge: dw-hdmi-qp: Fix a rebase oopsie that reintroduced some
functions that were dropped. (thanks to Cristian)
- drm/bridge: Shuffle "1:1" in the bridge fmt selection docs to earlier
in the sentence. (thanks to Randy Dunlap)
- i915: Check chosen output format against requested format for dp-mst
- All color format driver implementations: rebase and rework on top of
Maxime's series
- As part of this rework, rename drm_color_format_enum to
drm_connector_color_format
- drm kunit tests: rework for the new enums. Changes were trivial, so
trailers were kept
- Link to v8: https://lore.kernel.org/r/20260216-color-format-v8-0-5722ce175dd5@collabora.com
Changes in v8:
- Drop "drm/rockchip: vop2: Fix YUV444 output", as the original problem
could not be reproduced anymore, and the justification did not make
sense.
- Remove the 12-bit format from "drm/rockchip: vop2: Recognise 10/12-bit
YUV422 as YUV formats".
- Refactor to keep the original DRM_COLOR_FORMAT bitshifted defines
as-is, but introduce a new drm_color_format_enum enum.
- Adjust conversion functions for the newly refactored enum, ensuring
they only return valid enum values, and only convert in directions
that open up no error value cans of worms.
- Rework the property uapi code for the newly refactored enum, since
it no longer needs to do any bitshifting or ffs().
- Rework all the device drivers for the new enum.
- Rework all the tests for the refactored enum.
- Rework the hdmi state helper for the new enum, and also make it more
explicit about the auto behaviour by not relying on a conversion
function to map AUTO to RGB, but do this in the framework itself.
- rockchip dw_hdmi_qp: Fix the GRF value to check for color >= 0 instead
of color > 0, as the latter broke switching back to RGB.
- Rebase onto a recent drm-tip. This necessitated blindly reworking some
of the i915 dp-mst code.
- Drop the __maybe_unused edid test patch, as I could no longer
reproduce the build warnings I added it for. I blame ghosts.
- drm_bridge tests: remove "destroyed" member from struct
drm_bridge_chain_priv and all associated code, as it was not used in
any test.
- Link to v7: https://lore.kernel.org/r/20260121-color-format-v7-0-ef790dae780c@collabora.com
Changes in v7:
- Fix drm_bridge kunit test build failure caused by rebasing across an
API change.
- Make compilers shut up about unused EDID definitions in the test
suites.
- Empty line checkpatch fixes that b4 prep --check didn't catch.
- Link to v6: https://lore.kernel.org/r/20260121-color-format-v6-0-7b81a771cd0b@collabora.com
Changes in v6:
- Checkpatch fixes
- Add drm_bridge.c kerneldoc fix patch to b4 deps so the kernel docs
required for every contribution to the subsystem can be built
- dw-hdmi-qp core has gained the atomic_get_output_bus_fmts bridge func,
which allows it to participate in the drm_bridge chain recursive format
selection code properly.
- The Rockchip dw-hdmi-qp integration now no longer reimplements the
color format logic (improperly), but reads the bus format of the first
bridge as set by the recursive bridge format selection. If the input
format is FIXED, it'll use the output format. Otherwise, the input
format is used.
- In the synopsys drivers, YUV422 uses the same bus format as the non-qp
hdmi encoder driver. Probably correcter this way. The Rockchip vop2
is_yuv function has been extended to recognise this format as well.
- KUnit tests for drm_bridge chains are now included, which exercise the
chain's recursive bus format selection.
- On HDMI connectors, the drm_bridge bus format selection will try to target
the color format that the HDMI layer came up with. This means the AUTO
logic is not duplicated for HDMI connectors.
- The enum conversion function commit gained a function for converting
from hdmi_colorspace to drm_color_format, and its author changed as no
original code remains anyway. Marius is still included as a
Co-developer.
- Some tests for the HDMI state helper's mode_valid have been written.
They are incomplete as we lack a test EDID for a 420-also mode that
would violate the clock constraints on RGB. I hacked one together with
a hex editor, but it reports a too high of a clock rate, and there's
no EDID editor I could find which supports these extension blocks.
- The color_format KUnit tests have been more heavily parameterised, the
auto case absorbed into other tests, and the comments around them
rewritten.
- Add a few paragraphs of documentation that explain the bridge format
selection, and how to make use of it in a display driver.
- Link to v5: https://lore.kernel.org/r/20251128-color-format-v5-0-63e82f1db1e1@collabora.com
Changes in v5:
- Rebase onto drm-tip
- Drop DRM_MODE_COLOR_FORMAT_* as an enum
- Unify DRM_COLOR_FORMAT_NONE and DRM_COLOR_FORMAT_AUTO, with AUTO being
0. This makes conversion and general logic much easier.
- Adjust the drm_color_format enum to not needlessly renumber the
existing defines, as it doesn't need to correspond to how HDMI numbers
them.
- Make the DRM-to-HDMI conversion function static inline __pure, because
the assembly it generates is tiny, and the function is pure.
- Don't accept nothing as the list of supported color formats for
registration of the property.
- Drop the per-connector variants of the color format registration
function, as it's not needed.
- drm_hdmi_state_helper: Fix mode_valid rejecting 420-only modes.
- drm_hdmi_state_helper: Only fall back to YUV420 with
DRM_COLOR_FORMAT_AUTO.
- drm_hdmi_state_helper: Remove redundant AUTO->RGB condition, as the
conversion already does this.
- Add KUnit tests for hdmi_compute_config.
- drm/bridge: Refactor bus_format_is_color_fmt and add a few more YUV422
formats.
- Register the color format property in drmm_connector_hdmi_init based
on the supported HDMI formats passed to it. This means rockchip
dw_hdmi_qp no longer needs to register it.
- amdgpu: Simplify YUV420 logic
- amdgpu: Don't try to pick YUV444 on YUV420-only modes
- i915: Try to make behaviour more or less the same as that of the drm
hdmi state helper.
- rockchip dw_hdmi_qp: Set supported HDMI formats
- rockchip dw_hdmi_qp: Set the right VO GRF values depending on color
format.
- rockchip dw_hdmi_qp: Act on the color format property in this driver,
rather than in VOP2, by setting the bus_format appropriately.
- rockchip VOP2: Can the BCSH-based implementation. BCSH isn't available
on all video ports of the hardware, and the code was extremely
suspect. Instead, plug into the existing YUV-to-RGB/RGB-to-YUV code,
which can be done now that the HDMI driver sets the bus format.
- A whole bunch of Rockchip VOP2 fixes.
- Link to v4: https://lore.kernel.org/r/20251117-color-format-v4-0-0ded72bd1b00@collabora.com
Changes in v4:
- Rebase onto next-20251117
- Get rid of HDMI_COLORSPACE_AUTO
- Split hdmi_compute_config change into separate patch
- Add missing symbol export for color_format_to_hdmi_colorspace to fix
builds in certain configurations
- Drop "drm: Pass supported color formats straight onto drm_bridge"
- Make dw-hdmi-qp set the platform data's supported color formats as
the bridge's supported HDMI color formats
- drm_hdmi_state_helper: pass requested color format to
hdmi_compute_format_bpc if set.
- drm_bridge: limit the bus formats to those explicitly requested with
the color format property during the atomic bridge check call,
specifically in drm_atomic_bridge_chain_select_bus_fmts.
- i915: Remove INTEL_OUTPUT_FORMAT_AUTO, as automatic format selection
does not need to involve the hardware state
- i915: Deduplicate ntel_output_format_to_drm_color_format code by
moving it as a static inline __pure function into a shared header
- i915: rework logic in HDMI, DP and DP-MST output config functions to
remove redundant locals, simplify execution flow, and return an error
to userspace if an explicit color_format request can't be satisfied.
- i915: assign myself as the author and make the others Co-developers,
so that they don't get the blame for any of my bugs.
- amdgpu: refactor fill_stream_properties_from_drm_display_mode to
improve readability and ensure that impossible color format requests
get bubbled up to userspace as errors
- amdgpu: don't pick YUV444 over RGB.
- amdgpu: assign authorship to myself, with others as Co-developers, as
logic was modified and the blame should fall on me
- dw_hdmi_qp-rockchip: set the supported color formats platform data
member
- rockchip: remove drm property registration for rk3066_hdmi and
inno_hdmi. None of the platforms that use these use vop2 as the
video output processor.
- Link to v3: https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
Changes in v3 by mvlad compared to Andri's v2 series:
- renamed the property to just 'color format'
- the property is added dynamically similar to the Colorspace property
- a key point from previous comments was that drivers should advertise
the color formats they support and userspace would query EDID and
perform an intersection from those color formats which users can
further use. With this patch set each driver that adds this property
has such list of hard-coded color formats, but fundamentally the idea
is that driver can query the HW and do that on its own. The
infrastructure is now in place to allow to do that
- by default the 'AUTO' color format is set. With this patch series that
has been introduced as a fallback to RGB. Drivers could further
customize this behavour and could perform additional checks on the sink
to pick another suitable color format they'd like for AUTO
- drm_bridge bridge code has been improved to allow initialization with
the same color formats list as the DRM connector property. Similarly, bpc
pick-up now takes the color format into consideration when deciding
which bpc to choose from
- The new DRM color format re-uses HDMI_COLORPSACE enum and provides an
enum translations between the two to avoid touching all other drivers that
use HDMI_COLORPSACE enum. I believe at this point that this allows the
least amount of disruption and avoids a massive bike shedding around
that part
- a rockchip implementation has been by my colleague Derek Foreman
- YUV444 color format has been added in i915
- address comment about "Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A
check" where aconnector might be invalid
- Link to v2: https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/
---
Nicolas Frattaroli (27):
drm/display: hdmi-state-helper: Use default case for unsupported formats
drm: Add new general DRM property "color format"
drm/connector: Let connectors have a say in their color format
drm/display: bridge_connector: Use HDMI color format for HDMI conns
drm/bridge: Act on the DRM color format property
drm/atomic-helper: Add HDMI bridge output bus formats helper
drm/display: hdmi-state-helper: Act on color format DRM property
drm/display: hdmi-state-helper: Try subsampling in mode_valid
drm/amdgpu: Implement "color format" DRM property
drm/i915/hdmi: Add YCBCR444 handling for sink formats
drm/i915/dp: Add YCBCR444 handling for sink formats
drm/i915/hdmi: Implement "color format" DRM property
drm/i915/dp: Implement "color format" DRM property
drm/rockchip: Add YUV422 output mode constants for VOP2
drm/rockchip: vop2: Add RK3576 to the RG swap special case
drm/rockchip: vop2: Recognise 10-bit YUV422 as YUV format
drm/rockchip: vop2: Set correct output format for RK3576 YUV422
drm/bridge: dw-hdmi-qp: Use common HDMI output bus fmts helper
drm/rockchip: dw_hdmi_qp: Implement "color format" DRM property
drm/rockchip: dw_hdmi_qp: Set supported_formats platdata
drm/connector: Register color format property on HDMI connectors
drm/tests: hdmi: Add tests for the color_format property
drm/tests: hdmi: Add tests for HDMI helper's mode_valid
drm/tests: bridge: Add KUnit tests for bridge chain format selection
drm/tests: bridge: Add test for HDMI output bus formats helper
drm/bridge: Document bridge chain format selection
drm/connector: Update docs of "colorspace" for color format prop
Werner Sembach (1):
drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
Documentation/gpu/drm-kms-helpers.rst | 6 +
Documentation/gpu/drm-kms.rst | 6 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 91 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 1 +
drivers/gpu/drm/display/drm_bridge_connector.c | 24 +
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 53 +-
drivers/gpu/drm/drm_atomic_helper.c | 86 ++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +
drivers/gpu/drm/drm_bridge.c | 104 ++-
drivers/gpu/drm/drm_connector.c | 178 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 82 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 84 +-
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 111 ++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 4 +
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 21 +-
drivers/gpu/drm/tests/drm_bridge_test.c | 971 +++++++++++++++++++++
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 345 ++++++++
include/drm/drm_atomic_helper.h | 7 +
include/drm/drm_connector.h | 96 ++
19 files changed, 2237 insertions(+), 37 deletions(-)
---
base-commit: 8345929e243a7114bc17c48d0ff01923d2daae76
change-id: 20251028-color-format-49fd202b7183
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
^ permalink raw reply
* [PATCH v15 04/28] drm/connector: Let connectors have a say in their color format
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
Add a function to get the connector color format from a connector state,
and a new function pointer in drm_connector_funcs to allow connectors to
override what connector color format it returns.
This is useful for the bridge chain recursive bus format selection code,
which does not wish to implement connector implementation specific
checks like whether it involves HDMI.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_connector.c | 16 ++++++++++++++++
include/drm/drm_connector.h | 12 ++++++++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a0fca522f18f..41a5ab1e563e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -3685,6 +3685,22 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
}
EXPORT_SYMBOL(drm_connector_oob_hotplug_event);
+/**
+ * drm_connector_get_color_format - Return connector color format of @conn_state
+ * @conn_state: pointer to the &struct drm_connector_state to go check
+ *
+ */
+enum drm_connector_color_format
+drm_connector_get_color_format(const struct drm_connector_state *conn_state)
+{
+ struct drm_connector *connector = conn_state->connector;
+
+ if (connector->funcs->color_format)
+ return connector->funcs->color_format(conn_state);
+
+ return conn_state->color_format;
+}
+EXPORT_SYMBOL(drm_connector_get_color_format);
/**
* DOC: Tile group
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 03e42c36175d..c9aad2bc8227 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1787,6 +1787,16 @@ struct drm_connector_funcs {
* Allows connectors to create connector-specific debugfs files.
*/
void (*debugfs_init)(struct drm_connector *connector, struct dentry *root);
+
+ /**
+ * @color_format:
+ *
+ * Allows connectors to return a connector color format other than
+ * @conn_state.color_format for purposes of e.g. display protocol
+ * specific helper logic having already mapped it to an output format.
+ */
+ enum drm_connector_color_format (*color_format)(
+ const struct drm_connector_state *conn_state);
};
/**
@@ -2603,6 +2613,8 @@ drm_connector_is_unregistered(struct drm_connector *connector)
void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
enum drm_connector_status status);
+enum drm_connector_color_format
+drm_connector_get_color_format(const struct drm_connector_state *conn_state);
const char *drm_get_connector_type_name(unsigned int connector_type);
const char *drm_get_connector_status_name(enum drm_connector_status status);
const char *drm_get_subpixel_order_name(enum subpixel_order order);
--
2.54.0
^ permalink raw reply related
* [PATCH v15 03/28] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
Add a new general DRM property named "color format" which can be used by
userspace to request the display driver to output a particular color
format.
Possible string values for the new enum property are:
- "AUTO" (setup by default, driver internally picks the color format)
- "RGB"
- "YUV 4:4:4"
- "YUV 4:2:2"
- "YUV 4:2:0"
Drivers should advertise from this list the formats they support in an
optimistic best-case scenario. EDID data from the sink can then be used
in the kernel's atomic check phase to restrict this set of formats, as
well as by userspace to make a correct choice in the first place.
Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Co-developed-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_atomic_helper.c | 5 ++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +
drivers/gpu/drm/drm_connector.c | 155 ++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 84 +++++++++++++++++++
5 files changed, 254 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index fa69a5450f96..2b6a96211cfc 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -604,6 +604,12 @@ Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:doc: overview
+Color Format Property
+---------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :doc: Color format
+
Tile Group Property
-------------------
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 51f39edc31ed..3547f797a850 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->color_format !=
+ new_connector_state->color_format)
+ new_crtc_state->connectors_changed = true;
+
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 6441b55cc274..c7f80d90794c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -935,6 +935,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
state->privacy_screen_sw_state = val;
} else if (property == connector->broadcast_rgb_property) {
state->hdmi.broadcast_rgb = val;
+ } else if (property == connector->color_format_property) {
+ state->color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1020,6 +1022,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
*val = state->privacy_screen_sw_state;
} else if (property == connector->broadcast_rgb_property) {
*val = state->hdmi.broadcast_rgb;
+ } else if (property == connector->color_format_property) {
+ *val = state->color_format;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3fa4d2082cd7..a0fca522f18f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
+static const u32 hdmi_colorformats =
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
+
+static const u32 dp_colorformats =
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
+
/*
* As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
* Format Table 2-120
@@ -2935,6 +2947,149 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
+/**
+ * DOC: Color format
+ *
+ * The connector "color format" property allows userspace to request a specific
+ * color model on the output of the connector. Not all values listed by the
+ * property are guaranteed to work for every sink; rather, it is an optimistic
+ * listing of color formats that the source could output depending on
+ * circumstances.
+ *
+ * Whether it actually can output a certain color format is determined during
+ * the atomic check phase. Consequently, a userspace application that sets the
+ * color format to a value other than "AUTO" should check whether its atomic
+ * commit succeeded.
+ *
+ * Possible values for "color format":
+ *
+ * "AUTO":
+ * The driver or display protocol helpers should pick a suitable color
+ * format. All implementations of a specific display protocol will behave
+ * the same way with "AUTO", but different display protocols do not
+ * necessarily have the same "AUTO" semantics.
+ *
+ * For HDMI connectors, "AUTO" picks RGB, but falls back to YUV 4:2:0 if
+ * the bandwidth required for full-scale RGB is not available, or the mode
+ * is YUV 4:2:0-only, as long as the mode, source, and sink all support
+ * YUV 4:2:0.
+ * "RGB":
+ * RGB output format. The quantization range (limited/full) depends on the
+ * value of the "Broadcast RGB" property if it is present on the connector.
+ * "YUV 4:4:4":
+ * YUV 4:4:4 (a.k.a. YCbCr 4:4:4) output format. Chroma is not subsampled.
+ * The quantization range defaults to limited.
+ * "YUV 4:2:2":
+ * YUV 4:2:2 (a.k.a. YCbCr 4:2:2) output format. Chroma has half the
+ * horizontal resolution of Luma. The quantization range defaults to
+ * limited.
+ * "YUV 4:2:0":
+ * YUV 4:2:0 (a.k.a. YCbCr 4:2:0) output format. Chroma has half the
+ * horizontal and vertical resolution of Luma. The quantization range
+ * defaults to limited.
+ *
+ * A sink may only support some color formats in specific modes and at specific
+ * bit depths. The atomic modesetting API should be used to set a working
+ * configuration in one go, as an unsupported combination of parameters is
+ * rejected.
+ */
+
+/**
+ * drm_connector_attach_color_format_property - create and attach color format property
+ * @connector: connector to create the color format property on
+ * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
+ * values the connector supports
+ *
+ * Called by a driver to create a color format property. The property is
+ * attached to the connector automatically on success.
+ *
+ * @supported_color_formats should only include color formats the connector
+ * type can actually support.
+ *
+ * Returns:
+ * 0 on success, negative errno on error
+ */
+int drm_connector_attach_color_format_property(struct drm_connector *connector,
+ unsigned long supported_color_formats)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
+ unsigned int i = 0;
+ unsigned long fmt;
+
+ if (connector->color_format_property)
+ return 0;
+
+ if (!supported_color_formats) {
+ drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
+ drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ if (supported_color_formats & ~hdmi_colorformats) {
+ drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+ break;
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_eDP:
+ if (supported_color_formats & ~dp_colorformats) {
+ drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+ break;
+ }
+
+ enum_list[0].name = "AUTO";
+ enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
+
+ for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
+ switch (fmt) {
+ case DRM_OUTPUT_COLOR_FORMAT_RGB444:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
+ break;
+ default:
+ drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
+ fmt, connector->base.id, connector->name);
+ continue;
+ }
+ enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
+ }
+
+ connector->color_format_property =
+ drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
+ enum_list, i + 1);
+
+ if (!connector->color_format_property)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, connector->color_format_property,
+ DRM_CONNECTOR_COLOR_FORMAT_AUTO);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_color_format_property);
+
/**
* drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
* @old_state: old connector state to compare
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5ad62c207d00..03e42c36175d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -571,12 +571,80 @@ enum drm_colorspace {
* YCbCr 4:2:2 output format (ie. with horizontal subsampling)
* @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
* YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
+ * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
+ * Number of valid output color format values in this enum
*/
enum drm_output_color_format {
DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
+ DRM_OUTPUT_COLOR_FORMAT_COUNT,
+};
+
+/**
+ * enum drm_connector_color_format - Connector Color Format Request
+ *
+ * This enum, unlike &enum drm_output_color_format, is used to specify requests
+ * for a specific color format on a connector through the DRM "color format"
+ * property. The difference is that it has an "AUTO" value to specify that
+ * no specific choice has been made.
+ */
+enum drm_connector_color_format {
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
+ * helpers should pick a suitable color format. All implementations of a
+ * specific display protocol must behave the same way with "AUTO", but
+ * different display protocols do not necessarily have the same "AUTO"
+ * semantics.
+ *
+ * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
+ * bandwidth required for full-scale RGB is not available, or the mode
+ * is YCbCr 4:2:0-only, as long as the mode and output both support
+ * YCbCr 4:2:0.
+ *
+ * For display protocols other than HDMI, the recursive bridge chain
+ * format selection picks the first chain of bridge formats that works,
+ * as has already been the case before the introduction of the "color
+ * format" property. Non-HDMI bridges should therefore either sort their
+ * bus output formats by preference, or agree on a unified auto format
+ * selection logic that's implemented in a common state helper (like
+ * how HDMI does it).
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format. The
+ * quantization range depends on the value of the "Broadcast RGB"
+ * property if it is present on the connector.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_RGB444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
+ * not subsampled). Quantization range is "Limited" by default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
+ * with horizontal subsampling). Quantization range is "Limited" by
+ * default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
+ * with horizontal and vertical subsampling). Quantization range is
+ * "Limited" by default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
+ * format values in this enum
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_COUNT,
};
const char *
@@ -1167,6 +1235,13 @@ struct drm_connector_state {
*/
enum drm_colorspace colorspace;
+ /**
+ * @color_format: State variable for Connector property to request
+ * color format change on Sink. This is most commonly used to switch
+ * between RGB to YUV and vice-versa.
+ */
+ enum drm_connector_color_format color_format;
+
/**
* @writeback_job: Writeback job for writeback connectors
*
@@ -2165,6 +2240,12 @@ struct drm_connector {
*/
struct drm_property *colorspace_property;
+ /**
+ * @color_format_property: Connector property to set the suitable
+ * color format supported by the sink.
+ */
+ struct drm_property *color_format_property;
+
/**
* @path_blob_ptr:
*
@@ -2648,6 +2729,9 @@ bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
+int drm_connector_attach_color_format_property(struct drm_connector *connector,
+ unsigned long supported_color_formats);
+
/**
* drm_for_each_connector_iter - connector_list iterator macro
* @connector: &struct drm_connector pointer used as cursor
--
2.54.0
^ permalink raw reply related
* [PATCH v15 05/28] drm/display: bridge_connector: Use HDMI color format for HDMI conns
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
For bridge connectors which contain an HDMI bridge at some stage, the
HDMI state helpers' format selection logic should be involved.
Add an implementation for the drm_bridge_funcs color_format function,
which translates from the HDMI state's output format to a connector
format for bridge connectors involving an HDMI bridge, but return the
connector state's color_format member unchanged otherwise.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 649969fca141..19da5f668942 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -276,6 +276,29 @@ static void drm_bridge_connector_reset(struct drm_connector *connector)
connector->state);
}
+static enum drm_connector_color_format
+drm_bridge_connector_color_format(const struct drm_connector_state *conn_state)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(conn_state->connector);
+
+ if (bridge_connector->bridge_hdmi) {
+ switch (conn_state->hdmi.output_format) {
+ default:
+ case DRM_OUTPUT_COLOR_FORMAT_RGB444:
+ return DRM_CONNECTOR_COLOR_FORMAT_RGB444;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
+ return DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
+ return DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
+ return DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
+ }
+ }
+
+ return conn_state->color_format;
+}
+
static const struct drm_connector_funcs drm_bridge_connector_funcs = {
.reset = drm_bridge_connector_reset,
.detect = drm_bridge_connector_detect,
@@ -285,6 +308,7 @@ static const struct drm_connector_funcs drm_bridge_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.debugfs_init = drm_bridge_connector_debugfs_init,
.oob_hotplug_event = drm_bridge_connector_oob_hotplug_event,
+ .color_format = drm_bridge_connector_color_format,
};
/* -----------------------------------------------------------------------------
--
2.54.0
^ permalink raw reply related
* [PATCH v15 06/28] drm/bridge: Act on the DRM color format property
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
The new DRM color format property allows userspace to request a specific
color format on a connector. In turn, this fills the connector state's
color_format member to switch color formats.
Make drm_bridges consider the color_format set in the connector state
during the atomic bridge check. Call into the connector function to get
the connector state's connector color format. For bridge connectors
including an HDMI bridge, this will make use of whatever the HDMI
implementation set as output formats, and AUTO will never be part of the
rejection logic.
Reject any output bus formats that do not correspond to the requested
color format. DRM_CONNECTOR_COLOR_FORMAT_AUTO is always accepted as a
matching color format for a bus format, meaning that non-HDMI bridge
chains will end up picking the first bus format choice that works, as
has already been the case previously.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_bridge.c | 64 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 687b36eea0c7..6ec8c23b36b5 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -1149,6 +1149,47 @@ static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
return ret;
}
+static bool __pure bus_format_is_color_fmt(u32 bus_fmt, enum drm_connector_color_format fmt)
+{
+ if (fmt == DRM_CONNECTOR_COLOR_FORMAT_AUTO)
+ return true;
+
+ switch (bus_fmt) {
+ case MEDIA_BUS_FMT_FIXED:
+ return true;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ case MEDIA_BUS_FMT_RGB121212_1X36:
+ case MEDIA_BUS_FMT_RGB161616_1X48:
+ return fmt == DRM_CONNECTOR_COLOR_FORMAT_RGB444;
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ case MEDIA_BUS_FMT_YUV12_1X36:
+ case MEDIA_BUS_FMT_YUV16_1X48:
+ return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
+ case MEDIA_BUS_FMT_UYVY8_1X16:
+ case MEDIA_BUS_FMT_VYUY8_1X16:
+ case MEDIA_BUS_FMT_YUYV8_1X16:
+ case MEDIA_BUS_FMT_YVYU8_1X16:
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ case MEDIA_BUS_FMT_YUYV10_1X20:
+ case MEDIA_BUS_FMT_VYUY10_1X20:
+ case MEDIA_BUS_FMT_YVYU10_1X20:
+ case MEDIA_BUS_FMT_UYVY12_1X24:
+ case MEDIA_BUS_FMT_VYUY12_1X24:
+ case MEDIA_BUS_FMT_YUYV12_1X24:
+ case MEDIA_BUS_FMT_YVYU12_1X24:
+ return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
+ case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+ case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+ case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+ case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+ return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
+ default:
+ return false;
+ }
+}
+
/*
* This function is called by &drm_atomic_bridge_chain_check() just before
* calling &drm_bridge_funcs.atomic_check() on all elements of the chain.
@@ -1192,6 +1233,7 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
struct drm_encoder *encoder = bridge->encoder;
struct drm_bridge_state *last_bridge_state;
unsigned int i, num_out_bus_fmts = 0;
+ enum drm_connector_color_format fmt;
u32 *out_bus_fmts;
int ret = 0;
@@ -1233,11 +1275,31 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
}
+ /*
+ * Instead of directly accessing conn_state.color_format, call into a
+ * connector function that allows connector implementations (e.g. for
+ * bridge connectors including HDMI bridges, where the HDMI helpers will
+ * have already chosen an appropriate output format) to override the
+ * selected format.
+ */
+ fmt = drm_connector_get_color_format(conn_state);
+
for (i = 0; i < num_out_bus_fmts; i++) {
+ if (!bus_format_is_color_fmt(out_bus_fmts[i], fmt)) {
+ drm_dbg_kms(last_bridge->dev,
+ "Skipping bus format 0x%04x as it doesn't match format %d\n",
+ out_bus_fmts[i], fmt);
+ ret = -ENOTSUPP;
+ continue;
+ }
ret = select_bus_fmt_recursive(bridge, last_bridge, crtc_state,
conn_state, out_bus_fmts[i]);
- if (ret != -ENOTSUPP)
+ if (ret != -ENOTSUPP) {
+ drm_dbg_kms(last_bridge->dev,
+ "Found bridge chain ending with bus format 0x%04x\n",
+ out_bus_fmts[i]);
break;
+ }
}
kfree(out_bus_fmts);
--
2.54.0
^ permalink raw reply related
* [PATCH v15 07/28] drm/atomic-helper: Add HDMI bridge output bus formats helper
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
The drm_bridge_funcs atomic_get_output_bus_fmts operation should be the
same for likely every HDMI connector bridge, unless such an HDMI
connector bridge has some special hardware restrictions that I cannot
envision yet.
To avoid code duplication and standardize on a set of media bus formats
that the HDMI output color formats translate to, add a common helper
function that implements this operation to the drm bridge helpers.
The function returns a list of output bus formats based on the HDMI
bridge's current output bits-per-component, and its bitmask of supported
color formats.
To guard against future expansion of DRM_OUTPUT_COLOR_FORMAT outgrowing
the hweight8 call, add a BUILD_BUG_ON statement where it's used that
checks for DRM_OUTPUT_COLOR_FORMAT_COUNT. The justification for not
using hweight32 in all cases is that not all ISAs have a popcount
instruction, and will benefit from a smaller/faster software
implementation that doesn't have to operate across all bits.
The justification for not defining an hweight_color depending on the
value of DRM_OUTPUT_COLOR_FORMAT_COUNT is that this count enum value is
only known at compile time, not at preprocessor time.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 81 +++++++++++++++++++++++++++++++++++++
include/drm/drm_atomic_helper.h | 7 ++++
2 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 3547f797a850..285aac3554df 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -28,6 +28,7 @@
#include <linux/export.h>
#include <linux/dma-fence.h>
#include <linux/ktime.h>
+#include <linux/media-bus-format.h>
#include <drm/drm_atomic.h>
#include <drm/drm_atomic_helper.h>
@@ -4107,3 +4108,83 @@ drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
return input_fmts;
}
EXPORT_SYMBOL(drm_atomic_helper_bridge_propagate_bus_fmt);
+
+/**
+ * drm_atomic_helper_bridge_get_hdmi_output_bus_fmts - helper implementing
+ * atomic_get_output_bus_fmts for HDMI
+ * @bridge: pointer to &struct drm_bridge
+ * @bridge_state: pointer to the current bridge state
+ * @crtc_state: pointer to the current CRTC state
+ * @conn_state: pointer to the current connector state
+ * @num_output_fmts: pointer to where the number of entries in the returned array
+ * will be stored. Set to 0 if unsuccessful.
+ *
+ * Common implementation for the &drm_bridge_funcs.atomic_get_output_bus_fmts
+ * operation that's applicable to HDMI connectors.
+ *
+ * Returns: a newly allocated array of u32 values of length \*@num_output_fmts,
+ * representing all the MEDIA_BUS_FMTS\_ for the current connector state's
+ * chosen HDMI output bits per compoennt, or %NULL if it fails to allocate one.
+ */
+u32 *
+drm_atomic_helper_bridge_get_hdmi_output_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ unsigned int *num_output_fmts)
+{
+ unsigned int num_fmts = 0;
+ u32 *out_fmts;
+
+ /*
+ * bridge->supported_formats is a bit field of BIT(enum drm_output_color_format)
+ * values. The smallest hweight that is smaller than or equal to
+ * %DRM_OUTPUT_COLOR_FORMAT_COUNT will do for counting set bits here.
+ */
+ BUILD_BUG_ON(const_true(DRM_OUTPUT_COLOR_FORMAT_COUNT > 8));
+ out_fmts = kmalloc_array(hweight8(bridge->supported_formats),
+ sizeof(u32), GFP_KERNEL);
+ if (!out_fmts) {
+ *num_output_fmts = 0;
+ return NULL;
+ }
+
+ switch (conn_state->hdmi.output_bpc) {
+ case 12:
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_RGB121212_1X36;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_YUV12_1X36;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYVY12_1X24;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYYVYY12_0_5X36;
+ break;
+ case 10:
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_RGB101010_1X30;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_YUV10_1X30;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYVY10_1X20;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYYVYY10_0_5X30;
+ break;
+ default:
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_RGB888_1X24;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_YUV8_1X24;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYVY8_1X16;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYYVYY8_0_5X24;
+ break;
+ }
+
+ *num_output_fmts = num_fmts;
+
+ return out_fmts;
+}
+EXPORT_SYMBOL(drm_atomic_helper_bridge_get_hdmi_output_bus_fmts);
+
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index b84152810abb..4cfeec70d648 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -295,4 +295,11 @@ drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
u32 output_fmt,
unsigned int *num_input_fmts);
+u32 *
+drm_atomic_helper_bridge_get_hdmi_output_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ unsigned int *num_output_fmts);
+
#endif /* DRM_ATOMIC_HELPER_H_ */
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox