* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-07 12:38 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <420dba4a-0c31-47bc-b84a-5d29702b115e@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Monday, April 6, 2026 4:44 PM
...
> >> If we stop the PWM after an IRQ, then we don't get a consistent sample
> rate.
> >> Ideally, we would leave the PWM running and just pick a rate slow enough
> >> that
> >> there is plenty of time to read the data. Otherwise, this mode doesn't seem
> >> particularly useful.
> >
> > Should there also be a condition when setting the sampling frequency, that
> will
> > protect from setting too fast sample rates?
>
> I haven't figured out a good way to do this since the real max rate
> depends on a lot of different things and when not using offloading,
> the time it takes to do SPI xfers is non-deterministic.
>
There is another question that pops in my mind. How would osr work for the buffer
sampling frequency? Since that controls the PWM period, and if say channels 0, 1, 2
are used with osr 1, 4, 8 respectively, then it would mean the PWM "required
frequency" would be something like :
osr_avg = (osr[0] + osr[1] + osr[2]) / 3;
actual_samp_freq = samp_freq / osr_avg;
The problem here being - beside what you already stated that the xfer is non-deterministic -
that the implementation could be fragile, since buffer_sampling frequency wouldn't really
know for sure which channels are enabled and so couldn't account for osr in a safe way.
The solution I propose is letting PWM run from buffer enable to disable, the whole time,
while only disabling/enabling the irq in the handler before and after spi transfer, to also
assure they are rightly happening. This way, the PWM runs at the desired rate, the only
thing here is that if the PWM is set to a too high of a frequency, some periods will be
missed, which is normal if you think about it.
For example : if the user uses a 1MHz SPI for some reason, and wants a PWM of 500kHz,
and enables 4 channels with maximum osr and maximum per-channel samp_freq.
tPWM = 1/500kHz = 2us;
tOSR_per_channel = 32 * tOSC = 32us;
-> tPWM is already too fast, but there would be more
tOSR_total = 4 * 32 = 128us;
tSPI_per_channel = 32 * tSPI = 32us (too say the least)
tSPI_total = 128us;
tSEQ_total = 256us (again, to say the least)
so the actual sampling freq is 256us in this case, but that's non-determinstic, since this
is nothing but a best case scenario, time would vary between 256-280us to say so in
reality.
I would then say so, setting a too high buffer sampling frequency (PWM frequency) implies
by itself that samples will be missed.
So then, PWM freq should be set by the user, to the desired value without capping of the
value since that capping depends on too much run-time variables set by the same user.
^ permalink raw reply
* [PATCH v4 11/11] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@bootlin.com>
Convert this driver to DRM_BRIDGE_ATTACH_NO_CONNECTOR and to the
drm_bridge_connector framework which is the current DRM bridge best
practice.
Based on the in-tree dts[i] files this introduces no regression. Based on
the kernel doc of drm_bridge_connector.c:
* To make use of this helper, all bridges in the chain shall report bridge
* operation flags (&drm_bridge->ops) and bridge output type
* (&drm_bridge->type), as well as the DRM_BRIDGE_ATTACH_NO_CONNECTOR attach
* flag (none of the bridges shall create a DRM connector directly).
and each of the 3 LCDIF blocks in the i.MX8MP, all of them comply with the
above requirement:
* For the LCDIF3, the pipeline is:
LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector
And the involved bridges are:
* fsl,imx8mp-hdmi-pvi has ops = 0 (it doesn't set it) because it
implements none the optional features mentioned by those flags, and it
honors the DRM_BRIDGE_ATTACH_NO_CONNECTOR by propagating it
* fsl,imx8mp-hdmi-tx is implemented based on dw-hdmi, which sets ops as
appropriate and also propagates the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
* display-connector (enabled via the DT overlay if needed) sets ops and
makes DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory
* The LCDIF2 involves the panel-bridge, display-connector and lvds-decoder
(even though only the pane-bridge is surrently supported), amd all these
three also set ops as needed and propagate
DRM_BRIDGE_ATTACH_NO_CONNECTOR or make it mandatory.
* The LCDIF1 is used with the adv7511, tc358767 and the panel bridge
drivers which also comply with the requirements.
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 v4:
- enhance commit message to list all involved peripherals based on my dts
review
Changes in v2:
- Added missing select DRM_DISPLAY_HELPER in Kconfig
- Rebased on previous patch changes
---
drivers/gpu/drm/mxsfb/Kconfig | 2 ++
drivers/gpu/drm/mxsfb/lcdif_drv.c | 16 +++++++++++++++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 264e74f45554..31db7a824a93 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -33,6 +33,8 @@ config DRM_IMX_LCDIF
select DRM_GEM_DMA_HELPER
select DRM_PANEL
select DRM_PANEL_BRIDGE
+ select DRM_DISPLAY_HELPER
+ select DRM_BRIDGE_CONNECTOR
help
Choose this option if you have an LCDIFv3 LCD controller.
Those devices are found in various i.MX SoC (i.MX8MP,
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index c8ba8f9b1da8..7f07ae24e0dc 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -18,6 +18,7 @@
#include <drm/clients/drm_client_setup.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_bridge.h>
+#include <drm/drm_bridge_connector.h>
#include <drm/drm_drv.h>
#include <drm/drm_encoder.h>
#include <drm/drm_fbdev_dma.h>
@@ -57,6 +58,7 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
struct of_endpoint of_ep;
struct drm_bridge *bridge;
struct drm_encoder *encoder;
+ struct drm_connector *connector;
int ret;
if (!of_device_is_available(remote))
@@ -86,11 +88,23 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
"Failed to initialize encoder for endpoint%u\n",
of_ep.id);
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
+ ret = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
return dev_err_probe(dev, ret,
"Failed to attach bridge for endpoint%u\n",
of_ep.id);
+
+ connector = drm_bridge_connector_init(lcdif->drm, encoder);
+ if (IS_ERR(connector))
+ return dev_err_probe(dev, PTR_ERR(connector),
+ "Failed to init bridge_connector for endpoint%u\n",
+ of_ep.id);
+
+ ret = drm_connector_attach_encoder(connector, encoder);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to attach connector for endpoint%u\n",
+ of_ep.id);
}
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 10/11] drm/bridge: imx8mp-hdmi-tx: switch to DRM_BRIDGE_ATTACH_NO_CONNECTOR
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@bootlin.com>
The imx8mp-hdmi-tx 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. Switching to case B, which is
the current best practice, requires that the HDMI connector is always
described in the live device tree, and a previous commit ensured this is
always the case by adding an overlay in case the device tree does not
comply.
So now we can simply switch to the new mode and support
DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- new patch, split out of the previous patch
---
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
index 32fd3554e267..8e8cfd66f23b 100644
--- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
@@ -138,6 +138,7 @@ static int imx8mp_dw_hdmi_probe(struct platform_device *pdev)
plat_data->phy_name = "SAMSUNG HDMI TX PHY";
plat_data->priv_data = hdmi;
plat_data->phy_force_vendor = true;
+ plat_data->output_port = 1;
platform_set_drvdata(pdev, hdmi);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 09/11] drm/bridge: imx8mp-hdmi-tx-connector-fixup: show a warning when adding the overlay
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@bootlin.com>
Describing the HDMI connector in device tree is recommended. While the
overlay insertion is a workaround to avoid breaking existing devices, every
dts should be improved by adding a connector description.
Add a warning to make users aware as far as possible.
As a warning line cannot hold all the relevant info, add a detailed comment
in the code so it easy to find when the warning is seen.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Liu Ying <victor.liu@nxp.com>
---
Changes in v4:
- add missing \n to warning string
- Add Liu's R-by
Patch added in v3. Kept as a separate comment w.r.t. the patch adding the
overlay to let it be added in a later moment in case we want to convert
existing dts files before adding the warning.
---
.../gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
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
index dc1736bfc3ac..aaac27d00590 100644
--- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
@@ -44,6 +44,23 @@ static int __init imx8mp_hdmi_tx_connector_fixup_init(void)
if (endpoint)
return 0;
+ /*
+ * Boards with an HDMI connector should describe it in a device
+ * tree node with compatible = "hdmi-connector".
+ *
+ * If you see this warning, it means such a node was not found and
+ * a fallback one is added using a device tree overlay. Please add
+ * one in your device tree, also describing the exact connector
+ * type (the added overlay assumes Type A as a fallback, but it
+ * might be wrong).
+ *
+ * This node is necessary for modern DRM, where bridge drivers do
+ * not create a connector (see the DRM_BRIDGE_ATTACH_NO_CONNECTOR
+ * flag). See https://docs.kernel.org/gpu/drm-kms-helpers.html for
+ * more info.
+ */
+ pr_warn("Please add a hdmi-connector DT node for imx8mp-hdmi-tx.\n");
+
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;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 08/11] drm/bridge: imx8mp-hdmi-tx-connector-fixup: add an hdmi-connector when missing using a DT overlay at boot time
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@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 v4:
- fixed warning in overlay build
Changes in v3:
- removed unused variable
- simplified overlay using full path to port@1
- handle of_overlay_fdt_apply() errors
- use of_graph_get_endpoint_by_regs() for more robust endpoint lookup
- improve subject line
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
- improve commit message
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 | 58 ++++++++++++++++++++++
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 30 +++++++++++
4 files changed, 108 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..dc1736bfc3ac
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
@@ -0,0 +1,58 @@
+// 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>
+#include <linux/of_graph.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;
+ void *dtbo_start;
+ u32 dtbo_size;
+ int ovcs_id;
+ int err;
+
+ 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_graph_get_endpoint_by_regs(hdmi_tx, 1, -1);
+ 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;
+
+ err = of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
+ if (err)
+ err = of_overlay_remove(&ovcs_id);
+
+ return err;
+}
+
+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..6ba1c1854aee
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
@@ -0,0 +1,30 @@
+// 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/;
+
+&{/} {
+ fixup-hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "HDMI";
+ type = "a";
+
+ port {
+ fixup_hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+};
+
+&{/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1} {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&fixup_hdmi_connector_in>;
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 07/11] drm/bridge: dw-hdmi: move next_bridge lookup to attach time
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@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
Acked-by: Liu Ying <victor.liu@nxp.com>
Tested-by: Damon Ding <damon.ding@rock-chips.com> # rk3399
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 v4 06/11] drm/bridge: dw-hdmi: warn on unsupported attach combination
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@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
Tested-by: Damon Ding <damon.ding@rock-chips.com> # rk3399
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
* Re: [PATCH v10 6/6] usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode
From: Heikki Krogerus @ 2026-04-07 12:24 UTC (permalink / raw)
To: Amit Sunil Dhamne
Cc: André Draszik, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Jagan Sridharan, Mark Brown,
Matti Vaittinen, Andrew Morton, Sebastian Reichel, Peter Griffin,
Tudor Ambarus, Alim Akhtar, linux-kernel, devicetree, linux-usb,
linux-pm, linux-arm-kernel, linux-samsung-soc, RD Babiera,
Kyle Tso
In-Reply-To: <017b8552-87e2-4409-ae34-9a3ab7365a68@google.com>
Hi Amit,
On Thu, Apr 02, 2026 at 11:47:30AM -0700, Amit Sunil Dhamne wrote:
> Hi Heikki,
>
> On 4/2/26 7:33 AM, Heikki Krogerus wrote:
> > Hi Amit,
> >
> > > +static int get_vbus_regulator_handle(struct max_tcpci_chip *chip)
> > > +{
> > > + if (IS_ERR_OR_NULL(chip->vbus_reg)) {
> > > + chip->vbus_reg = devm_regulator_get_exclusive(chip->dev,
> > > + "vbus");
> > Sorry to go back to this, but why can't you just get the regulator in
> > max_tcpci_probe()?
>
> Thanks for calling this out. This was an intentional design decision to
> break a circular dependency.
>
> The charger driver is guaranteed to probe after the TCPC driver due to a
> power supply dependency (the TCPC is a supplier of power for the Battery
> Charger). However, the charger driver is also the regulator provider for
> VBUS out (when Type-C goes into source mode).
>
> Because of this, the regulator handle will not be available during the TCPC
> driver's probe. If we tried to fetch it in max_tcpci_probe() and returned
> -EPROBE_DEFER, it would create a probe deadlock, as the charger would then
> never probe. Therefore, I made the decision to get the regulator handle
> lazily and on-demand.
Got it. Thanks for the explanation!
--
heikki
^ permalink raw reply
* [PATCH v4 05/11] drm/bridge: dw-hdmi: document the output_port field
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@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
Tested-by: Damon Ding <damon.ding@rock-chips.com> # rk3399
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 v4 04/11] drm/mxsfb/lcdif: move iteration-specific variables declaration inside loop in lcdif_attach_bridge
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@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.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
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 v4 03/11] drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@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 better error reporting.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
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 v4 02/11] drm/mxsfb/lcdif: simplify ep pointer management using __free
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@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.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
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 v4 01/11] drm/mxsfb/lcdif: simplify remote pointer management using __free
From: Luca Ceresoli @ 2026-04-07 12:24 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: <20260407-drm-lcdif-dbanc-v4-0-247a16e61ef9@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 v4 00/11] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Luca Ceresoli @ 2026-04-07 12:24 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 previous versions (thanks!): some patches have changed
ingnificantly in v2 and v3 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 11: the goal of this series, but would not work alone
* Patch 10: lets patch 11 work; but in turn it can't work alone
* Patch 8+9: lets patch 10 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 11 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 10 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+9 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+9 cannot work alone because of a bad interaction between
devlink and device tree overlays. Patch 7 solves that.
Tested on the Avnet MSC SM2-MB-EP1 board which currently has no
"hdmi-connector" in the upstream device tree.
== 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 v4:
- Patch 8: fix dtso warning
- Patch 9: add missing \n in warning
- Patch 11: improve commit message
- Link to v3: https://patch.msgid.link/20260402-drm-lcdif-dbanc-v3-0-27cd247a0847@bootlin.com
Changes in v3:
- Patch 8: simplified overlay, handle of_overlay_fdt_apply() errors, use
of_graph_get_endpoint_by_regs() + add warning in separate patch
- Updated cover and mentioned the hardware used for testing
- Minor fixes to other patches
- Link to v2: https://patch.msgid.link/20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@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 (11):
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: move iteration-specific variables declaration inside loop in lcdif_attach_bridge
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-connector-fixup: add an hdmi-connector when missing using a DT overlay at boot time
drm/bridge: imx8mp-hdmi-tx-connector-fixup: show a warning when adding the overlay
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 | 75 ++++++++++++++++++++++
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 30 +++++++++
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, 189 insertions(+), 63 deletions(-)
---
base-commit: 9558119259ea082c551ac3d9af912eba8ba6a99e
change-id: 20260306-drm-lcdif-dbanc-83dd948327de
Best regards,
--
Luca Ceresoli <luca.ceresoli@bootlin.com>
^ permalink raw reply
* Re: [PATCH v1 2/2] usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
From: Heikki Krogerus @ 2026-04-07 12:22 UTC (permalink / raw)
To: Jameson Thies
Cc: robh, krzk+dt, conor+dt, abhishekpandit, bleung, akuchynski,
gregkh, devicetree, chrome-platform, linux-usb, linux-kernel
In-Reply-To: <20260403223357.1896403-3-jthies@google.com>
On Fri, Apr 03, 2026 at 10:33:27PM +0000, Jameson Thies wrote:
> Add support for cros_ec_ucsi to load based on "google,cros-ec-ucsi"
> compatible devices and "GOOG0021" ACPI nodes.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/ucsi/cros_ec_ucsi.c b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> index 6bca2dce211c..251aa7251ce6 100644
> --- a/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> +++ b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> @@ -5,11 +5,13 @@
> * Copyright 2024 Google LLC.
> */
>
> +#include <linux/acpi.h>
> #include <linux/container_of.h>
> #include <linux/dev_printk.h>
> #include <linux/jiffies.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/platform_data/cros_ec_commands.h>
> #include <linux/platform_data/cros_usbpd_notify.h>
> #include <linux/platform_data/cros_ec_proto.h>
> @@ -257,7 +259,6 @@ static void cros_ucsi_destroy(struct cros_ucsi_data *udata)
> static int cros_ucsi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
> struct cros_ucsi_data *udata;
> int ret;
>
> @@ -265,9 +266,16 @@ static int cros_ucsi_probe(struct platform_device *pdev)
> if (!udata)
> return -ENOMEM;
>
> + /* ACPI and OF FW nodes for cros_ec_ucsi are children of the ChromeOS EC. If the
> + * cros_ec_ucsi device has an ACPI or OF FW node, its parent is the ChromeOS EC device.
> + * Platforms without a FW node for cros_ec_ucsi may add it as a subdevice of cros_ec_dev.
> + */
> udata->dev = dev;
> + if (is_acpi_device_node(dev->fwnode) || is_of_node(dev->fwnode))
> + udata->ec = dev_get_drvdata(dev->parent);
> + else
> + udata->ec = ((struct cros_ec_dev *)dev_get_drvdata(dev->parent))->ec_dev;
>
> - udata->ec = ec_data->ec_dev;
> if (!udata->ec)
> return dev_err_probe(dev, -ENODEV, "couldn't find parent EC device\n");
>
> @@ -348,10 +356,24 @@ static const struct platform_device_id cros_ucsi_id[] = {
> };
> MODULE_DEVICE_TABLE(platform, cros_ucsi_id);
>
> +static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {
> + { "GOOG0021", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);
> +
> +static const struct of_device_id cros_ucsi_of_match[] = {
> + { .compatible = "google,cros-ec-ucsi", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);
> +
> static struct platform_driver cros_ucsi_driver = {
> .driver = {
> .name = KBUILD_MODNAME,
> .pm = &cros_ucsi_pm_ops,
> + .acpi_match_table = cros_ec_ucsi_acpi_device_ids,
> + .of_match_table = cros_ucsi_of_match,
> },
> .id_table = cros_ucsi_id,
> .probe = cros_ucsi_probe,
> --
> 2.53.0.1213.gd9a14994de-goog
--
heikki
^ permalink raw reply
* Re: [PATCH V10 03/13] PCI: dwc: Parse Root Port nodes in dw_pcie_host_init()
From: Manivannan Sadhasivam @ 2026-04-07 12:21 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114DFBAB7D1537A9A0A7CEB925AA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Tue, Apr 07, 2026 at 09:18:58AM +0000, Sherry Sun wrote:
> > On Tue, Apr 07, 2026 at 03:21:30AM +0000, Sherry Sun wrote:
> > > > On Thu, Apr 02, 2026 at 05:50:57PM +0800, Sherry Sun wrote:
> > > > > Add support for parsing Root Port child nodes in
> > > > > dw_pcie_host_init() using pci_host_common_parse_ports(). This
> > > > > allows DWC-based drivers to specify Root Port properties (like
> > > > > reset GPIOs) in individual Root Port nodes rather than in the host bridge
> > node.
> > > > >
> > > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > > ---
> > > > > drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > index da152c31bb2e..f6fca984fb34 100644
> > > > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > @@ -20,6 +20,7 @@
> > > > > #include <linux/platform_device.h>
> > > > >
> > > > > #include "../../pci.h"
> > > > > +#include "../pci-host-common.h"
> > > > > #include "pcie-designware.h"
> > > > >
> > > > > static struct pci_ops dw_pcie_ops; @@ -581,6 +582,13 @@ int
> > > > > dw_pcie_host_init(struct dw_pcie_rp *pp)
> > > > >
> > > > > pp->bridge = bridge;
> > > > >
> > > > > + /* Parse Root Port nodes if present */
> > > > > + ret = pci_host_common_parse_ports(dev, bridge);
> > > > > + if (ret && ret != -ENOENT) {
> > > > > + dev_err(dev, "Failed to parse Root Port nodes: %d\n", ret);
> > > > > + return ret;
> > > >
> > > > Won't this change break drivers that parse Root Ports on their own?
> > > > Either you need to modify them also in this change or call this API
> > > > from imx6 driver and let other drivers switch to it in a phased manner.
> > > >
> > > > I perfer the latter.
> > >
> > > Hi Mani, sorry I didn't fully get your point here, there are no
> > > changes to this part V10, for drivers that parse Root Ports on their
> > > own, here pci_host_common_parse_ports() will return -ENOENT, so
> > > nothing break as we discussed this in V8
> > https://lore.ke/
> > rnel.org%2Fall%2Fdcl3bdljrdzgeaybrg3dc5uaxkebkjns7pajix6mxxftao5g4m%40
> > vm3ywyyp4ujh%2F&data=05%7C02%7Csherry.sun%40nxp.com%7Cd9faef64b
> > 8154bdbc6ee08de94724b22%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > 7C0%7C639111415791802118%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
> > dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=POsurqr9RqBCnaQyeXDK2HQTN
> > a4Nc0tfl7thSiM9qHA%3D&reserved=0.
> > >
> >
> > So if this API gets called first, it will acquire PERST# from the Root Port node
> > and if the controller drivers try to do the same in their own parsing code,
> > PERST# request will return -EBUSY and the probe will fail.
> >
> > On the other hand, if the controller drivers parse PERST# first, this API will
> > return -EBUSY and will result in probe failure.
> >
> > Only way to fix this issue would be to call this API from imx6 driver for now
> > and start migrating other drivers later.
> >
>
> Ok, get your point here. Your assumption is based on the premise that the controller
> driver parse the reset-gpios in the Root Port node, not that most controller drivers
> now use reset under the host bridge node. For reset-gpios in the Root Port node,
> they should eventually switch to this common API.
>
Not many, but still some and it is paramount to not regress them. That's my
point.
> Anyway, I will call this API in imx6 driver at this stage to avoid impact other platforms.
>
Sounds good!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Bui Duc Phuc @ 2026-04-07 12:18 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <87a4vfu0mz.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
> Ah... is it because PIO transfer ?
> I have 100% forgotten, but FSI doesn't support RX DMA...
That is correct. Currently, the Armadillo board lacks DMA and HDMI support
after the transition to DTS, so FSI is limited to FSIA in PIO mode. I plan to
investigate those drivers further once the FSI implementation is finalized.
> Hmm... fsi_dai_trigger() seems strange.
> It seems (A) stops clock, and (B) sets register after that.
> Is this the reason why you get error ? I think (A) and (B) should be
> reversed. The balance between SNDRV_PCM_TRIGGER_START, and with
> __fsi_suspend() are also not good.
> If so, can you use hw_start/stop() ?
Thank you for the guidance. After reordering the sequence and moving the
SPU power control to fsi_hw_start/shutdown, the system hang is now resolved.
> Basically, concept of this driver is that power/clock is enabled/disabled
> when trigger() was called (except suspend/resume).
> While your testing may be correct from an ALSA point of view, but setting
> configuring it in multiple places will lead to confusion.
I see your point. I agree that keeping the power/clock management centralized
in trigger() is a much cleaner approach.
By the way, I’d like to discuss the fsidiv clock handling.
In the legacy implementation, it was handled here:
https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/sh/clk/cpg.c.
Currently, this has not been ported to the Common Clock Framework (CCF) for
R8A7740, and it resides in a different register range from the core CPG.
For v2, would you prefer that I implement a small clock provider for
fsidiv within
the FSI driver, or should it be added under drivers/clk/renesas/?
Best regards,
Phuc
^ permalink raw reply
* Re: [RFC][PATCH 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Geert Uytterhoeven @ 2026-04-07 12:06 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260328000031.94645-4-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sat, 28 Mar 2026 at 01:00, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
> @@ -551,9 +551,9 @@ cpg_clocks: cpg_clocks@e6150000 {
> clock-output-names = "system", "pllc0", "pllc1",
> "pllc2", "r",
> "usb24s",
> - "i", "zg", "b", "m1", "hp",
> - "hpp", "usbp", "s", "zb", "m3",
> - "cp";
> + "i", "zg", "b", "m1", "ztr", "zt",
> + "hp", "hpp", "usbp", "s", "zb",
> + "m3", "cp";
The order of the names must match the indices in the DT bindings below.
Else consumers end up with a wrong parent clock, leading to issues
like the I2C controller driver failing to probe because its parent
clock is out of range.
> };
>
> /* Variable factor clocks (DIV6) */
> diff --git a/include/dt-bindings/clock/r8a7740-clock.h b/include/dt-bindings/clock/r8a7740-clock.h
> index 1b3fdb39cc426..8a8816b2ff6ac 100644
> --- a/include/dt-bindings/clock/r8a7740-clock.h
> +++ b/include/dt-bindings/clock/r8a7740-clock.h
> @@ -24,6 +24,8 @@
> #define R8A7740_CLK_ZB 14
> #define R8A7740_CLK_M3 15
> #define R8A7740_CLK_CP 16
> +#define R8A7740_CLK_ZTR 17
> +#define R8A7740_CLK_ZT 18
Append at the end, good.
>
> /* MSTP1 */
> #define R8A7740_CLK_CEU21 28
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 3/3] arm64: dts: qcom: Add Samsung Galaxy Book4 Edge DTS/DTSI
From: Konrad Dybcio @ 2026-04-07 11:55 UTC (permalink / raw)
To: Maxim Storetvedt, andersson, robh, krzk+dt, conor+dt
Cc: marcus, marijn.suijten, linux-arm-msm, devicetree, linux-kernel,
abel.vesa, abel.vesa, johan, konradybcio, kirill
In-Reply-To: <e6134dd0-6672-44ce-8ced-41fc3e21e474@cern.ch>
On 3/31/26 6:34 PM, Maxim Storetvedt wrote:
>
>
> On 3/30/26 12:41, Konrad Dybcio wrote:
>> On 3/26/26 7:30 PM, Maxim Storetvedt wrote:
>>>
>>>
>>> On 3/26/26 12:33, Konrad Dybcio wrote:
>>>> On 3/25/26 7:30 PM, Maxim Storetvedt wrote:
>>>>>
>>>>>
>>>>> On 3/23/26 13:17, Konrad Dybcio wrote:
>>>>>> On 3/22/26 5:03 PM, Maxim Storetvedt wrote:
>>>>>>> Adds devicetrees for the 14-inch and 16-inch SKUs of the Samsung Galaxy Book4 Edge.
>>>>>>>
>>>>>>> These use a common dtsi derived from nodes that were able to work on Linux
>>>>>>> from the initial Galaxy Book4 Edge DTS by Marcus:
>>>>>>>
>>>>>>> Link: https://lore.kernel.org/all/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/
>>>>>>>
>>>>>>> combined with the ongoing patch for the Honor Magicbook Art 14, and its downstream by
>>>>>>> Valentin Manea, which shares device similarities:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> +&i2c8 {
>>>>>>> + clock-frequency = <400000>;
>>>>>>> +
>>>>>>> + status = "okay";
>>>>>>> +
>>>>>>> + touchscreen@5d {
>>>>>>> + compatible = "hid-over-i2c";
>>>>>>> + reg = <0x5d>;
>>>>>>> +
>>>>>>> + hid-descr-addr = <0x1>;
>>>>>>> + interrupts-extended = <&tlmm 34 IRQ_TYPE_LEVEL_LOW>;
>>>>>>> +
>>>>>>> + vdd-supply = <&vreg_misc_3p3>;
>>>>>>> + /* Lower power supply is not enoug to work. */
>>>>>>> + // vddl-supply = <&vreg_l15b_1p8>;
>>>>>>
>>>>>> How should we interpret that?
>>>>>>
>>>>>
>>>>> This was in the original patch, but using that same regulator appears to
>>>>> be enough to also get touchscreen working on the 16" book4e. That said,
>>>>> it still does not work on the 14". Something to revisit later...
>>>>>
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> +&panel {
>>>>>>> + compatible = "samsung,atna40cu07", "samsung,atna33xc20";
>>>>>>
>>>>>> I think it'd make sense to move the compatible from 'common' to the
>>>>>> 16in DTS then too
>>>>>>
>>>>>>> + enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
>>>>>>
>>>>>> this matches the common definition
>>>>>>
>>>>>>> + power-supply = <&vreg_edp_3p3>;
>>>>>>
>>>>>> ditto
>>>>>>
>>>>>>> + no-hpd;
>>>>>>
>>>>>> really??
>>>>>>
>>>>> One less thing to debug while previously attempting to work around the
>>>>> "illegal link rate" error, which turned out to be related to eDP 1.4
>>>>> (similar to the sp11). I've kept it as-is in case other SKUs attempt
>>>>> booting from this dts, such as the x1e80100 16" (as it might be getting
>>>>> a black screen using the current x1e84100 16" dts, though this is not
>>>>> fully tested).
>>>>
>>>> So do the 80100 and 84100-equipped SKUs of the laptop come with different
>>>> displays?
>>>>
>>>> Konrad
>>>
>>> So far assumed both 16" variants to be fairly similar, though one
>>> valiant 16" 80100 user over in the debug thread did try to boot via the
>>> 84100 dts, with no success. Instead having the screen go dark after the
>>> first post-tux kernel prints.
>>
>> Does switching to the generic edp-panel compatible (which will parse the
>> EDID and try not to be overly smart about it) help here?
>>
>>> This was strapped together via WSL though, so could be there was
>>> something else at fault, but strange it didn't at least fall back to a
>>> visible initramfs shell.
>>
>> You mean the kernel had been compiled via WSL? That shouldn't be a problem..
>>
>> Konrad
>
> Kernel was one shared by me in advance (same I've been using as a
> daily), so it should be OK, but there was an uphill battle in creating
> the modified system image afaik (that would boot).
>
> Can only speculate until there is another go at this, but could likewise
> be something completely unrelated that's simple to fix, e.g. older mesa
> in image, but final attempt at boot used a dts with gpu node enabled.
FWIW the GPU and display engine are completely disjoint, so mesa itself
shouldn't be an issue (unless something was caught in a restart loop due
to poor error handling.. I've seen that N years ago but have no clue
that would still be a problem nowadays)
Konrad
^ permalink raw reply
* Re: [PATCH] dt-binding: leds: publish common bindings under dual license
From: Greg Kroah-Hartman @ 2026-04-07 11:45 UTC (permalink / raw)
To: Corvin Köhne
Cc: linux-kernel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, open list:LED SUBSYSTEM, Krzysztof Kozlowski,
Conor Dooley, Pavel Machek, Lee Jones, Corvin Köhne,
Ashley Towns, Dan Murphy, Gergo Koteles, INAGAKI Hiroshi,
Jacek Anaszewski, Jacek Anaszewski, Linus Torvalds,
Olliver Schinagl, Pavel Machek, Rafał Miłecki,
Roderick Colenbrander
In-Reply-To: <20260407113941.43239-1-corvin.koehne@gmail.com>
On Tue, Apr 07, 2026 at 01:39:41PM +0200, Corvin Köhne wrote:
> From: Corvin Köhne <c.koehne@beckhoff.com>
>
> Changes leds/common.h DT binding header file to be published under GPLv2
> or BSD-2-Clause license terms. This change allows this common LED
> bindings header file to be used in software components as bootloaders
> and OSes that are not published under GPLv2 terms.
>
> All contributors to leds/common.h file in copy.
>
> Cc: Ashley Towns <mail@ashleytowns.id.au>
> Cc: Dan Murphy <dmurphy@ti.com>
> Cc: Gergo Koteles <soyer@irl.hu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
My only change was to put the proper SPDX line on the file, so my
opinion/change does not count here for a licensing change, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: qcom: sm8550: add PCIe MHI register regions and port labels
From: Joe Sandom @ 2026-04-07 11:43 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <ac8a4139-f7ed-4ced-885a-59145c188406@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 01:05:31PM +0200, Konrad Dybcio wrote:
> On 4/4/26 11:50 AM, Joe Sandom via B4 Relay wrote:
> > From: Joe Sandom <jsandom@axon.com>
> >
> > Add the MHI register regions to the pcie0 and pcie1 controller nodes
> > so that the MHI bus layer can access controller registers directly.
> >
> > Also add labels to the root port nodes (pcie0_port0, pcie1_port0) to
> > allow board DTS files to reference them for adding endpoint devices
> > to each pcie root port.
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/sm8550.dtsi | 14 ++++++++------
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index 912525e9bca6f5e1cbb8887ee0bf9e39650dc4ff..d4caf4d00832d7f1e8f65bf2bc873cddadc42168 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -1964,8 +1964,9 @@ pcie0: pcie@1c00000 {
> > <0 0x60000000 0 0xf1d>,
> > <0 0x60000f20 0 0xa8>,
> > <0 0x60001000 0 0x1000>,
> > - <0 0x60100000 0 0x100000>;
> > - reg-names = "parf", "dbi", "elbi", "atu", "config";
> > + <0 0x60100000 0 0x100000>,
> > + <0 0x01C03000 0 0x1000>;
>
> lowercase hex please, both places
Ack. Will correct this in v2.
>
> > + reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
>
> Since you're touching this part of the file anyway and others asked for
> more changes.. could you please break up the reg-names that you're
> editing such that there's one entry per line and they're aligned on
> the opening quote, i.e.
>
> reg-names = "foo",
> "bar",
> ...
>
> ?
Will do this in V2. Thanks Konrad.
>
> FWIW the reg ranges you added are OK
>
> Konrad
^ permalink raw reply
* [PATCH v4 5/5] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
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
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 4/5] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..c2865a6b1d7fb 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,15 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .features = BIT(PHY_GMII_SEL_RGMII_ID_MODE) |
+ BIT(PHY_GMII_SEL_FIXED_TX_DELAY),
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +316,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
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
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..0653252c18d8e 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,18 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
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
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 3/5] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6b584706b913a..7531a8a049123 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
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
https://www.tq-group.com/
^ 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