* [PATCH v2 08/10] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com>
The imx8mp-hdmi-tx is one of many drivers based on dw-hdmi. dw-hdmi in turn
can operate in two different modes, depending on the platform data as set
by the driver:
A. hdmi->plat_data->output_port = 0:
the HDMI output (port@1) in device tree is not used [0]
B. hdmi->plat_data->output_port = 1:
the HDMI output (port@1) is parsed to find the next bridge
The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
in that case it adds an HDMI Type A connector programmatically at bridge
attach time.
Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
case B. However switching to base B requires that port@1 is connected to a
"next bridge" DT node, typically the HDMI connector, because dw-hdmi won't
add the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Many dts files for imx8mp-based boards in the kernel have such a connector
described and linked to port@1, so the pipeline will be fully attached up
to a display-connector and a drm_connector added by the
bridge-connector. Sadly some of those dts files don't have the connector
described. Adding it would solve the problem easily, but this would break
existing devices which do not update the dtb when upgrading to a newer
kernel.
In preparation for switching to case B while preserving backward
compatibility for such devices, introduce a module adding the
hdmi-connector node to the live device tree at init time. This will allow
the dw-hdmi code to find the next bridge (the one wrapping the
hdmi-connector) and let the pipeline work as before.
The module is inserted only if there is no endpoint in port@1. So boards
whose device tree describe the connector will not have the device tre
modified, and will start isntantiating the correct HDMI connector type as
described in the device tree.
For boards lacking a connector description in DT the overlay will be added,
abd the HDMI connector will be Type A, which is a reasonable fallback and
is what the driver is currently doing.
[0] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
[1] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2907
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- don't apply the overlay if the SoC is not i.MX8MP
- build unconditionally, but depend on DRM_IMX_LCDIF
- remove useless error check
- add missing cleanup.h and init.h includes, remove unneeded includes
- avoid dtc warnings on overlay
- fix typo in Kconfig help text
- not added the Tested-bys because the code has changed
- split the 'plat_data->output_port = 1' line to a separate patch
This patch is inspired by commit 0ff223d99147 ("drm/tilcdc: Convert legacy
panel binding via DT overlay at boot time")
---
drivers/gpu/drm/bridge/imx/Kconfig | 18 +++++++
drivers/gpu/drm/bridge/imx/Makefile | 2 +
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 53 ++++++++++++++++++++
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 56 ++++++++++++++++++++++
4 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
index b9028a5e5a06..49f074559b00 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -18,6 +18,8 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
depends on OF
depends on COMMON_CLK
select DRM_DW_HDMI
+ select OF_OVERLAY
+ select DRM_DISPLAY_CONNECTOR
imply DRM_IMX8MP_HDMI_PAI
imply DRM_IMX8MP_HDMI_PVI
imply PHY_FSL_SAMSUNG_HDMI_PHY
@@ -25,6 +27,22 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
Choose this to enable support for the internal HDMI encoder found
on the i.MX8MP SoC.
+config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
+ bool
+ default y
+ depends on DRM_IMX_LCDIF
+ depends on DRM_IMX8MP_DW_HDMI_BRIDGE
+ depends on OF
+ help
+ Modifies at early boot the live device tree of boards using the
+ i.MX8MP fsl,imx8mp-hdmi-tx adding a hdmi-connector node linked to
+ the hdmi-tx. This is needed to support bridge-connector usage in
+ the i.MX8MP LCDIF driver.
+
+ You need this if you use the i.MX8MP HDMI output and your board
+ device tree file does not have an hdmi-connector node connected
+ to it.
+
config DRM_IMX8MP_HDMI_PAI
tristate "Freescale i.MX8MP HDMI PAI bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
index 8d01fda25451..84499fe2e444 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,6 +1,8 @@
obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
obj-$(CONFIG_DRM_IMX_LEGACY_BRIDGE) += imx-legacy-bridge.o
obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE) += imx8mp-hdmi-tx.o
+obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP) += imx8mp-hdmi-tx-connector-fixup.o \
+ imx8mp-hdmi-tx-connector-fixup.dtbo.o
obj-$(CONFIG_DRM_IMX8MP_HDMI_PAI) += imx8mp-hdmi-pai.o
obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
new file mode 100644
index 000000000000..4c0a22bf416b
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Add an hdmi-connector node to boards using the imx8mp hdmi_tx which
+ * don't have one. This is needed for the i.MX LCDIF to work with
+ * DRM_BRIDGE_ATTACH_NO_CONNECTOR.
+ *
+ * Copyright (C) 2026 GE HealthCare
+ * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
+ */
+
+#include <linux/cleanup.h>
+#include <linux/init.h>
+#include <linux/of.h>
+
+/* Embedded dtbo symbols created by cmd_wrap_S_dtb in scripts/Makefile.dtbs */
+extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_begin[];
+extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_end[];
+
+static int __init imx8mp_hdmi_tx_connector_fixup_init(void)
+{
+ struct device_node *soc __free(device_node) = NULL;
+ struct device_node *hdmi_tx __free(device_node) = NULL;
+ struct device_node *endpoint __free(device_node) = NULL;
+ struct device_node *hdmi_conn __free(device_node) = NULL;
+ void *dtbo_start;
+ u32 dtbo_size;
+ int ovcs_id;
+
+ soc = of_find_node_by_path("/soc@0");
+ if (!soc)
+ return 0;
+
+ /* This applies to i.MX8MP only, do nothing on other systems */
+ if (!of_device_is_compatible(soc, "fsl,imx8mp-soc"))
+ return 0;
+
+ hdmi_tx = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000");
+ if (!of_device_is_available(hdmi_tx))
+ return 0;
+
+ /* If endpoint exists, assume an hdmi-connector exists already */
+ endpoint = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1/endpoint");
+ if (endpoint)
+ return 0;
+
+ dtbo_start = __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
+ dtbo_size = __dtbo_imx8mp_hdmi_tx_connector_fixup_end -
+ __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
+
+ return of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
+}
+
+subsys_initcall(imx8mp_hdmi_tx_connector_fixup_init);
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
new file mode 100644
index 000000000000..5dbe06d5ffe7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
+ *
+ * Copyright (C) 2026 GE HealthCare
+ * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ fixup-hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "HDMI";
+ type = "a";
+
+ port {
+ fixup_hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
+ soc@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0 0x3e000000>;
+
+ bus@32c00000 {
+ reg = <0x32c00000 0x400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ hdmi@32fd8000 {
+ reg = <0x32fd8000 0x7eff>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&fixup_hdmi_connector_in>;
+ };
+ };
+ };
+ };
+ };
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 07/10] drm/bridge: dw-hdmi: move next_bridge lookup to attach time
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com>
This driver looks up the next_bridge at probe time and stores it in
hdmi->bridge.next_bridge, but only uses the stored value when attaching,
and only in the DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
This will be problematic with an upcoming change, adding an hdmi-connector
using a device tree overlay when not present. That change is in turn
necessary to migrate the i.MX LCDIF driver to the bridge-connector.
The problem is that, adding the hdmi-connector via an overlay, devlink
considers hdmi-connector a consumer of the dw-hdmi device, generating a
chicken-egg problem:
* hdmi-connector probe won't be tried until dw-hdmi is probed (devlink)
* dw-hdmi probe will defer until it finds the next_bridge (the
hdmi-connector wrapper bridge)
In preparation for those changes, move the next_bridge lookup from probe to
attach, when it is actually used. This allows dw-hdmi to probe, so that the
hdmi-connector can probe as well.
Also avoid storing the pointer in hdmi->bridge.next_bridge: the value is
computed when needed, thus a local variable is enough.
Finally, this also allows to slightly improve the code by not doing any DT
lookup in the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- Fix returned error codes
- Added missing cleanup.h include
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +++++++++++--------------------
1 file changed, 16 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ab1a6a8783cd..f4a1ebb79716 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -6,6 +6,8 @@
* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
* Copyright (C) 2010, Guennadi Liakhovetski <g.liakhovetski@gmx.de>
*/
+
+#include <linux/cleanup.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/err.h>
@@ -2914,9 +2916,20 @@ static int dw_hdmi_bridge_attach(struct drm_bridge *bridge,
if (WARN_ON((flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) && !hdmi->plat_data->output_port))
return -EINVAL;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
- return drm_bridge_attach(encoder, hdmi->bridge.next_bridge,
- bridge, flags);
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+ struct device_node *remote __free(device_node) =
+ of_graph_get_remote_node(hdmi->dev->of_node,
+ hdmi->plat_data->output_port, -1);
+ if (!remote)
+ return -ENODEV;
+
+ struct drm_bridge *next_bridge __free(drm_bridge_put) =
+ of_drm_find_and_get_bridge(remote);
+ if (!next_bridge)
+ return -EPROBE_DEFER;
+
+ return drm_bridge_attach(encoder, next_bridge, bridge, flags);
+ }
return dw_hdmi_connector_create(hdmi);
}
@@ -3307,28 +3320,6 @@ static void dw_hdmi_init_hw(struct dw_hdmi *hdmi)
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
-static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
-{
- struct device_node *remote;
-
- if (!hdmi->plat_data->output_port)
- return 0;
-
-
- remote = of_graph_get_remote_node(hdmi->dev->of_node,
- hdmi->plat_data->output_port,
- -1);
- if (!remote)
- return -ENODEV;
-
- hdmi->bridge.next_bridge = of_drm_find_and_get_bridge(remote);
- of_node_put(remote);
- if (!hdmi->bridge.next_bridge)
- return -EPROBE_DEFER;
-
- return 0;
-}
-
bool dw_hdmi_bus_fmt_is_420(struct dw_hdmi *hdmi)
{
return hdmi_bus_fmt_is_yuv420(hdmi->hdmi_data.enc_out_bus_format);
@@ -3373,10 +3364,6 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
mutex_init(&hdmi->cec_notifier_mutex);
spin_lock_init(&hdmi->audio_lock);
- ret = dw_hdmi_parse_dt(hdmi);
- if (ret < 0)
- return ERR_PTR(ret);
-
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
--
2.53.0
^ permalink raw reply related
* [PATCH v2 06/10] drm/bridge: dw-hdmi: warn on unsupported attach combination
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com>
dw-hdmi can operate in two different modes, depending on the platform data
as set by the driver:
A. hdmi->plat_data->output_port = 0:
the HDMI output (port@1) in device tree is not used
B. hdmi->plat_data->output_port = 1:
the HDMI output (port@1) is parsed to find the next bridge
Only case B is supported when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is
passed to the attach callback. Emit a warning when this is violated. Also
return -EINVAL which would be returned by drm_bridge_attach() right after
anyway.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Note: Returning when the warning triggers does not change the functional
behaviour of this function. It is not strictly necessary in this patch but
it will have to be done anyway in the following patch.
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 0296e110ce65..ab1a6a8783cd 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2910,6 +2910,10 @@ static int dw_hdmi_bridge_attach(struct drm_bridge *bridge,
{
struct dw_hdmi *hdmi = bridge->driver_private;
+ /* DRM_BRIDGE_ATTACH_NO_CONNECTOR requires a remote-endpoint to the next bridge */
+ if (WARN_ON((flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) && !hdmi->plat_data->output_port))
+ return -EINVAL;
+
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
return drm_bridge_attach(encoder, hdmi->bridge.next_bridge,
bridge, flags);
--
2.53.0
^ permalink raw reply related
* [PATCH v2 05/10] drm/bridge: dw-hdmi: document the output_port field
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com>
The meaning of this flag may not be obvious at first sight.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- improved comment as suggested by Liu
---
include/drm/bridge/dw_hdmi.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 336f062e1f9d..8500dd4f99d8 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -126,6 +126,12 @@ struct dw_hdmi_phy_ops {
struct dw_hdmi_plat_data {
struct regmap *regm;
+ /*
+ * The HDMI output port number must be 1 if the port is described
+ * in the device tree. 0 if the device tree does not describe the
+ * next component (legacy mode, i.e. without
+ * DRM_BRIDGE_ATTACH_NO_CONNECTOR flag when attaching bridge).
+ */
unsigned int output_port;
unsigned long input_bus_encoding;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 04/10] drm/mxsfb/lcdif: lcdif_attach_bridge: move iteration-specific variables declaration inside loop
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com>
The bridge and ret variables are per-iteration variables, whose values
don't have to be carried to the next iteration or be used after the loop
end. Move their declaration inside the loop scope as a cleanup and to make
code clearer.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
This patch is new in v2
---
drivers/gpu/drm/mxsfb/lcdif_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index 1c76709c4d94..c8ba8f9b1da8 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -50,14 +50,14 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
{
struct device *dev = lcdif->drm->dev;
struct device_node *ep __free(device_node) = NULL;
- struct drm_bridge *bridge;
- int ret;
for_each_endpoint_of_node(dev->of_node, ep) {
struct device_node *remote __free(device_node) =
of_graph_get_remote_port_parent(ep);
struct of_endpoint of_ep;
+ struct drm_bridge *bridge;
struct drm_encoder *encoder;
+ int ret;
if (!of_device_is_available(remote))
continue;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 03/10] drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com>
lcdif_attach_bridge() uses dev_err_probe() in some error paths, dev_err() +
return in others. Use dev_err_probe() for all of them to make code
consistent, simpler and with bettere error reporting.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- rewrote after removal of previous patch removing loop
- not added review/test trailers as the code is a bit different
---
drivers/gpu/drm/mxsfb/lcdif_drv.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index 8da8a265c05c..1c76709c4d94 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -63,10 +63,8 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
continue;
ret = of_graph_parse_endpoint(ep, &of_ep);
- if (ret < 0) {
- dev_err(dev, "Failed to parse endpoint %pOF\n", ep);
- return ret;
- }
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to parse endpoint %pOF\n", ep);
bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, of_ep.id);
if (IS_ERR(bridge))
@@ -75,20 +73,18 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
of_ep.id);
encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);
- if (!encoder) {
- dev_err(dev, "Failed to allocate encoder for endpoint%u\n",
- of_ep.id);
- return -ENOMEM;
- }
+ if (!encoder)
+ return dev_err_probe(dev, -ENOMEM,
+ "Failed to allocate encoder for endpoint%u\n",
+ of_ep.id);
encoder->possible_crtcs = drm_crtc_mask(&lcdif->crtc);
ret = drm_encoder_init(lcdif->drm, encoder, &lcdif_encoder_funcs,
DRM_MODE_ENCODER_NONE, NULL);
- if (ret) {
- dev_err(dev, "Failed to initialize encoder for endpoint%u: %d\n",
- of_ep.id, ret);
- return ret;
- }
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to initialize encoder for endpoint%u\n",
+ of_ep.id);
ret = drm_bridge_attach(encoder, bridge, NULL, 0);
if (ret)
--
2.53.0
^ permalink raw reply related
* [PATCH v2 02/10] drm/mxsfb/lcdif: simplify ep pointer management using __free
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com>
Putting the ep device_node reference requires a of_node_put(ep) in many
return points. Use a cleanup action to simplify the code.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
This patch is new in v2
---
drivers/gpu/drm/mxsfb/lcdif_drv.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index 7719629487da..8da8a265c05c 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -49,7 +49,7 @@ static const struct drm_encoder_funcs lcdif_encoder_funcs = {
static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
{
struct device *dev = lcdif->drm->dev;
- struct device_node *ep;
+ struct device_node *ep __free(device_node) = NULL;
struct drm_bridge *bridge;
int ret;
@@ -65,23 +65,19 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
ret = of_graph_parse_endpoint(ep, &of_ep);
if (ret < 0) {
dev_err(dev, "Failed to parse endpoint %pOF\n", ep);
- of_node_put(ep);
return ret;
}
bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, of_ep.id);
- if (IS_ERR(bridge)) {
- of_node_put(ep);
+ if (IS_ERR(bridge))
return dev_err_probe(dev, PTR_ERR(bridge),
"Failed to get bridge for endpoint%u\n",
of_ep.id);
- }
encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);
if (!encoder) {
dev_err(dev, "Failed to allocate encoder for endpoint%u\n",
of_ep.id);
- of_node_put(ep);
return -ENOMEM;
}
@@ -91,17 +87,14 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
if (ret) {
dev_err(dev, "Failed to initialize encoder for endpoint%u: %d\n",
of_ep.id, ret);
- of_node_put(ep);
return ret;
}
ret = drm_bridge_attach(encoder, bridge, NULL, 0);
- if (ret) {
- of_node_put(ep);
+ if (ret)
return dev_err_probe(dev, ret,
"Failed to attach bridge for endpoint%u\n",
of_ep.id);
- }
}
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 01/10] drm/mxsfb/lcdif: simplify remote pointer management using __free
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com>
Putting the remote device_node reference requires a of_node_put(remote) in
two places. Use a cleanup action to simplify the code.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- Use the correct cleanup action
- Fix commit message
- add missing cleanup.h include
---
drivers/gpu/drm/mxsfb/lcdif_drv.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index 47da1d9336b9..7719629487da 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -5,6 +5,7 @@
* This code is based on drivers/gpu/drm/mxsfb/mxsfb*
*/
+#include <linux/cleanup.h>
#include <linux/clk.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
@@ -53,16 +54,13 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
int ret;
for_each_endpoint_of_node(dev->of_node, ep) {
- struct device_node *remote;
+ struct device_node *remote __free(device_node) =
+ of_graph_get_remote_port_parent(ep);
struct of_endpoint of_ep;
struct drm_encoder *encoder;
- remote = of_graph_get_remote_port_parent(ep);
- if (!of_device_is_available(remote)) {
- of_node_put(remote);
+ if (!of_device_is_available(remote))
continue;
- }
- of_node_put(remote);
ret = of_graph_parse_endpoint(ep, &of_ep);
if (ret < 0) {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 00/10] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Luca Ceresoli @ 2026-03-30 19:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
This series modernizes the i.mx8mp LCDIF driver to use the
bridge-connector, which is the current best practice in DRM.
== Call for testing on i.MX8MP boards (especially those using HDMI)!
For who tested v1 (thanks!): some patches have changed so I had to drop
your Tested-by on them. A new round of test would still be useful.
This series applies changes to how video output devices are probed on
i.MX8MP, especially those using HDMI. Even though I have put care in not
breaking anything, there could potentially be pitfalls I haven't realized,
causing regressions on existing boards.
I have thus added in Cc all developers which appeared active on dts files
for imx8mp boards involving video. I would appreciate testing on as many
boards as possible, along with a Tested-by tag, or a report about any
issues encountered.
Thanks in advance to all testers!
== Review recommendation
I recommend reviewing patches in this order to be understood more
effectively:
* Cover letter
* Patches 1-6: small preliminary cleanups (can be applied independently)
* Patch 10: the goal of this series, but would not work alone
* Patch 9: lets patch 10 work; but in turn it can't work alone
* Patch 8: lets patch 9 work; but in turn it can't work alone
* Patch 7: lets patch 8 work
== Series description
This series is not strictly related to DRM bridge hotplug, it is rather a
preparation step. Introducing hotplug would need two different approaches:
one for the new way, for drivers using bridge-connector and
DRM_BRIDGE_ATTACH_NO_CONNECTOR, another for drivers using the "old, legacy
way" where the last bridge is supposed to instantiate the
drm_connector. Hotplug is complicated enough in one case, so it makes sense
to only support the new way.
The hardware I'm working on is an i.MX8MP, whose LCDIF driver is still
using the old way. So this series converts to the new way as a preparation
step.
Patch 10 does the conversion, which is simple. However this would introduce
a regression on some boards. Here's why:
There are 3 instances of the LCDIF in i.MX8MP:
* LCDIF1, driving the DSI output
* LCDIF2, driving the LVDS output
* LCDIF3, driving the HDMI output
The device drivers of peripherals connected to LCDIF1 and LCDIF2 already
support the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. So far so good.
LCDIF3 is more tricky. The HDMI pipeline is:
LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector
The fsl,imx8mp-hdmi-tx (hdmi-tx) does not support
DRM_BRIDGE_ATTACH_NO_CONNECTOR, but it is based on the dw-hdmi component
which supports it by simply changing a setting in the driver platform
data. Patch 9 does this switch.
However, for that switch to work, the device tree must describe the HDMI
connector (compatible = "hdmi-connector").
Unfortunately not all device trees in mainline have an hdmi-connector
node. Adding one is easy, but would break existing hardware upgrading to a
newer kernel without upgrading the device tree blob. This is addressed by
patch 8 reusing an existing approach to add such a node to the live device
tree at init time using a device tree overlay for boards which don't have
one.
Finally, patch 8 cannot work alone because of a bad interaction between
devlink and device tree overlays. Patch 7 solves that.
== Grand plan
This is part of the work to support hotplug of DRM bridges. The grand plan
was discussed in [0].
Here's the work breakdown (➜ marks the current series):
1. … add refcounting to DRM bridges struct drm_bridge,
based on devm_drm_bridge_alloc()
A. ✔ add new alloc API and refcounting (v6.16)
B. ✔ convert all bridge drivers to new API (v6.17)
C. ✔ kunit tests (v6.17)
D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
and warn on old allocation pattern (v6.17)
E. … add get/put on drm_bridge accessors
1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
2. ✔ drm_bridge_get_prev_bridge() (v6.18)
3. ✔ drm_bridge_get_next_bridge() (v6.19)
4. ✔ drm_for_each_bridge_in_chain() (v6.19)
5. ✔ drm_bridge_connector_init (v6.19)
6. … protect encoder bridge chain with a mutex
7. … of_drm_find_bridge
a. ✔ add of_drm_get_bridge() (v7.0),
convert basic direct users (v7.0-v7.1)
b. ✔ convert direct of_drm_get_bridge() users, part 2 (v7.0)
c. ✔ convert direct of_drm_get_bridge() users, part 3 (v7.0)
d. ✔… convert direct of_drm_get_bridge() users, part 4
(some v7.1, some pending)
e. convert bridge-only drm_of_find_panel_or_bridge() users
8. drm_of_find_panel_or_bridge, *_of_get_bridge
9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
F. ✔ debugfs improvements
1. ✔ add top-level 'bridges' file (v6.16)
2. ✔ show refcount and list lingering bridges (v6.19)
2. … handle gracefully atomic updates during bridge removal
A. ✔ Add drm_bridge_enter/exit() to protect device resources (v7.0)
B. … protect private_obj removal from list
C. ✔ Add drm_bridge_clear_and_put() (v7.1)
3. … DSI host-device driver interaction
4. ✔ removing the need for the "always-disconnected" connector
5. ➜ Migrate i.MX LCDIF driver to bridge-connector
6. DRM bridge hotplug
A. Bridge hotplug management in the DRM core
B. Device tree description
[0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- Dropped patch removing the loop in lcdif_attach_bridge, adapted following
patches as needed, added patch to use __free on the ep pointer
- Added new cleanup patch (patch 6)
- Build the fixup module unconditionally
- patch 7: fix returned error codes
- patch 1: fix cleanup action
- Various minor improvements based on reviews, see per-patch changelog
- Removed bouncing recipients from Cc
- Link to v1: https://lore.kernel.org/r/20260320-drm-lcdif-dbanc-v1-0-479a04133e70@bootlin.com
---
Luca Ceresoli (10):
drm/mxsfb/lcdif: simplify remote pointer management using __free
drm/mxsfb/lcdif: simplify ep pointer management using __free
drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
drm/mxsfb/lcdif: lcdif_attach_bridge: move iteration-specific variables declaration inside loop
drm/bridge: dw-hdmi: document the output_port field
drm/bridge: dw-hdmi: warn on unsupported attach combination
drm/bridge: dw-hdmi: move next_bridge lookup to attach time
drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
drm/bridge: imx8mp-hdmi-tx: switch to DRM_BRIDGE_ATTACH_NO_CONNECTOR
drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
drivers/gpu/drm/bridge/imx/Kconfig | 18 ++++++
drivers/gpu/drm/bridge/imx/Makefile | 2 +
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 53 +++++++++++++++++
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 56 ++++++++++++++++++
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 49 +++++++--------
drivers/gpu/drm/mxsfb/Kconfig | 2 +
drivers/gpu/drm/mxsfb/lcdif_drv.c | 69 +++++++++++-----------
include/drm/bridge/dw_hdmi.h | 6 ++
9 files changed, 193 insertions(+), 63 deletions(-)
---
base-commit: cb6fd48ab016a4b2245d805a5b766eea590e32dd
change-id: 20260306-drm-lcdif-dbanc-83dd948327de
Best regards,
--
Luca Ceresoli <luca.ceresoli@bootlin.com>
^ permalink raw reply
* Re: [PATCH v5 2/4] ACPI: of: match PRP0001 in of_match_device
From: Markus Probst @ 2026-03-30 19:24 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Hans de Goede, Ilpo Järvinen,
Bryan O'Donoghue, Lee Jones, Pavel Machek,
Krzysztof Kozlowski, Conor Dooley, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan,
platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi
In-Reply-To: <20260330192207.GA3097402-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]
On Mon, 2026-03-30 at 14:22 -0500, Rob Herring wrote:
> On Mon, Mar 30, 2026 at 07:04:21PM +0000, Markus Probst wrote:
> > On Mon, 2026-03-30 at 09:00 +0200, Krzysztof Kozlowski wrote:
> > > On Sun, Mar 29, 2026 at 08:02:16PM +0200, Markus Probst wrote:
> > > > Export `acpi_of_match_device` function and use it to match for PRP0001
> > > > in `of_match_device`, if the device does not have a device node.
> > > >
> > > > This fixes the match data being NULL when using ACPI PRP0001, even though
> > > > the device was matched against an of device table.
> > >
> > > Fixes tag?
> > >
> > > I don't see how this is going to fix !ACPI case - the
> > > acpi_of_match_device() will just return false.
> > While trying to argue I found out that there already is
> > `device_get_match_data`, which takes PRP0001 into account.
> >
> > I will now instead make a patch, which will make rust use this function
> > instead of calling `of_match_device` and `acpi_match_device`
> > individually, which ignores PRP0001.
>
> IIRC, the rust binding already gives you the data pointer in probe.
Yes, but that pointer is obtained by calling `acpi_match_device` and
`of_match_device` [1].
Thanks
- Markus Probst
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/driver.rs?id=7aaa8047eafd0bd628065b15757d9b48c5f9c07d
>
> > There are still a lot of drivers only using `of_match_device`, which
> > makes it impossible to use PRP0001 with them. But this is not relevant
> > for this driver.
>
> Usually using of_match_device() in drivers is wrong. You generally just
> want the data pointer. There's a whole bunch of drivers still doing the
> old way.
>
> Rob
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/4] ACPI: of: match PRP0001 in of_match_device
From: Rob Herring @ 2026-03-30 19:22 UTC (permalink / raw)
To: Markus Probst
Cc: Krzysztof Kozlowski, Hans de Goede, Ilpo Järvinen,
Bryan O'Donoghue, Lee Jones, Pavel Machek,
Krzysztof Kozlowski, Conor Dooley, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan,
platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi
In-Reply-To: <e4b194028dcf25b943438615a83bce68b0949e5f.camel@posteo.de>
On Mon, Mar 30, 2026 at 07:04:21PM +0000, Markus Probst wrote:
> On Mon, 2026-03-30 at 09:00 +0200, Krzysztof Kozlowski wrote:
> > On Sun, Mar 29, 2026 at 08:02:16PM +0200, Markus Probst wrote:
> > > Export `acpi_of_match_device` function and use it to match for PRP0001
> > > in `of_match_device`, if the device does not have a device node.
> > >
> > > This fixes the match data being NULL when using ACPI PRP0001, even though
> > > the device was matched against an of device table.
> >
> > Fixes tag?
> >
> > I don't see how this is going to fix !ACPI case - the
> > acpi_of_match_device() will just return false.
> While trying to argue I found out that there already is
> `device_get_match_data`, which takes PRP0001 into account.
>
> I will now instead make a patch, which will make rust use this function
> instead of calling `of_match_device` and `acpi_match_device`
> individually, which ignores PRP0001.
IIRC, the rust binding already gives you the data pointer in probe.
> There are still a lot of drivers only using `of_match_device`, which
> makes it impossible to use PRP0001 with them. But this is not relevant
> for this driver.
Usually using of_match_device() in drivers is wrong. You generally just
want the data pointer. There's a whole bunch of drivers still doing the
old way.
Rob
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: sound: Convert pcm3060 to DT Schema
From: Padmashree S S @ 2026-03-30 19:10 UTC (permalink / raw)
To: Kirill Marinushkin
Cc: broonie, robh, krzk+dt, conor+dt, linux-sound, devicetree,
linux-kernel, lgirdwood, Daniel Baluta
In-Reply-To: <b8ca83e9-5a48-032a-96bc-a62990cb61f6@gmail.com>
On Mon, Mar 30, 2026 at 11:19 AM Kirill Marinushkin
<k.marinushkin@gmail.com> wrote:
>
> Hello Padmashree,
>
>
> overall, your proposed changes look good to me, thank you for taking care of
>
> the DT schema for the pcm3060 driver!
>
> I left a few minor comments below, but i am open for a discussion, if
> you think
>
> they are not relevant
>
>
> On 3/27/26 1:19 PM, Padmashree S S wrote:
> > Convert pcm3060 to DT Schema
> >
> > Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> > ---
> > .../devicetree/bindings/sound/pcm3060.txt | 23 ----------
> > .../devicetree/bindings/sound/pcm3060.yaml | 42 +++++++++++++++++++
> > 2 files changed, 42 insertions(+), 23 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
> > create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/sound/pcm3060.txt b/Documentation/devicetree/bindings/sound/pcm3060.txt
> > deleted file mode 100644
> > index 97de66932d44..000000000000
> > --- a/Documentation/devicetree/bindings/sound/pcm3060.txt
> > +++ /dev/null
> > @@ -1,23 +0,0 @@
> > -PCM3060 audio CODEC
> > -
> > -This driver supports both I2C and SPI.
> > -
> > -Required properties:
> > -
> > -- compatible: "ti,pcm3060"
> > -
> > -- reg : the I2C address of the device for I2C, the chip select
> > - number for SPI.
> > -
> > -Optional properties:
> > -
> > -- ti,out-single-ended: "true" if output is single-ended;
> > - "false" or not specified if output is differential.
> > -
> > -Examples:
> > -
> > - pcm3060: pcm3060@46 {
> > - compatible = "ti,pcm3060";
> > - reg = <0x46>;
> > - ti,out-single-ended = "true";
> > - };
> > diff --git a/Documentation/devicetree/bindings/sound/pcm3060.yaml b/Documentation/devicetree/bindings/sound/pcm3060.yaml
> > new file mode 100644
> > index 000000000000..2d920a70bced
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/pcm3060.yaml
> > @@ -0,0 +1,42 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/sound/pcm3060.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: PCM3060 audio CODEC
>
>
> Here, we seem to drop a short description, that this driver supports
>
> I2C and SPI. It's maybe not a big deal, but maybe we could return these
> details,
>
> as a `description` property? Let me know what you think
>
>
> > +
> > +maintainers:
> > + - Kirill Marinushkin <k.marinushkin@gmail.com>
> > +
> > +properties:
> > + compatible:
> > + const: ti,pcm3060
> > +
> > + reg:
> > + maxItems: 1
>
>
> Here, i notice, that we remove the description of the `reg` property.
>
> It was there originally, and in the 1st version of your patch, but not
> in v3.
>
> The description here seems important to me - being a documentation, this
>
> yaml could be more helpful, when it describes the meaning of the properties.
>
> Do you think it would be possible to bring the description back?
>
>
> > +
> > + ti,out-single-ended:
> > + type: boolean
> > + description: |
> > + If present, the output is single-ended.
> > + If absent, the output is differential.
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + pcm3060: audio-codec@46 {
> > + compatible = "ti,pcm3060";
> > + reg = <0x46>;
> > + ti,out-single-ended;
> > + };
> > + };
>
>
> Best regards,
>
> Kirill
>
>Thank you for the feedback, I will bring back the descriptions in the next version of this patch.
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: sound: Convert pcm3060 to DT Schema
From: Padmashree S S @ 2026-03-30 19:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: k.marinushkin, lgirdwood, broonie, robh, krzk+dt, conor+dt,
linux-sound, devicetree, linux-kernel
In-Reply-To: <CAEjBr-aoOhbtZWdYvq3rQ3q+2SKUEctTXPdYcoS4mJyrPf-Yqw@mail.gmail.com>
On Tue, Mar 31, 2026 at 12:28 AM Padmashree S S
<padmashreess2006@gmail.com> wrote:
>
>
>
> On Sat, Mar 28, 2026 at 7:20 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Fri, Mar 27, 2026 at 05:49:18PM +0530, Padmashree S S wrote:
>> > Convert pcm3060 to DT Schema
>> >
>> > Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
>> > ---
>> > .../devicetree/bindings/sound/pcm3060.txt | 23 ----------
>> > .../devicetree/bindings/sound/pcm3060.yaml | 42 +++++++++++++++++++
>>
>> You sent it already after I asked you to slow down and implement
>> previous feedback, so this has the same issues.
>>
>> Please run scripts/checkpatch.pl on the patches and fix reported
>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>> patches and (probably) fix more warnings. Some warnings can be ignored,
>> especially from --strict run, but the code here looks like it needs a
>> fix. Feel free to get in touch if the warning is not clear.
>>
>> Please use subject prefixes matching the subsystem. You can get them for
>> example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
>> your patch is touching. For bindings, the preferred subjects are
>> explained here:
>> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
>>
>> > 2 files changed, 42 insertions(+), 23 deletions(-)
>> > delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
>> > create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
>>
>> Filename must match compatible.
>>
>> ...
>>
>> > +
>> > + reg:
>> > + maxItems: 1
>> > +
>> > + ti,out-single-ended:
>> > + type: boolean
>> > + description: |
>>
>> Drop |
>>
>> > + If present, the output is single-ended.
>> > + If absent, the output is differential.
>> > +
>> > +required:
>> > + - compatible
>> > + - reg
>> > +
>> > +additionalProperties: false
>> > +
>> > +examples:
>> > + - |
>> > + i2c {
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > +
>> > + pcm3060: audio-codec@46 {
>>
>> Drop unused label.
>>
>> Best regards,
>> Krzysztof
>> Thanks for the review.
>> I will run checkpatch.pl, address the comments and send an updated version.
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Loic Poulain @ 2026-03-30 19:07 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: johannes.goede, Dmitry Baryshkov, vladimir.zapolskiy,
laurent.pinchart, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <e2a4e9dd-6a45-48dc-8757-244e201dd4d6@kernel.org>
On Mon, Mar 30, 2026 at 4:33 PM Bryan O'Donoghue <bod@kernel.org> wrote:
>
> On 30/03/2026 15:27, johannes.goede@oss.qualcomm.com wrote:
> >> That's another reason I bring up CDM again and again. We probably don't want to fix to the wrong format for OPE, introduce the CDM and then find we have to map from one format to another for large and complex data over and over again for each frame or every N frames.
> > CDM is a much lower-level API then what is expected from
> > a media-controller centric V4L2 driver. Basically the OPE
> > driver will export:
>
> My concern is about wrappering one thing inside of another thing and
> then stuffing it again back into CDM and doing the same on the way out.
I think there will always be some level of copying involved. That
said, we can pre‑build the CDM sequence in the drivers and only update
the variable values, which should avoid significant overhead.
If we start handling CDM formats directly on the user side, it would
require exposing a lot of low‑level knowledge there (such as register
layouts and offsets), and that would diverge from how other ISP
implementations are structured. I’m concerned this would increase
complexity and reduce portability.
> There are already 50 MMIO writes in the OPE ISR, I don't believe it is
> sustainable to keep adding MMIO into that.
Yes, I understand the concern. From our testing so far, however, this
has not shown to be an issue. In addition, a full reconfiguration
would only happen in specific cases, such as on explicit full
configuration changes or during context switching. We can certainly
look at implementing CDM, but at this stage it didn't seem to bring
significant benefits, so I prefered to focus on other functional
aspects, and revisit CDM once there is a clearer need, measurable
gain, or if it becomes part of the uAPI as discussed here.
> I'm aware of a project in qcom that did something with making the CDM
> format in libcamera and handed that off to kernel, recommend looking
> into that.
I will, thanks, I'm however, concerned about how acceptable this
approach would be to the wider community and to the maintainers.
Regards,
Loic
^ permalink raw reply
* Re: [PATCH v4 net-next 5/5] net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"
From: Vladimir Oltean @ 2026-03-30 19:04 UTC (permalink / raw)
To: Frank Wunderlich
Cc: netdev, devicetree, linux-kernel, linux-mediatek, Daniel Golle,
Horatiu Vultur, Bj√∏rn Mork, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Eric Woudstra, Alexander Couzens, Chester A. Unal, DENG Qingfang,
Sean Wang, Felix Fietkau
In-Reply-To: <d9639ac711ff8f1186a684fa120ba77247669051@linux.dev>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
Hi Frank,
On Mon, Mar 30, 2026 at 05:52:17PM +0000, Frank Wunderlich wrote:
> Hi Vladimir
>
> Thanks for the patch and sorry for my delay...i was away this weekend so i was not able to test.
>
> traffic works again (but there is only read now) and this is the result of your debug prints:
>
> root@bpi-r3:~# dmesg | grep SGMSYS_QPHY_WRAP_CTRL
> [ 2.706963] SGMSYS_QPHY_WRAP_CTRL = 0x501, intending to write 0x500
> [ 9.134081] SGMSYS_QPHY_WRAP_CTRL = 0x500, intending to write 0x500
>
> R3/mt7986 has 2 MAC, and switch is on the first, so value will change, not sure why this is different.
>
> i have not found SGMSYS_QPHY_WRAP_CTRL or something related with polarity in ethernet/mac-
> (drivers/net/ethernet/mediatek/mtk_eth_soc.c) or switch-driver (drivers/net/dsa/mt7530{,-mdio}.c)
> in case they manipulate this register too (of course they should not). Also looked into the pcs-handling
> in both drivers, but see nothing related to polarity. And looked for possible duplicate register const
> definition (other name for 0xec).
This result means that your default QPHY_WRAP_CTRL register value has
the SGMII_PN_SWAP_TX bit set. Whether that comes from U-Boot or hardware
default or otherwise, it doesn't really matter. Curious that the
SGMII_SW_RESET doesn't clear TX inversion, though. I guess you wouldn't
have documentation that would suggest this setting is sticky?
In Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml,
it is not specified what happens when the "mediatek,pnswap" property is
missing. I thought the most logical thing would be for the lane
polarities to not be swapped - because how would you describe normal
lane polarities otherwise? My bad for thinking the original vendor
bindings were more sane than they were.
The only way to describe the polarities that this SGMSYS block needs on
a particular board is to use the newly introduced 'rx-polarity =
<PHY_POL_NORMAL>' and 'tx-polarity = <PHY_POL_INVERT>'. Which I strongly
recommend you to do, even if the attached patch should restore
functionality with your current device tree.
[-- Attachment #2: 0001-net-pcs-pcs-mtk-lynxi-preserve-lane-polarities-when-.patch --]
[-- Type: text/x-diff, Size: 3080 bytes --]
From 6b5fe06ec16e8a1e752fc871c135d2f12a37ce33 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Thu, 26 Mar 2026 23:46:46 +0200
Subject: [PATCH] net: pcs: pcs-mtk-lynxi: preserve lane polarities when not
described in fwnode
Frank Wunderlich reports that the BPI-R3 board has a default
SGMSYS_QPHY_WRAP_CTRL = 0x501, aka TX inverted and RX not inverted.
At the same time, neither rx-polarity/tx-polarity nor mediatek,pnswap
are present in the device tree.
The original driver logic was to enable both TX inversion and RX
inversion when finding mediatek,pnswap in the device tree, and leave
SGMSYS_QPHY_WRAP_CTRL to its default value otherwise.
The blamed commit has broken that by assuming that a missing
mediatek,pnswap would mean non-inverting polarity.
Restore the original behaviour by reading the SGMSYS_QPHY_WRAP_CTRL
value and using it as a default polarity if mediatek,pnswap and the new
rx-polarity/tx-polarity are all unset.
Fixes: 8871389da151 ("net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"")
Reported-by: Frank Wunderlich <frank.wunderlich@linux.dev>
Closes: https://lore.kernel.org/netdev/e0ad52862d34cf4e0169c9850a7f164f127d0093@linux.dev/
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/pcs/pcs-mtk-lynxi.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/net/pcs/pcs-mtk-lynxi.c b/drivers/net/pcs/pcs-mtk-lynxi.c
index c12f8087af9b..7518c98fa98a 100644
--- a/drivers/net/pcs/pcs-mtk-lynxi.c
+++ b/drivers/net/pcs/pcs-mtk-lynxi.c
@@ -126,11 +126,24 @@ static int mtk_pcs_config_polarity(struct mtk_pcs_lynxi *mpcs,
{
struct fwnode_handle *fwnode = mpcs->fwnode, *pcs_fwnode;
unsigned int pol, default_pol = PHY_POL_NORMAL;
- unsigned int val = 0;
+ unsigned int val = 0, orig;
+ bool has_legacy_prop;
int ret;
- if (fwnode_property_read_bool(fwnode, "mediatek,pnswap"))
+ ret = regmap_read(mpcs->regmap, SGMSYS_QPHY_WRAP_CTRL, &orig);
+ if (ret)
+ return ret;
+
+ /* RX polarity:
+ * - if standard 'rx-polarity' exists in 'pcs' subnode, follow that
+ * - if 'mediatek,pnswap' is set, invert RX polarity
+ * - otherwise, leave unchanged
+ */
+ has_legacy_prop = fwnode_property_read_bool(fwnode, "mediatek,pnswap");
+ if (has_legacy_prop || FIELD_GET(SGMII_PN_SWAP_RX, orig))
default_pol = PHY_POL_INVERT;
+ else
+ default_pol = PHY_POL_NORMAL;
pcs_fwnode = fwnode_get_named_child_node(fwnode, "pcs");
@@ -144,6 +157,16 @@ static int mtk_pcs_config_polarity(struct mtk_pcs_lynxi *mpcs,
if (pol == PHY_POL_INVERT)
val |= SGMII_PN_SWAP_RX;
+ /* And TX polarity:
+ * - if standard 'tx-polarity' exists in 'pcs' subnode, follow that
+ * - if 'mediatek,pnswap' is set, invert TX polarity
+ * - otherwise, leave unchanged
+ */
+ if (has_legacy_prop || FIELD_GET(SGMII_PN_SWAP_TX, orig))
+ default_pol = PHY_POL_INVERT;
+ else
+ default_pol = PHY_POL_NORMAL;
+
ret = phy_get_tx_polarity(pcs_fwnode, phy_modes(interface),
BIT(PHY_POL_NORMAL) | BIT(PHY_POL_INVERT),
default_pol, &pol);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 2/4] ACPI: of: match PRP0001 in of_match_device
From: Markus Probst @ 2026-03-30 19:04 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan,
platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi
In-Reply-To: <20260330-bipedal-invaluable-slug-0c6dea@quoll>
[-- Attachment #1: Type: text/plain, Size: 3606 bytes --]
On Mon, 2026-03-30 at 09:00 +0200, Krzysztof Kozlowski wrote:
> On Sun, Mar 29, 2026 at 08:02:16PM +0200, Markus Probst wrote:
> > Export `acpi_of_match_device` function and use it to match for PRP0001
> > in `of_match_device`, if the device does not have a device node.
> >
> > This fixes the match data being NULL when using ACPI PRP0001, even though
> > the device was matched against an of device table.
>
> Fixes tag?
>
> I don't see how this is going to fix !ACPI case - the
> acpi_of_match_device() will just return false.
While trying to argue I found out that there already is
`device_get_match_data`, which takes PRP0001 into account.
I will now instead make a patch, which will make rust use this function
instead of calling `of_match_device` and `acpi_match_device`
individually, which ignores PRP0001.
There are still a lot of drivers only using `of_match_device`, which
makes it impossible to use PRP0001 with them. But this is not relevant
for this driver.
Thanks
- Markus Probst
>
>
> >
> > Signed-off-by: Markus Probst <markus.probst@posteo.de>
> > ---
> > drivers/acpi/bus.c | 7 ++++---
> > drivers/of/device.c | 9 +++++++--
> > include/linux/acpi.h | 11 +++++++++++
> > 3 files changed, 22 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > index 2ec095e2009e..cd02f04cf685 100644
> > --- a/drivers/acpi/bus.c
> > +++ b/drivers/acpi/bus.c
> > @@ -831,9 +831,9 @@ const struct acpi_device *acpi_companion_match(const struct device *dev)
> > * identifiers and a _DSD object with the "compatible" property, use that
> > * property to match against the given list of identifiers.
> > */
> > -static bool acpi_of_match_device(const struct acpi_device *adev,
> > - const struct of_device_id *of_match_table,
> > - const struct of_device_id **of_id)
> > +bool acpi_of_match_device(const struct acpi_device *adev,
> > + const struct of_device_id *of_match_table,
> > + const struct of_device_id **of_id)
> > {
> > const union acpi_object *of_compatible, *obj;
> > int i, nval;
> > @@ -866,6 +866,7 @@ static bool acpi_of_match_device(const struct acpi_device *adev,
> >
> > return false;
> > }
> > +EXPORT_SYMBOL_GPL(acpi_of_match_device);
> >
> > static bool acpi_of_modalias(struct acpi_device *adev,
> > char *modalias, size_t len)
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index f7e75e527667..128682390058 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -11,6 +11,7 @@
> > #include <linux/mod_devicetable.h>
> > #include <linux/slab.h>
> > #include <linux/platform_device.h>
> > +#include <linux/acpi.h>
> >
> > #include <asm/errno.h>
> > #include "of_private.h"
> > @@ -26,8 +27,12 @@
> > const struct of_device_id *of_match_device(const struct of_device_id *matches,
> > const struct device *dev)
> > {
> > - if (!matches || !dev->of_node || dev->of_node_reused)
> > - return NULL;
> > + if (!matches || !dev->of_node || dev->of_node_reused) {
> > + const struct of_device_id *id = NULL;
> > +
> > + acpi_of_match_device(ACPI_COMPANION(dev), matches, &id);
>
> I don't think this should be done from of_match_device. Yuo will have
> soon recursive calls, because acpi_of_match_device() will call other
> match, that will call of_match_device() and so on...
>
> of_match_device() is supposed to match only against OF. Not ACPI. There
> should be no ACPI header or code in this unit file.
>
> Best regards,
> Krzysztof
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v7 0/5] Add driver for EC found on Qualcomm reference devices
From: Dmitry Baryshkov @ 2026-03-30 19:03 UTC (permalink / raw)
To: Rob Clark
Cc: Anvesh Jain P, Akhil P Oommen, linux-arm-msm, devicetree,
linux-kernel, platform-driver-x86, Maya Matuszczyk,
Krzysztof Kozlowski, Konrad Dybcio, Abel Vesa, Gaurav Kohli,
Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Randy Dunlap
In-Reply-To: <CACSVV02B9FOqi8w1VfgZXtvUxqDmsSsHMVF21qAAZNxDFTDNfA@mail.gmail.com>
On Mon, Mar 30, 2026 at 07:08:45AM -0700, Rob Clark wrote:
> On Sun, Mar 29, 2026 at 11:57 PM Anvesh Jain P
> <anvesh.p@oss.qualcomm.com> wrote:
> >
> >
> >
> > On 3/29/2026 7:52 PM, Akhil P Oommen wrote:
> > > On 3/27/2026 3:38 PM, Anvesh Jain P wrote:
> > >> From: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
> > >>
> > >> Add Embedded controller driver support for Hamoa/Purwa/Glymur Qualcomm
> > >> reference boards. It handles fan control, temperature sensors, access
> > >> to EC state changes and supports reporting suspend entry/exit to the EC.
> > >
> > > Just a question, is it possible to force fan to run at full speed
> > > constantly? That would be helpful to keep the passive cooling minimal
> > > and get a more consistent results while doing performance profiling.
> > >
> > > I see that you are registering a cooling device in this series. So I
> > > suppose we just need to update the cooling sysfs nodes.
> > >
> > > -Akhil
> > >
> >
> > Hi Akhil,
> >
> > Yes, that is possible. The cooling device registered by this driver
> > exposes the standard thermal sysfs interface. You can force the fan
> > to full speed by writing the maximum cooling state directly:
> >
> > # Find the max state
> > cat /sys/class/thermal/cooling_deviceX/max_state
> >
> > # Set to max state (force full speed)
> > echo <max_state> > /sys/class/thermal/cooling_deviceX/cur_state
> >
> > Where X is the index of the cooling device corresponding to the EC fan.
>
> Getting a bit off topic, but is there a good way to associated cooling
> devices and thermal sensors to the GPU device? I could see that being
> useful for nvtop (which currently supports shows GPU load and memory
> metrics, but thermal metrics are missing for us)
I had a dirty patch, providing temp readings in NVMem. Probably I need
to clean it up and submit upstream.
>
> BR,
> -R
>
> > --
> > Best Regards,
> > Anvesh
> >
> >
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2 4/4] usb: dwc3: xilinx: Add support to program MMI USB TX deemphasis
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260330190304.1841593-1-radhey.shyam.pandey@amd.com>
Introduces support for programming the 18-bit TX Deemphasis value that
drives the pipe_TxDeemph signal, as defined in the PIPE4 specification.
The configured value is recommended by Synopsys and is intended for
standard (non-compliance) operation. These Gen2 equalization settings
have been validated through both internal and external compliance
testing. By applying this setting, the stability of USB 3.2 enumeration
is improved and now SuperSpeedPlus devices are consistently recognized as
USB 3.2 Gen 2 by the MMI USB Host controller.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- Don't use compatible check for deemphasis programming.
- Rename property "snps,lcsr_tx_deemph" to "snps,lcsr-tx-deemph"
(hyphens per kernel convention).
- Fix double space in LCSR_TX_DEEMPH register comment.
- Add blank line between register offset define and "Bit fields" section.
---
drivers/usb/dwc3/core.c | 17 +++++++++++++++++
drivers/usb/dwc3/core.h | 8 ++++++++
drivers/usb/dwc3/dwc3-xilinx.c | 15 ++++++++++++---
3 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 161a4d58b2ce..e678a53a90b3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -646,6 +646,15 @@ static void dwc3_config_soc_bus(struct dwc3 *dwc)
reg |= DWC3_GSBUSCFG0_REQINFO(dwc->gsbuscfg0_reqinfo);
dwc3_writel(dwc, DWC3_GSBUSCFG0, reg);
}
+
+ if (dwc->csr_tx_deemph_field_1 != DWC3_LCSR_TX_DEEMPH_UNSPECIFIED) {
+ u32 reg;
+
+ reg = dwc3_readl(dwc, DWC3_LCSR_TX_DEEMPH);
+ reg &= ~DWC3_LCSR_TX_DEEMPH_MASK(~0);
+ reg |= DWC3_LCSR_TX_DEEMPH_MASK(dwc->csr_tx_deemph_field_1);
+ dwc3_writel(dwc, DWC3_LCSR_TX_DEEMPH, reg);
+ }
}
static int dwc3_core_ulpi_init(struct dwc3 *dwc)
@@ -1671,11 +1680,13 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
static void dwc3_get_software_properties(struct dwc3 *dwc,
const struct dwc3_properties *properties)
{
+ u32 csr_tx_deemph_field_1;
struct device *tmpdev;
u16 gsbuscfg0_reqinfo;
int ret;
dwc->gsbuscfg0_reqinfo = DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED;
+ dwc->csr_tx_deemph_field_1 = DWC3_LCSR_TX_DEEMPH_UNSPECIFIED;
if (properties->gsbuscfg0_reqinfo !=
DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED) {
@@ -1693,6 +1704,12 @@ static void dwc3_get_software_properties(struct dwc3 *dwc,
&gsbuscfg0_reqinfo);
if (!ret)
dwc->gsbuscfg0_reqinfo = gsbuscfg0_reqinfo;
+
+ ret = device_property_read_u32(tmpdev,
+ "snps,lcsr-tx-deemph",
+ &csr_tx_deemph_field_1);
+ if (!ret)
+ dwc->csr_tx_deemph_field_1 = csr_tx_deemph_field_1;
}
}
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index a35b3db1f9f3..99874ad09730 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -181,6 +181,8 @@
#define DWC3_LLUCTL(n) (0xd024 + ((n) * 0x80))
+#define DWC3_LCSR_TX_DEEMPH 0xd060
+
/* Bit fields */
/* Global SoC Bus Configuration INCRx Register 0 */
@@ -198,6 +200,10 @@
#define DWC3_GSBUSCFG0_REQINFO(n) (((n) & 0xffff) << 16)
#define DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED 0xffffffff
+/* LCSR_TX_DEEMPH Register: setting TX deemphasis used in normal operation in gen2 */
+#define DWC3_LCSR_TX_DEEMPH_MASK(n) ((n) & 0x3ffff)
+#define DWC3_LCSR_TX_DEEMPH_UNSPECIFIED 0xffffffff
+
/* Global Debug LSP MUX Select */
#define DWC3_GDBGLSPMUX_ENDBC BIT(15) /* Host only */
#define DWC3_GDBGLSPMUX_HOSTSELECT(n) ((n) & 0x3fff)
@@ -1180,6 +1186,7 @@ struct dwc3_glue_ops {
* @wakeup_pending_funcs: Indicates whether any interface has requested for
* function wakeup in bitmap format where bit position
* represents interface_id.
+ * @csr_tx_deemph_field_1: stores TX deemphasis used in Gen2 operation.
*/
struct dwc3 {
struct work_struct drd_work;
@@ -1417,6 +1424,7 @@ struct dwc3 {
struct dentry *debug_root;
u32 gsbuscfg0_reqinfo;
u32 wakeup_pending_funcs;
+ u32 csr_tx_deemph_field_1;
};
#define INCRX_BURST_MODE 0
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index f2dee28bdc65..44008856ee73 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -41,11 +41,13 @@
#define PIPE_CLK_SELECT 0
#define XLNX_USB_FPD_POWER_PRSNT 0x80
#define FPD_POWER_PRSNT_OPTION BIT(0)
+#define XLNX_MMI_USB_TX_DEEMPH_DEF 0x8c45
struct dwc3_xlnx;
struct dwc3_xlnx_config {
int (*pltfm_init)(struct dwc3_xlnx *data);
+ u32 tx_deemph;
bool map_resource;
};
@@ -284,6 +286,7 @@ static const struct dwc3_xlnx_config versal_config = {
static const struct dwc3_xlnx_config versal2_config = {
.pltfm_init = dwc3_xlnx_init_versal2,
+ .tx_deemph = XLNX_MMI_USB_TX_DEEMPH_DEF,
};
static const struct of_device_id dwc3_xlnx_of_match[] = {
@@ -303,10 +306,12 @@ static const struct of_device_id dwc3_xlnx_of_match[] = {
};
MODULE_DEVICE_TABLE(of, dwc3_xlnx_of_match);
-static int dwc3_set_swnode(struct device *dev)
+static int dwc3_set_swnode(struct dwc3_xlnx *priv_data)
{
+ struct device *dev = priv_data->dev;
+ const struct dwc3_xlnx_config *config = priv_data->dwc3_config;
struct device_node *np = dev->of_node, *dwc3_np;
- struct property_entry props[2];
+ struct property_entry props[3];
int prop_idx = 0, ret = 0;
dwc3_np = of_get_compatible_child(np, "snps,dwc3");
@@ -320,6 +325,10 @@ static int dwc3_set_swnode(struct device *dev)
if (of_dma_is_coherent(dwc3_np))
props[prop_idx++] = PROPERTY_ENTRY_U16("snps,gsbuscfg0-reqinfo",
0xffff);
+ if (config->tx_deemph)
+ props[prop_idx++] = PROPERTY_ENTRY_U32("snps,lcsr-tx-deemph",
+ config->tx_deemph);
+
of_node_put(dwc3_np);
if (prop_idx)
@@ -368,7 +377,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
if (ret)
goto err_clk_put;
- ret = dwc3_set_swnode(dev);
+ ret = dwc3_set_swnode(priv_data);
if (ret)
goto err_clk_put;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] usb: dwc3: xilinx: Add Versal2 MMI USB 3.2 controller support
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260330190304.1841593-1-radhey.shyam.pandey@amd.com>
Multi-media integrated (MMI) USB3.2 DRD IP is usb3.1 gen2 controller
which support following speed SSP (10-Gbps), SuperSpeed(5-Gbps),
high-speed(480-Mbps), full-speed(12-Mbps), and low-speed(1.5-Mbps)
operation modes.
USB2 and USB3 PHY support Physical connectivity via the Type-C
connectivity. The MMI USB controller does not have a dedicated wrapper
register space, so ioremap is skipped via the map_resource config flag.
The driver handles clock and reset initialization. In this initial
version typec reversibility is not implemented and it is assumed that
USB3 PHY TCA mux programming is done by MMI configuration data object
(CDOs) and TI PD controller is configured using external tiva programmer
on VEK385 evaluation board.
Tested host mode with mass storage device.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
- Introduce xlnx,usb-syscon phandle to access UDH address space
which is wrapper subsystem IP for USB, DP and HDCP.
- Split config struct refactoring into separate patch (2/4).
- Remove unused regmap/syscon fields and parsing code; defer to
patch that first consumes them.
- Fix error message capitalization to lowercase ("reset", "deassert").
---
drivers/usb/dwc3/dwc3-xilinx.c | 50 ++++++++++++++++++++++++++++++----
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index bb59b56726e7..f2dee28bdc65 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -46,6 +46,7 @@ struct dwc3_xlnx;
struct dwc3_xlnx_config {
int (*pltfm_init)(struct dwc3_xlnx *data);
+ bool map_resource;
};
struct dwc3_xlnx {
@@ -93,6 +94,29 @@ static void dwc3_xlnx_set_coherency(struct dwc3_xlnx *priv_data, u32 coherency_o
}
}
+static int dwc3_xlnx_init_versal2(struct dwc3_xlnx *priv_data)
+{
+ struct device *dev = priv_data->dev;
+ struct reset_control *crst;
+ int ret;
+
+ crst = devm_reset_control_get_optional_exclusive(dev, NULL);
+ if (IS_ERR(crst))
+ return dev_err_probe(dev, PTR_ERR(crst),
+ "failed to get reset signal\n");
+
+ /* assert and deassert reset */
+ ret = reset_control_assert(crst);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to assert reset\n");
+
+ ret = reset_control_deassert(crst);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to deassert reset\n");
+
+ return 0;
+}
+
static int dwc3_xlnx_init_versal(struct dwc3_xlnx *priv_data)
{
struct device *dev = priv_data->dev;
@@ -250,10 +274,16 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
static const struct dwc3_xlnx_config zynqmp_config = {
.pltfm_init = dwc3_xlnx_init_zynqmp,
+ .map_resource = true,
};
static const struct dwc3_xlnx_config versal_config = {
.pltfm_init = dwc3_xlnx_init_versal,
+ .map_resource = true,
+};
+
+static const struct dwc3_xlnx_config versal2_config = {
+ .pltfm_init = dwc3_xlnx_init_versal2,
};
static const struct of_device_id dwc3_xlnx_of_match[] = {
@@ -265,6 +295,10 @@ static const struct of_device_id dwc3_xlnx_of_match[] = {
.compatible = "xlnx,versal-dwc3",
.data = &versal_config,
},
+ {
+ .compatible = "xlnx,versal2-mmi-dwc3",
+ .data = &versal2_config,
+ },
{ /* Sentinel */ }
};
MODULE_DEVICE_TABLE(of, dwc3_xlnx_of_match);
@@ -299,19 +333,23 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
struct dwc3_xlnx *priv_data;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- void __iomem *regs;
int ret;
priv_data = devm_kzalloc(dev, sizeof(*priv_data), GFP_KERNEL);
if (!priv_data)
return -ENOMEM;
- regs = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(regs))
- return dev_err_probe(dev, PTR_ERR(regs), "failed to map registers\n");
-
priv_data->dwc3_config = device_get_match_data(dev);
- priv_data->regs = regs;
+
+ if (priv_data->dwc3_config->map_resource) {
+ void __iomem *regs;
+
+ regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(regs))
+ return dev_err_probe(dev, PTR_ERR(regs),
+ "failed to map registers\n");
+ priv_data->regs = regs;
+ }
priv_data->dev = dev;
platform_set_drvdata(pdev, priv_data);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] usb: dwc3: xilinx: Introduce dwc3_xlnx_config for per-platform data
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260330190304.1841593-1-radhey.shyam.pandey@amd.com>
Replace the direct pltfm_init function pointer in struct dwc3_xlnx with
a const pointer to a new struct dwc3_xlnx_config. This groups
per-platform configuration in one place and allows future patches to add
platform-specific fields (e.g. tx_deemph) without growing dwc3_xlnx.
While at it, switch from of_match_node() to device_get_match_data() to
simplify the match data lookup.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- New patch, split from "Add Versal2 MMI USB 3.2 controller support".
- Use device_get_match_data() instead of of_match_node().
---
drivers/usb/dwc3/dwc3-xilinx.c | 28 ++++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index f41b0da5e89d..bb59b56726e7 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -12,6 +12,7 @@
#include <linux/clk.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/dma-mapping.h>
#include <linux/gpio/consumer.h>
#include <linux/of_platform.h>
@@ -41,12 +42,18 @@
#define XLNX_USB_FPD_POWER_PRSNT 0x80
#define FPD_POWER_PRSNT_OPTION BIT(0)
+struct dwc3_xlnx;
+
+struct dwc3_xlnx_config {
+ int (*pltfm_init)(struct dwc3_xlnx *data);
+};
+
struct dwc3_xlnx {
int num_clocks;
struct clk_bulk_data *clks;
struct device *dev;
void __iomem *regs;
- int (*pltfm_init)(struct dwc3_xlnx *data);
+ const struct dwc3_xlnx_config *dwc3_config;
struct phy *usb3_phy;
};
@@ -241,14 +248,22 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
return ret;
}
+static const struct dwc3_xlnx_config zynqmp_config = {
+ .pltfm_init = dwc3_xlnx_init_zynqmp,
+};
+
+static const struct dwc3_xlnx_config versal_config = {
+ .pltfm_init = dwc3_xlnx_init_versal,
+};
+
static const struct of_device_id dwc3_xlnx_of_match[] = {
{
.compatible = "xlnx,zynqmp-dwc3",
- .data = &dwc3_xlnx_init_zynqmp,
+ .data = &zynqmp_config,
},
{
.compatible = "xlnx,versal-dwc3",
- .data = &dwc3_xlnx_init_versal,
+ .data = &versal_config,
},
{ /* Sentinel */ }
};
@@ -284,7 +299,6 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
struct dwc3_xlnx *priv_data;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- const struct of_device_id *match;
void __iomem *regs;
int ret;
@@ -296,9 +310,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
if (IS_ERR(regs))
return dev_err_probe(dev, PTR_ERR(regs), "failed to map registers\n");
- match = of_match_node(dwc3_xlnx_of_match, pdev->dev.of_node);
-
- priv_data->pltfm_init = match->data;
+ priv_data->dwc3_config = device_get_match_data(dev);
priv_data->regs = regs;
priv_data->dev = dev;
@@ -314,7 +326,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = priv_data->pltfm_init(priv_data);
+ ret = priv_data->dwc3_config->pltfm_init(priv_data);
if (ret)
goto err_clk_put;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260330190304.1841593-1-radhey.shyam.pandey@amd.com>
Versal Gen2 platform multimedia integrated (MMI) module has a USB3.2 Gen
2x1 Dual Role Device IP. Introduce a new compatibility string to support
it. The USB wrapper registers reside in the MMI UDH system-level control
registers (SLCR) block, so instead of a dedicated reg property, add
xlnx,usb-syscon phandle with four cells specifying register offsets for
USB2 PHY, USB3 PHY, USB DRD, and USB power configuration within the SLCR.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- Add blank line after compatible as suggested by Krzysztof.
- Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
IP from Synopsys is part of the dedicated Multimedia Interface. The
Versal Gen2 platform also includes a separate USB 2.0 controller,
and the mmi suffix uniquely distinguishes between the two USB
controllers. MMI is an independent subsystem particularly targeted for
deployment in Multi-Media related applications. The MMI block include
following submodules: UDH: USB3.2 Gen 2x1 Dual Role Device, DisplayPort
Transmit Controller, Security Module (ESM) for DisplayPort and HDMI
Controllers, DP AUX-I2C PHY.
- For MMI USB define parent address space i.e UDH block.
- Fix inconsistent MHz spacing to use SI convention with spaces.
- Move description before $ref and items in xlnx,usb-syscon property.
- Restore original zynqmp-dwc3 example, add new versal2-mmi-dwc3 example.
- Use 'usb' node name (without unit address) for versal2 example since
it has no reg property.
- Use 1/1 address/size configuration in versal2 example, use lowercase
hex in syscon offsets.
---
.../devicetree/bindings/usb/dwc3-xilinx.yaml | 70 ++++++++++++++++++-
1 file changed, 67 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
index d6823ef5f9a7..5e31b961aff7 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
@@ -15,6 +15,8 @@ properties:
- enum:
- xlnx,zynqmp-dwc3
- xlnx,versal-dwc3
+ - xlnx,versal2-mmi-dwc3
+
reg:
maxItems: 1
@@ -37,8 +39,9 @@ properties:
A list of phandle and clock-specifier pairs for the clocks
listed in clock-names.
items:
- - description: Master/Core clock, has to be >= 125 MHz
- for SS operation and >= 60MHz for HS operation.
+ - description: Master/Core clock, has to be >= 156.25 MHz in SSP
+ mode, >= 125 MHz for SS operation and >= 60 MHz for HS
+ operation.
- description: Clock source to core during PHY power down.
clock-names:
@@ -79,6 +82,20 @@ properties:
description: GPIO used for the reset ulpi-phy
maxItems: 1
+ xlnx,usb-syscon:
+ description:
+ Phandle to the MMI UDH system-level control register (SLCR) syscon
+ node, with four cells specifying the register offsets for USB2 PHY,
+ USB3 PHY, USB DRD, and USB power configuration respectively.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to MMI UDH SLCR syscon node
+ - description: USB2 PHY register offset within SLCR
+ - description: USB3 PHY register offset within SLCR
+ - description: USB DRD register offset within SLCR
+ - description: USB power register offset within SLCR
+
# Required child node:
patternProperties:
@@ -87,7 +104,6 @@ patternProperties:
required:
- compatible
- - reg
- "#address-cells"
- "#size-cells"
- ranges
@@ -104,6 +120,7 @@ allOf:
contains:
enum:
- xlnx,versal-dwc3
+ - xlnx,versal2-mmi-dwc3
then:
properties:
resets:
@@ -117,6 +134,26 @@ allOf:
reset-names:
minItems: 3
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,zynqmp-dwc3
+ - xlnx,versal-dwc3
+ then:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: xlnx,versal2-mmi-dwc3
+ then:
+ required:
+ - xlnx,usb-syscon
+
additionalProperties: false
examples:
@@ -156,3 +193,30 @@ examples:
};
};
};
+ - |
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
+ #include <dt-bindings/reset/xlnx-zynqmp-resets.h>
+ #include <dt-bindings/phy/phy.h>
+ usb {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,versal2-mmi-dwc3";
+ clocks = <&zynqmp_clk 32>, <&zynqmp_clk 34>;
+ clock-names = "bus_clk", "ref_clk";
+ power-domains = <&zynqmp_firmware PD_USB_0>;
+ resets = <&zynqmp_reset ZYNQMP_RESET_USB1_CORERESET>;
+ reset-names = "usb_crst";
+ phys = <&psgtr 2 PHY_TYPE_USB3 0 2>;
+ phy-names = "usb3-phy";
+ xlnx,usb-syscon = <&udh_slcr 0x005c 0x0070 0x00c4 0x00f8>;
+ ranges;
+
+ usb@fe200000 {
+ compatible = "snps,dwc3";
+ reg = <0xfe200000 0x40000>;
+ interrupt-names = "host", "otg";
+ interrupts = <0 65 4>, <0 69 4>;
+ dr_mode = "host";
+ dma-coherent;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] usb: dwc3: xilinx: Add Versal2 MMI USB 3.2 controller support
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
This series introduces support for the Multi-Media Integrated (MMI) USB
3.2 Dual-Role Device (DRD) controller on Xilinx Versal2 platforms.
The controller supports SSP(10-Gbps), SuperSpeed, high-speed, full-speed
and low-speed operation modes.
USB2 and USB3 PHY support Physical connectivity via the Type-C
connectivity. DWC3 wrapper IP IO space is in SLCR so reg is made
optional.
The driver is required for the clock, reset and platform specific
initialization (coherency/TX_DEEMPH etc). In this initial version typec
reversibility is not implemented and it is assumed that USB3 PHY TCA mux
programming is done by MMI configuration data object (CDOs) and TI PD
controller is configured using external tiva programmer on VEK385
evaluation board.
Changes for v2:
- DT binding: fix MHz spacing (SI convention), reorder description
before $ref in xlnx,usb-syscon, restore zynqmp-dwc3 example and add
versal2-mmi-dwc3 example, fix node name for no-reg case, use 1/1
address/size configuration and lowercase hex in syscon offsets.
- Split config struct refactoring (device_get_match_data,dwc3_xlnx_config)
into a separate preparatory patch.
- Fix error message capitalization to lowercase per kernel convention.
- Rename property snps,lcsr_tx_deemph to snps,lcsr-tx-deemph (hyphens).
- Fix double space in comment and missing blank line in core.h.
- Use platform data instead of of_device_is_compatible() check for
deemphasis support.
Link: https://lore.kernel.org/all/20251119193036.2666877-1-radhey.shyam.pandey@amd.com/
Radhey Shyam Pandey (4):
dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2
platform
usb: dwc3: xilinx: Introduce dwc3_xlnx_config for per-platform data
usb: dwc3: xilinx: Add Versal2 MMI USB 3.2 controller support
usb: dwc3: xilinx: Add support to program MMI USB TX deemphasis
.../devicetree/bindings/usb/dwc3-xilinx.yaml | 70 ++++++++++++++-
drivers/usb/dwc3/core.c | 17 ++++
drivers/usb/dwc3/core.h | 8 ++
drivers/usb/dwc3/dwc3-xilinx.c | 89 +++++++++++++++----
4 files changed, 166 insertions(+), 18 deletions(-)
base-commit: 46b513250491a7bfc97d98791dbe6a10bcc8129d
--
2.43.0
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Dmitry Baryshkov @ 2026-03-30 18:59 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: johannes.goede, Loic Poulain, vladimir.zapolskiy,
laurent.pinchart, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <e2a4e9dd-6a45-48dc-8757-244e201dd4d6@kernel.org>
On Mon, Mar 30, 2026 at 03:32:55PM +0100, Bryan O'Donoghue wrote:
> On 30/03/2026 15:27, johannes.goede@oss.qualcomm.com wrote:
> > > That's another reason I bring up CDM again and again. We probably don't want to fix to the wrong format for OPE, introduce the CDM and then find we have to map from one format to another for large and complex data over and over again for each frame or every N frames.
> > CDM is a much lower-level API then what is expected from
> > a media-controller centric V4L2 driver. Basically the OPE
> > driver will export:
>
> My concern is about wrappering one thing inside of another thing and then
> stuffing it again back into CDM and doing the same on the way out.
>
> There are already 50 MMIO writes in the OPE ISR, I don't believe it is
> sustainable to keep adding MMIO into that.
That's why I asked about the ABI. If we have a format for OPE
programming, we can reuse it for CDM. If we don't, we have to open the
wormhole. That is unless we make OPE driver utilize CDM instead of
writing registers through MMIO (and instead of userspace directly
programming the CDM).
>
> I'm aware of a project in qcom that did something with making the CDM format
> in libcamera and handed that off to kernel, recommend looking into that.
>
> ---
> bod
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 2/3] ath10k: Add device-tree quirk to skip host cap QMI requests
From: Jeff Johnson @ 2026-03-30 18:56 UTC (permalink / raw)
To: Dmitry Baryshkov, david
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <c5tdbllqrxxsviv7m2i3xzweyjhetv6wbpgioddaitig3tm6or@a22uaizux6nq>
On 3/29/2026 9:26 AM, Dmitry Baryshkov wrote:
> On Wed, Mar 25, 2026 at 06:57:16PM +0100, David Heidelberg via B4 Relay wrote:
>> From: Amit Pundir <amit.pundir@linaro.org>
>>
>> Some firmware versions do not support the host capability QMI request.
>> Since this request occurs before firmware-N.bin and board-M.bin are
>> loaded, the quirk cannot be expressed in the firmware itself.
>
>
> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
> Jeff, to my knowledge this is the best approach that we have to solve
> the issue on those devices.
I'm ok with this approach.
I need DT Review or ACK on the 1/3 patch in order to bring the first 2 patches
through my ath tree.
/jeff
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Dmitry Baryshkov @ 2026-03-30 18:55 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: johannes.goede, Loic Poulain, vladimir.zapolskiy,
laurent.pinchart, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <0879e4c1-5381-4a70-9fb3-4af9b3bf6e48@kernel.org>
On Mon, Mar 30, 2026 at 03:11:58PM +0100, Bryan O'Donoghue wrote:
> On 30/03/2026 14:46, johannes.goede@oss.qualcomm.com wrote:
> > > > And then your CCMv1 or CCMv2 helper will get called with
> > > > the matching parameter-data.
> > > This leads to userspace having to know exact format for each hardware
> > > version, which is not nice. At the very least it should be possible to
> > > accept CCMv1 buffers and covert them to CCMv2 when required.
> > Yes, but a new ISP may also have a different pipeline altogether
> > with e.g. more then one preview/viewfinder output vs one viewfinder
> > output for current hw, etc.
>
> My scoping on HFI shows that the IQ structures between Kona and later
> versions have pretty stable data-structures.
>
> It might be worthwhile for the non-HFI version to implement those
> structures.
>
> I keep mentioning CDM. Its also possible to construct the buffer in the
> format the CDM would require and hand that from user-space into the kernel.
>
> That would save alot of overhead translating from one format to another.
>
> That's another reason I bring up CDM again and again. We probably don't want
> to fix to the wrong format for OPE, introduce the CDM and then find we have
> to map from one format to another for large and complex data over and over
> again for each frame or every N frames.
>
> TBH I think the CDM should happen for this system and in that vein is there
> any reason not to pack the data in the order the CDM will want ?
This sounds like the most horrible idea: letting userspace directly
program any registers in a way that is not visible to the kernel.
>
> So probably in fact IQ structs are not the right thing for OPE+IFE.
>
> ---
> bod
--
With best wishes
Dmitry
^ permalink raw reply
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