* [PATCH v4 net-next 01/14] dt-bindings: net: dsa: update the description of 'dsa,member' property
From: Wei Fang @ 2026-03-31 11:30 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
f.fainelli, frank.li, chleroy, horms, linux, andrew
Cc: netdev, linux-kernel, devicetree, linuxppc-dev, linux-arm-kernel,
imx
In-Reply-To: <20260331113025.1566878-1-wei.fang@nxp.com>
The current description indicates that the 'dsa,member' property cannot
be set for a switch that is not part of any cluster. Vladimir thinks
that this is a case where the actual technical limitation was poorly
transposed into words when this restriction was first documented, in
commit 8c5ad1d6179d ("net: dsa: Document new binding").
The true technical limitation is that many DSA tagging protocols are
topology-unaware, and always call dsa_conduit_find_user() with a
switch_id of 0. Specifying a custom "dsa,member" property with a
non-zero switch_id would break them.
Therefore, for topology-aware switches, it is fine to specify this
property for them, even if they are not part of any cluster. Our NETC
switch is a good example which is topology-aware, the switch_id is
carried in the switch tag, but the switch_id 0 is reserved for VEPA
switch and cannot be used, so we need to use this property to assign
a non-zero switch_id for it.
Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
Documentation/devicetree/bindings/net/dsa/dsa.yaml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
index 2abd036578d1..801e1411e5c2 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
@@ -28,7 +28,11 @@ properties:
A two element list indicates which DSA cluster, and position within the
cluster a switch takes. <0 0> is cluster 0, switch 0. <0 1> is cluster 0,
switch 1. <1 0> is cluster 1, switch 0. A switch not part of any cluster
- (single device hanging off a CPU port) must not specify this property
+ (single device hanging off a CPU port) does not usually need to specify
+ this property, and then it becomes cluster 0, switch 0. For a topology
+ aware switch, its switch index can be specified through this property,
+ even if it is not part of any cluster. Also, topology-unaware switches
+ must always be defined as index 0 of their cluster.
$ref: /schemas/types.yaml#/definitions/uint32-array
additionalProperties: true
--
2.34.1
^ permalink raw reply related
* [PATCH v4 net-next 00/14] Add preliminary NETC switch support for i.MX94
From: Wei Fang @ 2026-03-31 11:30 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
f.fainelli, frank.li, chleroy, horms, linux, andrew
Cc: netdev, linux-kernel, devicetree, linuxppc-dev, linux-arm-kernel,
imx
i.MX94 NETC (v4.3) integrates 802.1Q Ethernet switch functionality, the
switch provides advanced QoS with 8 traffic classes and a full range of
TSN standards capabilities. It has 3 user ports and 1 CPU port, and the
CPU port is connected to an internal ENETC through the pseduo link, so
instead of a back-to-back MAC, the lightweight "pseudo MAC" is used at
both ends of the pseudo link to transfer Ethernet frames. The pseudo
link provides a zero-copy interface (no serialization delay) and lower
power (less logic and memory).
Like most Ethernet switches, the NETC switch also supports a proprietary
switch tag, is used to carry in-band metadata information about frames.
This in-band metadata information can include the source port from which
the frame was received, what was the reason why this frame got forwarded
to the entity, and for the entity to indicate the precise destination
port of a frame. The NETC switch tag is added to frames after the source
MAC address. There are three types of switch tags, and each type has 1
to 4 subtypes, more details are as follows.
Forward switch tag (Type = 0): Represents forwarded frames.
- SubType = 0 - Normal frame processing.
To_Port switch tag (Type = 1): Represents frames that are to be sent to
a specific switch port.
- SubType = 0. No request to perform timestamping.
- SubType = 1. Request to perform one-step timestamping.
- SubType = 2. Request to perform two-step timestamping.
- SubType = 3. Request to perform both one-step timestamping and
two-step timestamping.
To_Host switch tag (Type = 2): Represents frames redirected or copied to
the switch management port.
- SubType = 0. Received frames redirected or copied to the switch
management port.
- SubType = 1. Received frames redirected or copied to the switch
management port with captured timestamp at the switch port where
the frame was received.
- SubType = 2. Transmit timestamp response (two-step timestamping).
Currently, this patch set supports Forward tag, SubType 0 of To_Port tag
and SubType 0 of To_Host tag. More tags will be supported in the future.
In addition, the switch supports NETC Table Management Protocol (NTMP),
some switch functionality is controlled using control messages sent to
the hardware using BD ring interface with 32B descriptors similar to the
packet Transmit BD ring used on ENETC. This interface is referred to as
the command BD ring. This is used to configure functionality where the
underlying resources may be shared between different entities or being
too large to configure using direct registers.
For this patch set, we have supported the following tables through the
command BD ring interface.
FDB Table: It contains forwarding and/or filtering information about MAC
addresses. The FDB table is used for MAC learning lookups and MAC
forwarding lookups.
VLAN Filter Table: It contains configuration and control information for
each VLAN configured on the switch.
Buffer Pool Table: It contains buffer pool configuration and operational
information. Each entry corresponds to a buffer pool. Currently, we use
this table to implement flow control feature on each port.
Ingress Port Filter Table: It contains a set of filters each capable of
classifying incoming traffic using a mix of L2, L3, and L4 parsed and
arbitrary field data. We use this table to implement host flood support
to the switch port.
The switch also supports other tables, and we will add more advanced
features through them in the future.
---
v4:
1. Fix some nits in patch 2.
2. Revert netc_ipv_to_buffer_pool_mapping() to v2, the new added code in
v3 is actually a dead code and was only added to address false positives
reported by AI review. Therefore, v4 optimizes the comments in
netc_switch_bpt_default_config() to avoid the false positives.
v3 link: https://lore.kernel.org/imx/20260326062917.3552334-1-wei.fang@nxp.com/
v2 link: https://lore.kernel.org/imx/20260323060752.1157031-1-wei.fang@nxp.com/
v1 link: https://lore.kernel.org/imx/20260316094152.1558671-1-wei.fang@nxp.com/
---
Wei Fang (14):
dt-bindings: net: dsa: update the description of 'dsa,member' property
dt-bindings: net: dsa: add NETC switch
net: enetc: add pre-boot initialization for i.MX94 switch
net: enetc: add basic operations to the FDB table
net: enetc: add support for the "Add" operation to VLAN filter table
net: enetc: add support for the "Update" operation to buffer pool
table
net: enetc: add support for "Add" and "Delete" operations to IPFT
net: enetc: add multiple command BD rings support
net: dsa: add NETC switch tag support
net: dsa: netc: introduce NXP NETC switch driver for i.MX94
net: dsa: netc: add phylink MAC operations
net: dsa: netc: add more basic functions support
net: dsa: netc: initialize buffer bool table and implement
flow-control
net: dsa: netc: add support for the standardized counters
.../devicetree/bindings/net/dsa/dsa.yaml | 6 +-
.../bindings/net/dsa/nxp,netc-switch.yaml | 130 ++
MAINTAINERS | 11 +
drivers/net/dsa/Kconfig | 3 +
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/netc/Kconfig | 14 +
drivers/net/dsa/netc/Makefile | 3 +
drivers/net/dsa/netc/netc_ethtool.c | 192 +++
drivers/net/dsa/netc/netc_main.c | 1528 +++++++++++++++++
drivers/net/dsa/netc/netc_platform.c | 90 +
drivers/net/dsa/netc/netc_switch.h | 155 ++
drivers/net/dsa/netc/netc_switch_hw.h | 335 ++++
.../ethernet/freescale/enetc/netc_blk_ctrl.c | 188 +-
drivers/net/ethernet/freescale/enetc/ntmp.c | 383 ++++-
.../ethernet/freescale/enetc/ntmp_private.h | 122 +-
include/linux/dsa/tag_netc.h | 14 +
include/linux/fsl/netc_global.h | 6 +
include/linux/fsl/ntmp.h | 235 ++-
include/net/dsa.h | 2 +
include/uapi/linux/if_ether.h | 1 +
net/dsa/Kconfig | 10 +
net/dsa/Makefile | 1 +
net/dsa/tag_netc.c | 185 ++
23 files changed, 3585 insertions(+), 30 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
create mode 100644 drivers/net/dsa/netc/Kconfig
create mode 100644 drivers/net/dsa/netc/Makefile
create mode 100644 drivers/net/dsa/netc/netc_ethtool.c
create mode 100644 drivers/net/dsa/netc/netc_main.c
create mode 100644 drivers/net/dsa/netc/netc_platform.c
create mode 100644 drivers/net/dsa/netc/netc_switch.h
create mode 100644 drivers/net/dsa/netc/netc_switch_hw.h
create mode 100644 include/linux/dsa/tag_netc.h
create mode 100644 net/dsa/tag_netc.c
--
2.34.1
^ permalink raw reply
* Re: [PATCH v5 1/9] dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
From: Ulf Hansson @ 2026-03-31 11:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Iker Pedrosa, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel
In-Reply-To: <1c1b12f2-b305-4341-8269-788fb9e11cdc@kernel.org>
On Tue, 31 Mar 2026 at 13:11, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 31/03/2026 12:58, Ulf Hansson wrote:
> >>> + - default
> >>> + - state_uhs
> >>
> >> Instead: uhs
> >
> > While I agree that "uhs" would be better, we have tried to stick with
> > "state_uhs" for legacy and consistency reasons with other mmc
> > controllers.
> >
> > No strong opinion though, what do you think?
> >
>
> I missed that it is already present in other places. Is the name coming
> from any other referenced schema like mmc-controller? Does the existing
> common driver code expect state_uhs?
No common schema or binding states that it must be "state_uhs".
It's all described on a per-controller basis, but I was thinking we
should perhaps make it common at some point.
>
> If yes, then go with state_uhs, if not then let's switch to new name.
> Old conventions in the bindings can be changed, we already do many
> things differently than 10 years ago (e.g. no underscores in node and
> property names).
Okay, let's go with solely "uhs" then.
At some point we should make this part of the common mmc-controller
bindings too.
>
> But followup question - the binding is called sdhci, so maybe sdhci
> common schema should be referenced?
Yes, that seems reasonable.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH V3 0/9] Add Invensense ICM42607
From: Andy Shevchenko @ 2026-03-31 11:25 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260330195853.392877-1-macroalpha82@gmail.com>
On Mon, Mar 30, 2026 at 02:58:44PM -0500, Chris Morgan wrote:
> Add support for the ICM42607 IMU. This sensor shares the same
> functionality but a different register layout with the existing
> ICM42600.
>
> This driver should work with the ICM42607 and ICM42607P over both I2C
> and SPI, however only the ICM42607P over I2C could be tested.
>
> Changes Since V1:
> - Instead of creating a new driver, merged with the existing inv_icm42600
> driver. This necessitated adding some code to the existing driver to
> permit using a different register layout for the same functionality.
> - Split changes up a bit more to decrease the size of the individual
> patches. Note that patch 0004 is still pretty hefty; if I need to split
> further I may need to create some temporary stub functions.
> - Used guard() and PM_RUNTIME_ACQUIRE_AUTOSUSPEND() on the new functions
> per Jonathan's recommendations.
>
> Changes Since V2:
> - Went back to using a new driver on advice from Invensense engineer.
Okay, but this should be elaborated in the cover letter. If I followed
previous discussion correctly, the problem is the indirect subset of
registers that are absent on the 42600 series. But would be nice to have
the summary of what vendor engineers told you.
> - Further split changes up into smaller chunks of functionality. Note
> still that the largest patch is approximately 900 lines, and that while
> the driver compiles cleanly at each commit it is not able to drive the
> hardware until the commit that adds the Interrupt (as it also adds the
> Makefile).
> - Change the error to a warning when the devicetree binding does not match
> the hardware ID.
> - Dropped the ack on the devicetree bindings, as I am creating a new file
> (for a new driver) instead of modifying the existing one.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 1/2] memory: tegra: Add T238 MC support
From: Ashish Mhetre @ 2026-03-31 11:23 UTC (permalink / raw)
To: krzk, robh, conor+dt, =thierry.reding, jonathanh, sumitg
Cc: linux-kernel, devicetree, linux-tegra, Ashish Mhetre
In-Reply-To: <20260331112347.3897841-1-amhetre@nvidia.com>
Add Memory Controller driver support for Tegra238 SOC, including:
- MC client definitions with Tegra238-specific stream IDs
- Reuse of Tegra234 ICC operations for bandwidth management via BPMP-FW
- Device tree compatible string "nvidia,tegra238-mc"
Export tegra234_mc_icc_ops so it can be shared with the Tegra238 MC
driver, as both SoCs use the same ICC aggregation and bandwidth
management logic.
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
drivers/memory/tegra/Makefile | 1 +
drivers/memory/tegra/mc.c | 3 +
drivers/memory/tegra/mc.h | 6 +
drivers/memory/tegra/tegra234.c | 2 +-
drivers/memory/tegra/tegra238.c | 395 ++++++++++++++++++++++++++++++++
5 files changed, 406 insertions(+), 1 deletion(-)
create mode 100644 drivers/memory/tegra/tegra238.c
diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
index 6334601e6120..0d50e37d43af 100644
--- a/drivers/memory/tegra/Makefile
+++ b/drivers/memory/tegra/Makefile
@@ -10,6 +10,7 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
tegra-mc-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
tegra-mc-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra186.o tegra194.o
tegra-mc-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra186.o tegra234.o
+tegra-mc-$(CONFIG_ARCH_TEGRA_238_SOC) += tegra186.o tegra238.o
tegra-mc-$(CONFIG_ARCH_TEGRA_264_SOC) += tegra186.o tegra264.o
obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index d620660da331..10ef3c323e22 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -49,6 +49,9 @@ static const struct of_device_id tegra_mc_of_match[] = {
#ifdef CONFIG_ARCH_TEGRA_234_SOC
{ .compatible = "nvidia,tegra234-mc", .data = &tegra234_mc_soc },
#endif
+#ifdef CONFIG_ARCH_TEGRA_238_SOC
+ { .compatible = "nvidia,tegra238-mc", .data = &tegra238_mc_soc },
+#endif
#ifdef CONFIG_ARCH_TEGRA_264_SOC
{ .compatible = "nvidia,tegra264-mc", .data = &tegra264_mc_soc },
#endif
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 649b54369263..d0da4a5f192d 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -238,6 +238,11 @@ extern const struct tegra_mc_soc tegra194_mc_soc;
#ifdef CONFIG_ARCH_TEGRA_234_SOC
extern const struct tegra_mc_soc tegra234_mc_soc;
+extern const struct tegra_mc_icc_ops tegra234_mc_icc_ops;
+#endif
+
+#ifdef CONFIG_ARCH_TEGRA_238_SOC
+extern const struct tegra_mc_soc tegra238_mc_soc;
#endif
#ifdef CONFIG_ARCH_TEGRA_264_SOC
@@ -256,6 +261,7 @@ extern const struct tegra_mc_ops tegra30_mc_ops;
#if defined(CONFIG_ARCH_TEGRA_186_SOC) || \
defined(CONFIG_ARCH_TEGRA_194_SOC) || \
defined(CONFIG_ARCH_TEGRA_234_SOC) || \
+ defined(CONFIG_ARCH_TEGRA_238_SOC) || \
defined(CONFIG_ARCH_TEGRA_264_SOC)
extern const struct tegra_mc_ops tegra186_mc_ops;
#endif
diff --git a/drivers/memory/tegra/tegra234.c b/drivers/memory/tegra/tegra234.c
index 87b22038a5fb..9fbd34d4abe0 100644
--- a/drivers/memory/tegra/tegra234.c
+++ b/drivers/memory/tegra/tegra234.c
@@ -1125,7 +1125,7 @@ static int tegra234_mc_icc_get_init_bw(struct icc_node *node, u32 *avg, u32 *pea
return 0;
}
-static const struct tegra_mc_icc_ops tegra234_mc_icc_ops = {
+const struct tegra_mc_icc_ops tegra234_mc_icc_ops = {
.xlate = tegra_mc_icc_xlate,
.aggregate = tegra234_mc_icc_aggregate,
.get_bw = tegra234_mc_icc_get_init_bw,
diff --git a/drivers/memory/tegra/tegra238.c b/drivers/memory/tegra/tegra238.c
new file mode 100644
index 000000000000..5abdca16a275
--- /dev/null
+++ b/drivers/memory/tegra/tegra238.c
@@ -0,0 +1,395 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, NVIDIA CORPORATION. All rights reserved.
+ */
+
+#include <soc/tegra/mc.h>
+
+#include <dt-bindings/memory/tegra234-mc.h>
+#include <dt-bindings/memory/nvidia,tegra238-mc.h>
+#include <linux/interconnect.h>
+#include <linux/tegra-icc.h>
+
+#include <soc/tegra/bpmp.h>
+#include "mc.h"
+
+static const struct tegra_mc_client tegra238_mc_clients[] = {
+ {
+ .id = TEGRA234_MEMORY_CLIENT_HDAR,
+ .name = "hdar",
+ .bpmp_id = TEGRA_ICC_BPMP_HDA,
+ .type = TEGRA_ICC_ISO_AUDIO,
+ .sid = TEGRA238_SID_HDA,
+ .regs = {
+ .sid = {
+ .override = 0xa8,
+ .security = 0xac,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_HDAW,
+ .name = "hdaw",
+ .bpmp_id = TEGRA_ICC_BPMP_HDA,
+ .type = TEGRA_ICC_ISO_AUDIO,
+ .sid = TEGRA238_SID_HDA,
+ .regs = {
+ .sid = {
+ .override = 0x1a8,
+ .security = 0x1ac,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_SDMMCRAB,
+ .name = "sdmmcrab",
+ .bpmp_id = TEGRA_ICC_BPMP_SDMMC_4,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_SDMMC4A,
+ .regs = {
+ .sid = {
+ .override = 0x318,
+ .security = 0x31c,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_SDMMCWAB,
+ .name = "sdmmcwab",
+ .bpmp_id = TEGRA_ICC_BPMP_SDMMC_4,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_SDMMC4A,
+ .regs = {
+ .sid = {
+ .override = 0x338,
+ .security = 0x33c,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_APER,
+ .name = "aper",
+ .bpmp_id = TEGRA_ICC_BPMP_APE,
+ .type = TEGRA_ICC_ISO_AUDIO,
+ .sid = TEGRA238_SID_ISO_APE0,
+ .regs = {
+ .sid = {
+ .override = 0x3d0,
+ .security = 0x3d4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_APEW,
+ .name = "apew",
+ .bpmp_id = TEGRA_ICC_BPMP_APE,
+ .type = TEGRA_ICC_ISO_AUDIO,
+ .sid = TEGRA238_SID_ISO_APE0,
+ .regs = {
+ .sid = {
+ .override = 0x3d8,
+ .security = 0x3dc,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_NVDISPLAYR,
+ .name = "nvdisplayr",
+ .bpmp_id = TEGRA_ICC_BPMP_DISPLAY,
+ .type = TEGRA_ICC_ISO_DISPLAY,
+ .sid = TEGRA238_SID_ISO_NVDISPLAY,
+ .regs = {
+ .sid = {
+ .override = 0x490,
+ .security = 0x494,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_NVDISPLAYR1,
+ .name = "nvdisplayr1",
+ .bpmp_id = TEGRA_ICC_BPMP_DISPLAY,
+ .type = TEGRA_ICC_ISO_DISPLAY,
+ .sid = TEGRA238_SID_ISO_NVDISPLAY,
+ .regs = {
+ .sid = {
+ .override = 0x508,
+ .security = 0x50c,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_BPMPR,
+ .name = "bpmpr",
+ .sid = TEGRA238_SID_BPMP,
+ .regs = {
+ .sid = {
+ .override = 0x498,
+ .security = 0x49c,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_BPMPW,
+ .name = "bpmpw",
+ .sid = TEGRA238_SID_BPMP,
+ .regs = {
+ .sid = {
+ .override = 0x4a0,
+ .security = 0x4a4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_BPMPDMAR,
+ .name = "bpmpdmar",
+ .sid = TEGRA238_SID_BPMP,
+ .regs = {
+ .sid = {
+ .override = 0x4a8,
+ .security = 0x4ac,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_BPMPDMAW,
+ .name = "bpmpdmaw",
+ .sid = TEGRA238_SID_BPMP,
+ .regs = {
+ .sid = {
+ .override = 0x4b0,
+ .security = 0x4b4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_APEDMAR,
+ .name = "apedmar",
+ .bpmp_id = TEGRA_ICC_BPMP_APEDMA,
+ .type = TEGRA_ICC_ISO_AUDIO,
+ .sid = TEGRA238_SID_ISO_APE1,
+ .regs = {
+ .sid = {
+ .override = 0x4f8,
+ .security = 0x4fc,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_APEDMAW,
+ .name = "apedmaw",
+ .bpmp_id = TEGRA_ICC_BPMP_APEDMA,
+ .type = TEGRA_ICC_ISO_AUDIO,
+ .sid = TEGRA238_SID_ISO_APE1,
+ .regs = {
+ .sid = {
+ .override = 0x500,
+ .security = 0x504,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_VICSRD,
+ .name = "vicsrd",
+ .bpmp_id = TEGRA_ICC_BPMP_VIC,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_VIC,
+ .regs = {
+ .sid = {
+ .override = 0x360,
+ .security = 0x364,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_VICSWR,
+ .name = "vicswr",
+ .bpmp_id = TEGRA_ICC_BPMP_VIC,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_VIC,
+ .regs = {
+ .sid = {
+ .override = 0x368,
+ .security = 0x36c,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_NVDECSRD,
+ .name = "nvdecsrd",
+ .bpmp_id = TEGRA_ICC_BPMP_NVDEC,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_NVDEC,
+ .regs = {
+ .sid = {
+ .override = 0x3c0,
+ .security = 0x3c4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_NVDECSWR,
+ .name = "nvdecswr",
+ .bpmp_id = TEGRA_ICC_BPMP_NVDEC,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_NVDEC,
+ .regs = {
+ .sid = {
+ .override = 0x3c8,
+ .security = 0x3cc,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_NVENCSRD,
+ .name = "nvencsrd",
+ .bpmp_id = TEGRA_ICC_BPMP_NVENC,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_NVENC,
+ .regs = {
+ .sid = {
+ .override = 0xe0,
+ .security = 0xe4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_NVENCSWR,
+ .name = "nvencswr",
+ .bpmp_id = TEGRA_ICC_BPMP_NVENC,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_NVENC,
+ .regs = {
+ .sid = {
+ .override = 0x158,
+ .security = 0x15c,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_PCIE0R,
+ .name = "pcie0r",
+ .bpmp_id = TEGRA_ICC_BPMP_PCIE_0,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_PCIE0,
+ .regs = {
+ .sid = {
+ .override = 0x6c0,
+ .security = 0x6c4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_PCIE0W,
+ .name = "pcie0w",
+ .bpmp_id = TEGRA_ICC_BPMP_PCIE_0,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_PCIE0,
+ .regs = {
+ .sid = {
+ .override = 0x6c8,
+ .security = 0x6cc,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_PCIE1R,
+ .name = "pcie1r",
+ .bpmp_id = TEGRA_ICC_BPMP_PCIE_1,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_PCIE1,
+ .regs = {
+ .sid = {
+ .override = 0x6d0,
+ .security = 0x6d4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_PCIE1W,
+ .name = "pcie1w",
+ .bpmp_id = TEGRA_ICC_BPMP_PCIE_1,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_PCIE1,
+ .regs = {
+ .sid = {
+ .override = 0x6d8,
+ .security = 0x6dc,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_PCIE2AR,
+ .name = "pcie2ar",
+ .bpmp_id = TEGRA_ICC_BPMP_PCIE_2,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_PCIE2,
+ .regs = {
+ .sid = {
+ .override = 0x6e0,
+ .security = 0x6e4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_PCIE2AW,
+ .name = "pcie2aw",
+ .bpmp_id = TEGRA_ICC_BPMP_PCIE_2,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_PCIE2,
+ .regs = {
+ .sid = {
+ .override = 0x6e8,
+ .security = 0x6ec,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_PCIE3R,
+ .name = "pcie3r",
+ .bpmp_id = TEGRA_ICC_BPMP_PCIE_3,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_PCIE3,
+ .regs = {
+ .sid = {
+ .override = 0x6f0,
+ .security = 0x6f4,
+ },
+ },
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_PCIE3W,
+ .name = "pcie3w",
+ .bpmp_id = TEGRA_ICC_BPMP_PCIE_3,
+ .type = TEGRA_ICC_NISO,
+ .sid = TEGRA238_SID_PCIE3,
+ .regs = {
+ .sid = {
+ .override = 0x6f8,
+ .security = 0x6fc,
+ },
+ },
+ }, {
+ .id = TEGRA_ICC_MC_CPU_CLUSTER0,
+ .name = "sw_cluster0",
+ .bpmp_id = TEGRA_ICC_BPMP_CPU_CLUSTER0,
+ .type = TEGRA_ICC_NISO,
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_NVL1R,
+ .name = "nvl1r",
+ .bpmp_id = TEGRA_ICC_BPMP_GPU,
+ .type = TEGRA_ICC_NISO,
+ }, {
+ .id = TEGRA234_MEMORY_CLIENT_NVL1W,
+ .name = "nvl1w",
+ .bpmp_id = TEGRA_ICC_BPMP_GPU,
+ .type = TEGRA_ICC_NISO,
+ }
+};
+
+static const struct tegra_mc_intmask tegra238_mc_intmasks[] = {
+ {
+ .reg = MC_INTMASK,
+ .mask = MC_INT_DECERR_ROUTE_SANITY | MC_INT_DECERR_GENERALIZED_CARVEOUT |
+ MC_INT_DECERR_MTS | MC_INT_SECERR_SEC | MC_INT_DECERR_VPR |
+ MC_INT_SECURITY_VIOLATION | MC_INT_DECERR_EMEM,
+ },
+};
+
+const struct tegra_mc_soc tegra238_mc_soc = {
+ .num_clients = ARRAY_SIZE(tegra238_mc_clients),
+ .clients = tegra238_mc_clients,
+ .num_address_bits = 40,
+ .num_channels = 8,
+ .client_id_mask = 0x1ff,
+ .intmasks = tegra238_mc_intmasks,
+ .num_intmasks = ARRAY_SIZE(tegra238_mc_intmasks),
+ .has_addr_hi_reg = true,
+ .ops = &tegra186_mc_ops,
+ .icc_ops = &tegra234_mc_icc_ops,
+ .ch_intmask = 0x0000ff00,
+ .global_intstatus_channel_shift = 8,
+ /*
+ * Additionally, there are lite carveouts but those are not currently
+ * supported.
+ */
+ .num_carveouts = 32,
+ .regs = &tegra20_mc_regs,
+ .handle_irq = tegra30_mc_irq_handlers,
+ .num_interrupts = ARRAY_SIZE(tegra30_mc_irq_handlers),
+ .mc_addr_hi_mask = 0x3,
+ .mc_err_status_type_mask = (0x7 << 28),
+};
--
2.50.1
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: memory: tegra: Add nvidia,tegra238-mc compatible
From: Ashish Mhetre @ 2026-03-31 11:23 UTC (permalink / raw)
To: krzk, robh, conor+dt, =thierry.reding, jonathanh, sumitg
Cc: linux-kernel, devicetree, linux-tegra, Ashish Mhetre
In-Reply-To: <20260331112347.3897841-1-amhetre@nvidia.com>
Document the device tree binding for the Tegra238 memory controller.
Tegra238 has 8 memory controller channels plus broadcast and stream-id
registers.
Add the stream ID header (nvidia,tegra238-mc.h) defining ISO and NISO
stream IDs for SMMU configuration.
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
.../nvidia,tegra186-mc.yaml | 31 ++++++++
.../dt-bindings/memory/nvidia,tegra238-mc.h | 74 +++++++++++++++++++
2 files changed, 105 insertions(+)
create mode 100644 include/dt-bindings/memory/nvidia,tegra238-mc.h
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
index 7b03b589168b..e008cb1ccd28 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
@@ -32,6 +32,7 @@ properties:
- nvidia,tegra186-mc
- nvidia,tegra194-mc
- nvidia,tegra234-mc
+ - nvidia,tegra238-mc
- nvidia,tegra264-mc
reg:
@@ -266,6 +267,36 @@ allOf:
interrupt-names: false
+ - if:
+ properties:
+ compatible:
+ const: nvidia,tegra238-mc
+ then:
+ properties:
+ reg:
+ minItems: 10
+ maxItems: 10
+ description: 8 memory controller channels, 1 broadcast, and 1 for stream-id registers
+
+ reg-names:
+ items:
+ - const: sid
+ - const: broadcast
+ - const: ch0
+ - const: ch1
+ - const: ch2
+ - const: ch3
+ - const: ch4
+ - const: ch5
+ - const: ch6
+ - const: ch7
+
+ interrupts:
+ items:
+ - description: MC general interrupt
+
+ interrupt-names: false
+
- if:
properties:
compatible:
diff --git a/include/dt-bindings/memory/nvidia,tegra238-mc.h b/include/dt-bindings/memory/nvidia,tegra238-mc.h
new file mode 100644
index 000000000000..be24c0eb3f15
--- /dev/null
+++ b/include/dt-bindings/memory/nvidia,tegra238-mc.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/* Copyright (c) 2026, NVIDIA CORPORATION. All rights reserved. */
+
+#ifndef DT_BINDINGS_MEMORY_TEGRA238_MC_H
+#define DT_BINDINGS_MEMORY_TEGRA238_MC_H
+
+/* special clients */
+#define TEGRA238_SID_INVALID 0x0
+#define TEGRA238_SID_PASSTHROUGH 0x7f
+
+/* ISO stream IDs */
+#define TEGRA238_SID_ISO_NVDISPLAY 0x1
+#define TEGRA238_SID_ISO_APE0 0x2
+#define TEGRA238_SID_ISO_APE1 0x3
+
+/* NISO stream IDs */
+#define TEGRA238_SID_AON 0x1
+#define TEGRA238_SID_BPMP 0x2
+#define TEGRA238_SID_ETR 0x3
+#define TEGRA238_SID_FDE 0x4
+#define TEGRA238_SID_HC 0x5
+#define TEGRA238_SID_HDA 0x6
+#define TEGRA238_SID_NVDEC 0x7
+#define TEGRA238_SID_NVDISPLAY 0x8
+#define TEGRA238_SID_NVENC 0x9
+#define TEGRA238_SID_OFA 0xa
+#define TEGRA238_SID_PCIE0 0xb
+#define TEGRA238_SID_PCIE1 0xc
+#define TEGRA238_SID_PCIE2 0xd
+#define TEGRA238_SID_PCIE3 0xe
+#define TEGRA238_SID_HWMP_PMA 0xf
+#define TEGRA238_SID_PSC 0x10
+#define TEGRA238_SID_SDMMC1A 0x11
+#define TEGRA238_SID_SDMMC4A 0x12
+#define TEGRA238_SID_SES_SE0 0x13
+#define TEGRA238_SID_SES_SE1 0x14
+#define TEGRA238_SID_SES_SE2 0x15
+#define TEGRA238_SID_SEU1_SE0 0x16
+#define TEGRA238_SID_SEU1_SE1 0x17
+#define TEGRA238_SID_SEU1_SE2 0x18
+#define TEGRA238_SID_TSEC 0x19
+#define TEGRA238_SID_UFSHC 0x1a
+#define TEGRA238_SID_VIC 0x1b
+#define TEGRA238_SID_XUSB_HOST 0x1c
+#define TEGRA238_SID_XUSB_DEV 0x1d
+#define TEGRA238_SID_GPCDMA_0 0x1e
+#define TEGRA238_SID_SMMU_TEST 0x1f
+
+/* Host1x virtualization clients. */
+#define TEGRA238_SID_HOST1X_CTX0 0x20
+#define TEGRA238_SID_HOST1X_CTX1 0x21
+#define TEGRA238_SID_HOST1X_CTX2 0x22
+#define TEGRA238_SID_HOST1X_CTX3 0x23
+#define TEGRA238_SID_HOST1X_CTX4 0x24
+#define TEGRA238_SID_HOST1X_CTX5 0x25
+#define TEGRA238_SID_HOST1X_CTX6 0x26
+#define TEGRA238_SID_HOST1X_CTX7 0x27
+
+#define TEGRA238_SID_XUSB_VF0 0x28
+#define TEGRA238_SID_XUSB_VF1 0x29
+#define TEGRA238_SID_XUSB_VF2 0x2a
+#define TEGRA238_SID_XUSB_VF3 0x2b
+
+/* Host1x command buffers */
+#define TEGRA238_SID_HC_VM0 0x2c
+#define TEGRA238_SID_HC_VM1 0x2d
+#define TEGRA238_SID_HC_VM2 0x2e
+#define TEGRA238_SID_HC_VM3 0x2f
+#define TEGRA238_SID_HC_VM4 0x30
+#define TEGRA238_SID_HC_VM5 0x31
+#define TEGRA238_SID_HC_VM6 0x32
+#define TEGRA238_SID_HC_VM7 0x33
+
+#endif
--
2.50.1
^ permalink raw reply related
* [PATCH 0/2] memory: tegra: Add Tegra238 memory controller support
From: Ashish Mhetre @ 2026-03-31 11:23 UTC (permalink / raw)
To: krzk, robh, conor+dt, =thierry.reding, jonathanh, sumitg
Cc: linux-kernel, devicetree, linux-tegra, Ashish Mhetre
This series adds Memory Controller driver support for the Tegra238 SoC.
Tegra238 is similar to Tegra234 but with a reduced memory controller
configuration featuring 8 channels instead of 16. The driver reuses
Tegra234 memory client IDs and ICC operations, with Tegra238-specific
stream IDs for SMMU configuration.
Ashish Mhetre (2):
memory: tegra: Add T238 MC support
dt-bindings: memory: tegra: Add nvidia,tegra238-mc compatible
.../nvidia,tegra186-mc.yaml | 31 ++
drivers/memory/tegra/Makefile | 1 +
drivers/memory/tegra/mc.c | 3 +
drivers/memory/tegra/mc.h | 6 +
drivers/memory/tegra/tegra234.c | 2 +-
drivers/memory/tegra/tegra238.c | 395 ++++++++++++++++++
.../dt-bindings/memory/nvidia,tegra238-mc.h | 74 ++++
7 files changed, 511 insertions(+), 1 deletion(-)
create mode 100644 drivers/memory/tegra/tegra238.c
create mode 100644 include/dt-bindings/memory/nvidia,tegra238-mc.h
--
2.50.1
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Bryan O'Donoghue @ 2026-03-31 11:19 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Jonathan Marek, Ulf Hansson, Rafael J. Wysocki,
Vikash Garodia, Dikshita Agarwal, Mauro Carvalho Chehab,
Stanimir Varbanov, Abhinav Kumar, Hans Verkuil, Stefan Schmidt,
Konrad Dybcio, Bryan O'Donoghue, Dikshita Agarwal
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm,
linux-media, Mauro Carvalho Chehab
In-Reply-To: <20260209-iris-venus-fix-sm8250-v5-2-0a22365d3585@oss.qualcomm.com>
On 09/02/2026 01:32, Dmitry Baryshkov wrote:
> On SM8250 most of the video clocks are powered by the MMCX domain, while
> the PLL is powered on by the MX domain. Extend the driver to support
> scaling both power domains, while keeping compatibility with the
> existing DTs, which define only the MX domain.
>
> Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
> drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> index df8e6bf9430e..aa71f7f53ee3 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
>
> static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
>
> -static const char * const sm8250_opp_pd_table[] = { "mx" };
> +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
>
> static const struct platform_clk_data sm8250_clk_table[] = {
> {IRIS_AXI_CLK, "iface" },
> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> index 7b612ad37e4f..74ec81e3d622 100644
> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
> return ret;
>
> ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
> + /* backwards compatibility for incomplete ABI SM8250 */
> + if (ret == -ENODEV &&
> + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
> + iris_opp_pd_data.num_pd_names--;
> + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
ci is choking on this.
=>
drivers/media/platform/qcom/venus/pm_helpers.c: In function
‘vcodec_domains_get’:
drivers/media/platform/qcom/venus/pm_helpers.c:910:41: error: decrement
of read-only member ‘num_pd_names’
910 | opp_pd_data.num_pd_names--;
| ^~
=>
include/linux/pm_domain.h
struct dev_pm_domain_attach_data {
const char * const *pd_names;
const u32 num_pd_names;
const u32 pd_flags;
};
=>
struct dev_pm_domain_attach_data opp_pd_data = {
.pd_names = res->opp_pmdomain,
.num_pd_names = res->opp_pmdomain_num,
.pd_flags = PD_FLAG_DEV_LINK_ON | PD_FLAG_REQUIRED_OPP,
};
---
bod
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: remoteproc: qcom: Drop types for firmware-name
From: Shawn Guo @ 2026-03-31 11:16 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring
Cc: Mathieu Poirier, Krzysztof Kozlowski, Conor Dooley,
Stephan Gerhold, Sibi Sankar, Bartosz Golaszewski,
Manivannan Sadhasivam, linux-arm-msm, linux-remoteproc,
devicetree, linux-kernel
In-Reply-To: <20260309123357.1911586-1-shengchao.guo@oss.qualcomm.com>
On Mon, Mar 09, 2026 at 08:33:57PM +0800, Shawn Guo wrote:
> The type of firmware-name is already defined by core schemas. Drop it
> from individual bindings that have either a redundant definition or
> an override as string type. For the later cases, constrain the number
> of expected firmware names to 1.
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> Changes in v2:
> - Add constraint of maxItems 1 for string type removal (Thanks to Krzysztof!)
> - Link to v1: https://lore.kernel.org/all/20260306140306.1328719-1-shengchao.guo@oss.qualcomm.com/
Hi Bjorn,
Did you get a chance to look at it, or is there anything I should do
on my end?
Shawn
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: eliza-mtp: Enable USB and ADSP support
From: Konrad Dybcio @ 2026-03-31 11:12 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331-eliza-adsp-usb-v1-3-d8a251be20c3@oss.qualcomm.com>
On 3/31/26 12:37 PM, Abel Vesa wrote:
> The Eliza MTP features a single USB Type-C port. Its USB 2.0 lines are
> routed through an eUSB2 repeater provided by the PM7750BA PMIC.
>
> Describe the port and repeater, and enable the USB controller and PHYs.
>
> Also specify the ADSP firmware and enable the remoteproc.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
[...]
> +&usb {
> + dr_mode = "otg";
That's the default if dr_mode is absent, drop
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v5 1/9] dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
From: Krzysztof Kozlowski @ 2026-03-31 11:11 UTC (permalink / raw)
To: Ulf Hansson
Cc: Iker Pedrosa, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel
In-Reply-To: <CAPDyKFrafqhNbetL5kOzAFO526yUrJWa6mS_FPX-cw9bj2Mg4Q@mail.gmail.com>
On 31/03/2026 12:58, Ulf Hansson wrote:
>>> + - default
>>> + - state_uhs
>>
>> Instead: uhs
>
> While I agree that "uhs" would be better, we have tried to stick with
> "state_uhs" for legacy and consistency reasons with other mmc
> controllers.
>
> No strong opinion though, what do you think?
>
I missed that it is already present in other places. Is the name coming
from any other referenced schema like mmc-controller? Does the existing
common driver code expect state_uhs?
If yes, then go with state_uhs, if not then let's switch to new name.
Old conventions in the bindings can be changed, we already do many
things differently than 10 years ago (e.g. no underscores in node and
property names).
But followup question - the binding is called sdhci, so maybe sdhci
common schema should be referenced?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: sram: document glymur as compatible
From: Ananthu C V @ 2026-03-31 11:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <t5vbe36b3i2lx4ktrw5bosjtldgpmep4ueqkx5b5saoc7a3dm4@ywsv5rrcefew>
On Sun, Mar 29, 2026 at 02:05:23PM +0300, Dmitry Baryshkov wrote:
> On Fri, Mar 27, 2026 at 03:24:35AM -0700, Ananthu C V wrote:
> > Add compatible for Qualcomm's glymur IMEM, a block of sram which
> > can fall back to mmio-sram.
> >
> > Acked-by: Rob Herring (Arm) <robh@kernel.org>
> > Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > ---
> > Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
> > index c451140962c8..bd62711dc630 100644
> > --- a/Documentation/devicetree/bindings/sram/sram.yaml
> > +++ b/Documentation/devicetree/bindings/sram/sram.yaml
> > @@ -34,6 +34,7 @@ properties:
> > - nvidia,tegra186-sysram
> > - nvidia,tegra194-sysram
> > - nvidia,tegra234-sysram
> > + - qcom,glymur-imem
>
> Is it different from the Kaanapali one?
No, it is the same as the kaanapali imem.
> > - qcom,kaanapali-imem
> > - qcom,rpm-msg-ram
> > - rockchip,rk3288-pmu-sram
> >
> > --
> > 2.43.0
> >
>
> --
> With best wishes
> Dmitry
Best,
Ananthu
^ permalink raw reply
* RE: [PATCH v2 1/3] dt-bindings: watchdog: renesas,r9a09g057-wdt: Rework example
From: Fabrizio Castro @ 2026-03-31 11:09 UTC (permalink / raw)
To: Wim Van Sebroeck, linux-watchdog@vger.kernel.org,
Krzysztof Kozlowski, Conor Dooley, Rob Herring, Guenter Roeck
Cc: Michael Turquette, Stephen Boyd, magnus.damm,
Prabhakar Mahadev Lad, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, Biju Das, geert
In-Reply-To: <CAMuHMdXtrAwAtqNPqwq5qKHo4SKQqFoGSE7qPnFRD4rbKkPfaA@mail.gmail.com>
Dear All,
This is a gentle reminder that this patch is waiting for someone
to kindly pick it up.
Kind regards,
Fab
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 03 March 2026 13:17
> To: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> Cc: Rob Herring <robh@kernel.org>; Guenter Roeck <linux@roeck-us.net>; Michael Turquette
> <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; Wim Van Sebroeck <wim@linux-watchdog.org>;
> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; magnus.damm
> <magnus.damm@gmail.com>; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>; linux-
> watchdog@vger.kernel.org; linux-kernel@vger.kernel.org; linux-renesas-soc@vger.kernel.org;
> devicetree@vger.kernel.org; linux-clk@vger.kernel.org; Biju Das <biju.das.jz@bp.renesas.com>
> Subject: Re: [PATCH v2 1/3] dt-bindings: watchdog: renesas,r9a09g057-wdt: Rework example
>
> On Tue, 3 Feb 2026 at 13:43, Fabrizio Castro
> <fabrizio.castro.jz@renesas.com> wrote:
> > When the bindings for the Renesas RZ/V2H(P) SoC were factored
> > out IP WDT0 was selected for the example, however the HW user
> > manual states that only IP WDT1 can be used by Linux.
> >
> > This commit is part of a series that removes WDT{0,2,3} support
> > from the kernel, therefore the example from the bindings has
> > lost its meaning.
> >
> > Update the example accordingly.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> 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 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms
From: Sebastian Reichel @ 2026-03-31 11:01 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Damon Ding,
Dmitry Baryshkov, Alexey Charkov, dri-devel, linux-rockchip,
linux-kernel, devicetree, kernel
In-Reply-To: <1801CF6805B8DD32+0afb49ab-a03c-40f0-92bd-d0b332f8f28e@airkyi.com>
[-- Attachment #1: Type: text/plain, Size: 4631 bytes --]
Hi,
On Tue, Mar 31, 2026 at 11:16:26AM +0800, Chaoyi Chen wrote:
> On 3/31/2026 10:09 AM, Sebastian Reichel wrote:
> > On Tue, Mar 31, 2026 at 09:18:32AM +0800, Chaoyi Chen wrote:
> >> On 3/30/2026 7:50 PM, Sebastian Reichel wrote:
> >>> On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote:
> >>>>> There are two parts, which possibly need some discussion:
> >>>>>
> >>>>> 1. I added a dedicated bridge callback for out-of-band hotplug events,
> >>>>> which is separate from the hotplug_notify. I have a feeling, that
> >>>>> there might be a better solution, but haven't found it.
> >>>>
> >>>> Could you explain what an out-of-band hotplug event is?
> >>>>
> >>>> Can't the drivers/usb/typec/altmodes/displayport.c respond to these
> >>>> hot-plug events? Thank you.
> >>>
> >>> That is what generates the out-of-band hotplug event in the first
> >>> place via drm_connector_oob_hotplug_event(). The oob in that call
> >>> means out of band.
> >>>
> >>> If you look at that function it calls oob_hotplug_event() callback
> >>> on the DRM connector, which is then implemented by
> >>> drm_bridge_connector_oob_hotplug_event(). This function calls uses
> >>> the normal hpd handling (shared by in-band and out-of-band) and I'm
> >>> patching it, so that the bridges are aware of hpd explicitly being
> >>> provided out-of-band.
> >>>
> >>
> >> Ah, I'm actually more concerned with the specific types of events.
> >> For example, the "explicitly" provided HPD you mentioned here.
> >> Isn't drm_connector_oob_hotplug_event able to provide those?
> >>
> >> I assume you’re looking for an oob event that is propagated along the
> >> bridge chain, rather than at the connector. Is that so? Thank you.
> >
> > The connector has a dedicated hotplug oob event callback, but I obviously
> > need the event on the bridge, since the DP controller is implemented as
> > bridge. The existing infrastructure propages it down to the bridge chain
> > via drm_bridge_hpd_notify(), which can be received by the DP controller
> > via the .hpd_notify callback in struct drm_bridge_funcs.
> >
> > The problem is, that this receives events for in-band AND
> > out-of-band hotplug events. That's why I added a new bridge
> > callback, which hooks into the existing framework, but only delivers
> > out-of-band events and no in-band events.
> >
>
> How to distinguish between in-band and out-of-band events? In your patch4:
>
> @@ -180,6 +180,12 @@ static void drm_bridge_connector_oob_hotplug_event(struct drm_connector *connect
> struct drm_bridge_connector *bridge_connector =
> to_drm_bridge_connector(connector);
>
> + /* Notify all bridges in the pipeline of hotplug events. */
> + drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
> + if (bridge->funcs->oob_notify)
> + bridge->funcs->oob_notify(bridge, connector, status);
> + }
> +
this is the new handler that will only get OOB events, since it is
only called from the connector's oob hotplug event function.
> drm_bridge_connector_handle_hpd(bridge_connector, status);
this is the existing handler, which is not modified and keeps its
behaviour of receiving both hpd event types just as before.
> Here, drm_bridge_connector_handle_hpd() will eventually call:
>
> drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
> if (bridge->funcs->hpd_notify)
> bridge->funcs->hpd_notify(bridge, connector, status);
> }
>
> Therefore, for the bridge chain, you will call hpd_notify and
> oob_notify separately.
Correct, I keep existing functionality. Apparently it works for
everyone else.
> This looks redundant, how do you distinguish between them?
hpd_notify can be used in the same way as before. It is useful in
case the bridge driver does not care about the source of the hpd
event. In case of the Rockchip Synopsys DP bridge, .hpd_notify is
not bound and only .oob_notify is used, so it only receives the OOB
events. It's not necessary to receive the in-band events at all,
since those are generated by the driver itself anyways.
> > The problem with receiving in-band in addition to out-of-band is
> > that the out-of-band signal should set the hotplug pin accordingly,
> > but the in-band detection also checks the actual DP link. If the OOB
> > hotplug signal says "nothing plugged", the hotplug pin should be
> > forced off, but if the DP link detection fails, the hotplug pin
> > should not be force disabled, as that makes any further detection
> > tries useless.
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/9] dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
From: Ulf Hansson @ 2026-03-31 10:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Iker Pedrosa, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel
In-Reply-To: <20260331-eager-kind-civet-62f60a@quoll>
On Tue, 31 Mar 2026 at 08:48, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Mon, Mar 30, 2026 at 10:38:02AM +0200, Iker Pedrosa wrote:
> > Document pinctrl properties to support voltage-dependent pin
> > configuration switching for UHS-I SD card modes.
> >
> > Add optional pinctrl-names property with two states:
> > - "default": For 3.3V operation with standard drive strength
> > - "state_uhs": For 1.8V operation with optimized drive strength
> >
> > These pinctrl states allow the SDHCI driver to coordinate voltage
> > switching with pin configuration changes, ensuring proper signal
> > integrity during UHS-I mode transitions.
> >
> > Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
> > ---
> > .../devicetree/bindings/mmc/spacemit,sdhci.yaml | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> > index 9a055d963a7f0cdba4741c1e3e7269688dcd5f45..201ab97f0e88376a4680dcca7917e8b3172bd84a 100644
> > --- a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> > @@ -44,6 +44,20 @@ properties:
> > - const: axi
> > - const: sdh
> >
> > + pinctrl-names:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + enum:
>
> No, that's not enum but list. Look here:
>
> > + - default
> > + - state_uhs
>
> Instead: uhs
While I agree that "uhs" would be better, we have tried to stick with
"state_uhs" for legacy and consistency reasons with other mmc
controllers.
No strong opinion though, what do you think?
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 2/3] clk: qcom: Add support for GXCLK for Milos
From: Jagadeesh Kona @ 2026-03-31 10:57 UTC (permalink / raw)
To: Alexander Koskovich, Luca Weiss
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <gwVAH2mJerU4dBInw8pKmOs5aQK55Q7W6q_UQAlLFCsEgX6eyvSgXAWbNNMqAX4WmPlYCKUSMhfkr5Jry4Ps5EqnxYZqEEDd3Whwv7ZXGlc=@pm.me>
On 3/31/2026 8:07 AM, Alexander Koskovich wrote:
> On Friday, March 6th, 2026 at 8:56 AM, Luca Weiss <luca.weiss@fairphone.com> wrote:
>
>> GXCLKCTL (Graphics GX Clock Controller) is a block dedicated to managing
>> clocks for the GPU subsystem on GX power domain. The GX clock controller
>> driver manages only the GX GDSC and the rest of the resources of the
>> controller are managed by the firmware.
>>
>> We can use the existing kaanapali driver for Milos as well since the
>> GX_CLKCTL_GX_GDSC supported by the Linux driver requires the same
>> configuration.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> drivers/clk/qcom/Makefile | 2 +-
>> drivers/clk/qcom/gxclkctl-kaanapali.c | 1 +
>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
>> index 90ea21c3b7cf..155830140d26 100644
>> --- a/drivers/clk/qcom/Makefile
>> +++ b/drivers/clk/qcom/Makefile
>> @@ -182,7 +182,7 @@ obj-$(CONFIG_SM_GPUCC_8350) += gpucc-sm8350.o
>> obj-$(CONFIG_SM_GPUCC_8450) += gpucc-sm8450.o
>> obj-$(CONFIG_SM_GPUCC_8550) += gpucc-sm8550.o
>> obj-$(CONFIG_SM_GPUCC_8650) += gpucc-sm8650.o
>> -obj-$(CONFIG_SM_GPUCC_MILOS) += gpucc-milos.o
>> +obj-$(CONFIG_SM_GPUCC_MILOS) += gpucc-milos.o gxclkctl-kaanapali.o
>> obj-$(CONFIG_SM_LPASSCC_6115) += lpasscc-sm6115.o
>> obj-$(CONFIG_SM_TCSRCC_8550) += tcsrcc-sm8550.o
>> obj-$(CONFIG_SM_TCSRCC_8650) += tcsrcc-sm8650.o
>> diff --git a/drivers/clk/qcom/gxclkctl-kaanapali.c b/drivers/clk/qcom/gxclkctl-kaanapali.c
>> index 3ee512f34967..d3899420d6f2 100644
>> --- a/drivers/clk/qcom/gxclkctl-kaanapali.c
>> +++ b/drivers/clk/qcom/gxclkctl-kaanapali.c
>> @@ -54,6 +54,7 @@ static const struct qcom_cc_desc gx_clkctl_kaanapali_desc = {
>> static const struct of_device_id gx_clkctl_kaanapali_match_table[] = {
>> { .compatible = "qcom,glymur-gxclkctl" },
>> { .compatible = "qcom,kaanapali-gxclkctl" },
>> + { .compatible = "qcom,milos-gxclkctl" },
>> { }
>> };
>> MODULE_DEVICE_TABLE(of, gx_clkctl_kaanapali_match_table);
>>
>> --
>> 2.53.0
>>
>
> Was running into gx_clkctl_gx_gdsc being stuck on when GPU was doing runtime pm
> and it seems like this GDSC requires GPU_CC_GX_AHB_FF_CLK to be enabled. Though
> it is already in gpu_cc_milos_critical_cbcrs, the GMU firmware appears to be
> disabling it.
>
> Relevant downstream change:
> https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/3c1f31518edb7b094b9b9285287ba49a5c9196d8
>
Hi Alexander,
This change was introduced as a temporary placeholder specific to downstream GPU SW & GPUCC code,
to unblock the gx gdsc warnings observed during system resume. But it is not the final
implementation and change was reverted later in below commit:
https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/11bd8d8d6f654cf156bb4fbbfe6587e0c41adc2b
But you are right, gpu_cc_gx_ahb_ff_clk is indeed required for GX GDSC register access. And the
actual requirement is linux GMU driver should disable the GX GDSC only in GMU recovery use case
at which point the necessary clock will already be enabled by firmware. In all other cases, the
GX GDSC should never be enabled/disabled from linux.
In the upstream implementation of GMU driver, the GX GDSC is being enabled/disabled in every runtime
resume/suspend of GMU driver which is leading to these GX GDSC warnings. Milos GPU architecture is
similar to that of Pakala and similar GX GDSC warnings were reported on Pakala already[1].
Discussions are in progress with internal GPU SW team to see if GX GDSC can be handled gracefully
only during GMU recovery use case and not control it in other scenarios, to avoid this issue and
without impacting any other GPU use cases.
[1]: https://lore.kernel.org/all/CAH2e8h4R-nF+eV+OnkSySKSY5_H-V8Ndyfhac3=VNQ-bMaBeFg@mail.gmail.com/
Thanks,
Jagadeesh
>>
>>
>
^ permalink raw reply
* Re: [PATCH v2 06/10] drm/bridge: dw-hdmi: warn on unsupported attach combination
From: Damon Ding @ 2026-03-31 7:25 UTC (permalink / raw)
To: Luca Ceresoli, 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: 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
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-6-c7f2af536a24@bootlin.com>
On 3/31/2026 3:25 AM, Luca Ceresoli wrote:
> 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);
>
Tested-by: Damon Ding <damon.ding@rock-chips.com> (on rk3399)
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Luca Ceresoli @ 2026-03-31 10:54 UTC (permalink / raw)
To: Liu Ying, 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, Rob Herring, Saravana Kannan
Cc: 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, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <9a6e74ed-d4ab-4f11-ab17-25e1a2b64b2d@nxp.com>
Hello Liu,
On Tue Mar 31, 2026 at 5:03 AM CEST, Liu Ying wrote:
> Hi Luca,
>
> On Mon, Mar 30, 2026 at 05:47:23PM +0200, Luca Ceresoli wrote:
>> Hello Liu,
>>
>> On Mon Mar 30, 2026 at 5:02 AM CEST, Liu Ying wrote:
>
> [...]
>
>>>>>> + fixup-hdmi-connector {
>>>>>> + compatible = "hdmi-connector";
>>>>>> + label = "HDMI";
>>>>>> + type = "a";
>>>>>
>>>>> What if a board uses another type?
>>>>
>>>> For boards affected by this patch, currently the connector is created by
>>>> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
>>>> difference.
>>>
>>> Yes, that's from driver's PoV. However, userspace may get the type
>>> from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
>>> to do something.
>>
>> I'd say this is incorrect, the device tree is not an API for that. The
>> connector type might be known to the driver by other means (ACPI, DP MST,
>> whatever). So I think this is a non-problem.
>
> I just feel that it's not great to report potentially wrong type to users
> through the above sys node ...
>
>>
>> If userspace needs to know the connector type, that should come from the
>> ioctl (DRM_IOCTL_MODE_GETCONNECTOR perhaps).
>>
>>> Maybe, that's trivial.
>>
>> Not sure I got what you mean here, sorry. What are you referring to?
>
> ... with the above potentially wrong type being said, I think maybe this
> drawback is not a big deal and could be ignored. Sorry for not being
> clear in my last reply.
Ah, clear now. No problem!
>>>> Boards with a different connector should describe the connector in the
>>>> device tree, if they need to instantiate the exact type.
>>
>> I think this is the only valid solution. It's very easy to do, nothing new
>> to invent.
>>
>> Maybe on top of that we could add a warning when the overlay is applied,
>> e.g. "imx8mp-hdmi-tx used without a connector described in device tree;
>> adding a type A connector as a fallback; please add a valid description to
>> your device tree".
>
> I'd say this doesn't sound a bad idea but I hope the message is clear and
> short.
What about:
Connector description not found in device tree, please add one. Falling back to Type A.
>> Maybe pointing to a TODO entry in the documentation.
>
> To parameterize the HDMI connector type? If so, I'm okay with that.
I was meaning a TODO entry to suggest people to add a connector description
to the dts. E.g., expanding on the above suggested warning:
Connector description not found in device tree, please add one. See https://docs.kernel.org/gpu/todo.html#<...>
And of course adding a TODO entry describing what one needs to do (add an
hdmi-connector node and link it to port@1 of the hdmi-tx).
The drawback of the TODO is that items in todo.rst are supposed to be
removed eventually when done in the code, but this one cannot be removed
until some kernels printing the above logging message will be around,
i.e. potentially for decades.
So maybe the simplest solution is just the first warning message + a
comment in the code right before the warning line, so it easily found with
grep or a web search by who sees the warning.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH V3 1/3] net: stmmac: Fix PTP ref clock for Tegra234
From: Jon Hunter @ 2026-03-31 10:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, netdev, devicetree, linux-tegra
In-Reply-To: <5b3eaba5-eba2-43f9-8ef5-d305ca50ddf0@kernel.org>
On 31/03/2026 11:18, Krzysztof Kozlowski wrote:
> On 31/03/2026 12:14, Jon Hunter wrote:
>>
>> On 26/03/2026 08:32, Krzysztof Kozlowski wrote:
>>
>> ...
>>
>>>> @@ -257,9 +258,23 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
>>>> if (!mgbe->clks)
>>>> return -ENOMEM;
>>>>
>>>> - for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++)
>>>> + /*
>>>> + * Older device-trees use 'ptp-ref' rather than 'ptp_ref'.
>>>> + * Fall back to the legacy name when 'ptp_ref' is absent.
>>>> + */
>>>> + use_legacy_ptp = of_property_match_string(pdev->dev.of_node,
>>>> + "clock-names", "ptp_ref") < 0;
>>>> +
>>>> + for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++) {
>>>> mgbe->clks[i].id = mgbe_clks[i];
>>>>
>>>> + if (use_legacy_ptp && !strcmp(mgbe_clks[i], "ptp_ref")) {
>>>
>>> Why index 0 is not valid? And why -EINVAL would be considered as legacy
>>> clock present?
>>
>> Index 0 is valid. However, yes I guess that treating an -EINVAL from
>> of_property_match_string() is not correct. I will switch the logic to be ...
>>
>> use_legacy_ptp = of_property_match_string(pdev->dev.of_node,
>> "clock-names", "ptp-ref") >= 0;
>
> No, apologies, I think my comment was not correct and your reply made me
> rethink. I missed final "< 0" in of_property_match_string().
>
> So the code is good, you do not store index in 'use_legacy_ptp', but the
> error return value.
>
> Can you however make it more obvious code, so something like:
>
> if (of_property_match_string...))
> use_legacy_ptp = true;;
Yes I can do that. Before I was avoiding the need to pre-initialise the
variable, but I am happy either way to get this fixed!
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: soc: renesas: Document MFIS IP core
From: Wolfram Sang @ 2026-03-31 10:45 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Krzysztof Kozlowski, Marek Vasut, Wolfram Sang,
Geert Uytterhoeven, Magnus Damm, Rob Herring, Conor Dooley,
devicetree
In-Reply-To: <20260331104527.29170-1-wsa+renesas@sang-engineering.com>
Document the Renesas Multifunctional Interface (MFIS) as found on the
Renesas R-Car X5H (r8a78000) SoC. MFIS includes features like Mailbox/HW
Spinlock/Product Register/Error Injection/Error Detection and the likes.
Family-compatible values are not introduced here because MFIS is usually
very different per SoC.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Changes since v2:
* added interrupt constraints
* fixed whitespaces in example (Thanks, Krzysztof, for both!)
.../soc/renesas/renesas,r8a78000-mfis.yaml | 191 ++++++++++++++++++
.../dt-bindings/soc/renesas,r8a78000-mfis.h | 28 +++
2 files changed, 219 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
create mode 100644 include/dt-bindings/soc/renesas,r8a78000-mfis.h
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
new file mode 100644
index 000000000000..7ee3a82053d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
@@ -0,0 +1,191 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/renesas,r8a78000-mfis.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas MFIS (Multifunctional Interface) controller
+
+maintainers:
+ - Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+description:
+ The Renesas Multifunctional Interface (MFIS) provides various functionality
+ like mailboxes, hardware spinlocks, product identification, error injection,
+ error detection and such. Parts of it can be used for communication between
+ different CPU cores. Those cores can be in various domains like AP, RT, or
+ SCP. Often multiple domain-specific MFIS instances exist in one SoC.
+
+properties:
+ compatible:
+ enum:
+ - renesas,r8a78000-mfis # R-Car X5H (AP<->AP, with PRR)
+ - renesas,r8a78000-mfis-scp # R-Car X5H (AP<->SCP, without PRR)
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: common
+ - const: mboxes
+
+ interrupts:
+ minItems: 32
+ maxItems: 128
+ description:
+ The interrupts raised by the remote doorbells.
+
+ interrupt-names:
+ minItems: 32
+ maxItems: 128
+ description:
+ An interrupt name is constructed with the prefix 'ch'. Then, the
+ channel number as specified in the documentation of the SoC. Finally,
+ the letter 'i' if the interrupt is raised by the IICR register. Or 'e'
+ if it is raised by the EICR register.
+
+ "#hwlock-cells":
+ const: 1
+
+ "#mbox-cells":
+ const: 2
+ description:
+ The first cell is the channel number as specified in the documentation
+ of the SoC. The second cell may specify flags as described in the file
+ <dt-bindings/soc/renesas,r8a78000-mfis.h>.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r8a78000-mfis
+ then:
+ properties:
+ interrupts:
+ minItems: 128
+ maxItems: 128
+ interrupt-names:
+ minItems: 128
+ maxItems: 128
+ items:
+ pattern: "^ch[0-9]+[ie]$"
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r8a78000-mfis-scp
+ then:
+ properties:
+ interrupts:
+ minItems: 32
+ maxItems: 32
+ interrupt-names:
+ minItems: 32
+ maxItems: 32
+ items:
+ pattern: "^ch[0-9]+i$"
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - "#hwlock-cells"
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ system-controller@189e0000 {
+ compatible = "renesas,r8a78000-mfis";
+ reg = <0x189e0000 0x1000>, <0x18800000 0x40000>;
+ reg-names = "common", "mboxes";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ch0i", "ch0e", "ch1i", "ch1e", "ch2i", "ch2e", "ch3i", "ch3e",
+ "ch4i", "ch4e", "ch5i", "ch5e", "ch6i", "ch6e", "ch7i", "ch7e",
+ "ch8i", "ch8e", "ch9i", "ch9e", "ch10i", "ch10e", "ch11i", "ch11e",
+ "ch12i", "ch12e", "ch13i", "ch13e", "ch14i", "ch14e", "ch15i", "ch15e",
+ "ch16i", "ch16e", "ch17i", "ch17e", "ch18i", "ch18e", "ch19i", "ch19e",
+ "ch20i", "ch20e", "ch21i", "ch21e", "ch22i", "ch22e", "ch23i", "ch23e",
+ "ch24i", "ch24e", "ch25i", "ch25e", "ch26i", "ch26e", "ch27i", "ch27e",
+ "ch28i", "ch28e", "ch29i", "ch29e", "ch30i", "ch30e", "ch31i", "ch31e",
+ "ch32i", "ch32e", "ch33i", "ch33e", "ch34i", "ch34e", "ch35i", "ch35e",
+ "ch36i", "ch36e", "ch37i", "ch37e", "ch38i", "ch38e", "ch39i", "ch39e",
+ "ch40i", "ch40e", "ch41i", "ch41e", "ch42i", "ch42e", "ch43i", "ch43e",
+ "ch44i", "ch44e", "ch45i", "ch45e", "ch46i", "ch46e", "ch47i", "ch47e",
+ "ch48i", "ch48e", "ch49i", "ch49e", "ch50i", "ch50e", "ch51i", "ch51e",
+ "ch52i", "ch52e", "ch53i", "ch53e", "ch54i", "ch54e", "ch55i", "ch55e",
+ "ch56i", "ch56e", "ch57i", "ch57e", "ch58i", "ch58e", "ch59i", "ch59e",
+ "ch60i", "ch60e", "ch61i", "ch61e", "ch62i", "ch62e", "ch63i", "ch63e";
+ #hwlock-cells = <1>;
+ #mbox-cells = <2>;
+ };
diff --git a/include/dt-bindings/soc/renesas,r8a78000-mfis.h b/include/dt-bindings/soc/renesas,r8a78000-mfis.h
new file mode 100644
index 000000000000..52e17fea1a03
--- /dev/null
+++ b/include/dt-bindings/soc/renesas,r8a78000-mfis.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+#ifndef _DT_BINDINGS_SOC_RENESAS_R8A78000_MFIS_H
+#define _DT_BINDINGS_SOC_RENESAS_R8A78000_MFIS_H
+
+/*
+ * Constants for the second mbox-cell of the Renesas MFIS IP core. To be treated
+ * as bit flags which can be ORed.
+ */
+
+/*
+ * MFIS HW design before r8a78001 requires a channel to be marked as either
+ * TX or RX.
+ */
+#define MFIS_CHANNEL_TX (0 << 0)
+#define MFIS_CHANNEL_RX (1 << 0)
+
+/*
+ * MFIS variants before r8a78001 work with pairs of IICR and EICR registers.
+ * Usually, it is specified in the datasheets which of the two a specific core
+ * should use. Then, it does not need extra description in DT. For plain MFIS
+ * of r8a78000, this is selectable, though. According to the system design and
+ * the firmware in use, these channels need to be marked. This is not needed
+ * with other versions of the MFIS, not even with MFIS-SCP of r8a78000.
+ */
+#define MFIS_CHANNEL_IICR (0 << 1)
+#define MFIS_CHANNEL_EICR (1 << 1)
+
+#endif
--
2.51.0
^ permalink raw reply related
* [PATCH v3 0/3] soc: renesas: add MFIS driver
From: Wolfram Sang @ 2026-03-31 10:45 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Krzysztof Kozlowski, Marek Vasut, Wolfram Sang, Conor Dooley,
devicetree, Geert Uytterhoeven, Magnus Damm, Rob Herring
Changes since v2:
* added constraints and fixed whitespaces in patch 1
* use BIT macro in patch 2
* added tag to patch 2 (Thanks, Jassi!)
Renesas R-Car MFIS offers multiple features but most importantly
mailboxes and hwspinlocks. Because they share a common register space
and a common register unprotection mechanism, a single driver was chosen
to handle all dependencies. (MFD and auxiliary bus have been tried as
well, but they failed because of circular dependencies.)
In this first step, the driver implements common register access and a
mailbox controller. hwspinlock support will be added incrementally, once
the subsystem allows out-of-directory drivers (patches already under
review). This driver has been tested on a Renesas Ironhide board (R-Car
X5H) and is able to communicate with the SCP via mailboxes. Also, the
mailbox-test driver was used to confirm back-and-forth communication
between two application cores.
Because of its multifunctional nature, the driver lives in
drivers/soc/renesas. A branch (with some additions to enable it on R-Car
X5H) can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/x5h/mfis-single-driver
Thanks and happy hacking,
Wolfram
Wolfram Sang (3):
dt-bindings: soc: renesas: Document MFIS IP core
soc: renesas: Add Renesas R-Car MFIS driver
soc: renesas: add X5H PRR support
.../soc/renesas/renesas,r8a78000-mfis.yaml | 191 ++++++++++
drivers/soc/renesas/Kconfig | 9 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/rcar-mfis.c | 344 ++++++++++++++++++
drivers/soc/renesas/renesas-soc.c | 8 +-
.../dt-bindings/soc/renesas,r8a78000-mfis.h | 28 ++
6 files changed, 580 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
create mode 100644 drivers/soc/renesas/rcar-mfis.c
create mode 100644 include/dt-bindings/soc/renesas,r8a78000-mfis.h
--
2.51.0
^ permalink raw reply
* [PATCH 3/3] arm64: dts: qcom: eliza-mtp: Enable USB and ADSP support
From: Abel Vesa @ 2026-03-31 10:37 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
In-Reply-To: <20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com>
The Eliza MTP features a single USB Type-C port. Its USB 2.0 lines are
routed through an eUSB2 repeater provided by the PM7750BA PMIC.
Describe the port and repeater, and enable the USB controller and PHYs.
Also specify the ADSP firmware and enable the remoteproc.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/eliza-mtp.dts | 83 ++++++++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/eliza-mtp.dts b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
index 90f629800cb0..c31f00e36eee 100644
--- a/arch/arm64/boot/dts/qcom/eliza-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
@@ -6,9 +6,12 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "eliza.dtsi"
+#include "pm7550ba-eliza.dtsi"
+
/ {
model = "Qualcomm Technologies, Inc. Eliza MTP";
compatible = "qcom,eliza-mtp", "qcom,eliza";
@@ -54,6 +57,44 @@ bi_tcxo_ao_div2: bi-tcxo-ao-div2-clk {
};
};
+ pmic-glink {
+ compatible = "qcom,eliza-pmic-glink",
+ "qcom,sm8550-pmic-glink",
+ "qcom,pmic-glink";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ orientation-gpios = <&tlmm 122 GPIO_ACTIVE_HIGH>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss_in: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_out>;
+ };
+ };
+ };
+ };
+ };
+
vph_pwr: regulator-vph-pwr {
compatible = "regulator-fixed";
@@ -376,6 +417,18 @@ vreg_l7k: ldo7 {
};
};
+&pm7550ba_eusb2_repeater {
+ vdd18-supply = <&vreg_l7b>;
+ vdd3-supply = <&vreg_l17b>;
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/eliza/adsp.mbn",
+ "qcom/eliza/adsp_dtb.mbn";
+
+ status = "okay";
+};
+
&tlmm {
gpio-reserved-ranges = <20 4>, /* NFC SPI */
<111 2>, /* WCN UART1 */
@@ -405,3 +458,33 @@ &ufs_mem_phy {
status = "okay";
};
+
+&usb {
+ dr_mode = "otg";
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l3g>;
+ vdda-pll-supply = <&vreg_l7k>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss_in>;
+};
+
+&usb_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_hsphy {
+ vdd-supply = <&vreg_l2b>;
+ vdda12-supply = <&vreg_l4b>;
+
+ phys = <&pm7550ba_eusb2_repeater>;
+
+ status = "okay";
+};
--
2.48.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: qcom: Add Eliza-specific PM7750BA dtsi
From: Abel Vesa @ 2026-03-31 10:37 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
In-Reply-To: <20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com>
On Eliza, the SPMI arbiter supports multiple bus masters, requiring
explicit selection of the master for each PMIC.
The existing PM7750BA dtsi does not provide a way to describe this,
so introduce an Eliza-specific variant with the appropriate bus
configuration.
This duplication is required due to hardware differences in how the
SPMI bus is exposed on this platform.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/pm7550ba-eliza.dtsi | 69 ++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm7550ba-eliza.dtsi b/arch/arm64/boot/dts/qcom/pm7550ba-eliza.dtsi
new file mode 100644
index 000000000000..2c386f16eca4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm7550ba-eliza.dtsi
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2026 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/spmi/spmi.h>
+
+/ {
+ thermal-zones {
+ pm7550ba-thermal {
+ polling-delay-passive = <100>;
+
+ thermal-sensors = <&pm7550ba_temp_alarm>;
+
+ trips {
+ trip0 {
+ temperature = <95000>;
+ hysteresis = <0>;
+ type = "passive";
+ };
+
+ trip1 {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "hot";
+ };
+
+ trip2 {
+ temperature = <145000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ };
+};
+
+&spmi_bus0 {
+ pm7550ba: pmic@7 {
+ compatible = "qcom,pm7550ba", "qcom,spmi-pmic";
+ reg = <7 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pm7550ba_temp_alarm: temp-alarm@a00 {
+ compatible = "qcom,spmi-temp-alarm";
+ reg = <0xa00>;
+ interrupts = <0x7 0xa 0x0 IRQ_TYPE_EDGE_BOTH>;
+ #thermal-sensor-cells = <0>;
+ };
+
+ pm7550ba_gpios: gpio@8800 {
+ compatible = "qcom,pm7550ba-gpio", "qcom,spmi-gpio";
+ reg = <0x8800>;
+ gpio-controller;
+ gpio-ranges = <&pm7550ba_gpios 0 0 8>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ pm7550ba_eusb2_repeater: phy@fd00 {
+ compatible = "qcom,pm7550ba-eusb2-repeater", "qcom,pm8550b-eusb2-repeater";
+ reg = <0xfd00>;
+ #phy-cells = <0>;
+ };
+ };
+};
--
2.48.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes
From: Abel Vesa @ 2026-03-31 10:37 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
In-Reply-To: <20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com>
Describe the ADSP remoteproc node along with its dependencies, including
the IPCC mailbox, AOSS QMP and SMP2P links used for communication.
The Eliza SoC features a USB 3.1 Gen 2 controller connected to a QMP
combo PHY and an SNPS eUSB2 PHY. Describe them.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 261 ++++++++++++++++++++++++++++++++++++
1 file changed, 261 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 4a7a0ac40ce6..37baa4b240d6 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -6,10 +6,13 @@
#include <dt-bindings/clock/qcom,eliza-gcc.h>
#include <dt-bindings/clock/qcom,eliza-tcsr.h>
#include <dt-bindings/clock/qcom,rpmh.h>
+#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interconnect/qcom,eliza-rpmh.h>
#include <dt-bindings/interconnect/qcom,icc.h>
#include <dt-bindings/interconnect/qcom,osm-l3.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/mailbox/qcom-ipcc.h>
+#include <dt-bindings/phy/phy-qcom-qmp.h>
#include <dt-bindings/power/qcom,rpmhpd.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
@@ -596,6 +599,30 @@ llcc_lpi_mem: llcc-lpi@ff800000 {
};
};
+ smp2p-adsp {
+ compatible = "qcom,smp2p";
+ qcom,smem = <443>, <429>;
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_SMP2P
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_SMP2P>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <2>;
+
+ smp2p_adsp_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ smp2p_adsp_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
soc: soc@0 {
compatible = "simple-bus";
@@ -624,6 +651,17 @@ gcc: clock-controller@100000 {
#power-domain-cells = <1>;
};
+ ipcc: mailbox@406000 {
+ compatible = "qcom,eliza-ipcc", "qcom,ipcc";
+ reg = <0x0 0x00406000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ #mbox-cells = <2>;
+ };
+
qupv3_2: geniqup@8c0000 {
compatible = "qcom,geni-se-qup";
reg = <0x0 0x008c0000 0x0 0x2000>;
@@ -862,6 +900,55 @@ tcsr: clock-controller@1fbf000 {
#reset-cells = <1>;
};
+ remoteproc_adsp: remoteproc@3000000 {
+ compatible = "qcom,eliza-adsp-pas";
+ reg = <0x0 0x03000000 0x0 0x10000>;
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack",
+ "shutdown-ack";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ power-domains = <&rpmhpd RPMHPD_LCX>,
+ <&rpmhpd RPMHPD_LMX>;
+ power-domain-names = "lcx",
+ "lmx";
+
+ interconnects = <&lpass_lpicx_noc MASTER_LPASS_PROC QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+
+ memory-region = <&adspslpi_mem>, <&q6_adsp_dtb_mem>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ };
+ };
+
lpass_ag_noc: interconnect@7e40000 {
compatible = "qcom,eliza-lpass-ag-noc";
reg = <0x0 0x07e40000 0x0 0xe080>;
@@ -883,6 +970,167 @@ lpass_lpicx_noc: interconnect@7420000 {
#interconnect-cells = <2>;
};
+ usb_hsphy: phy@88e3000 {
+ compatible = "qcom,eliza-snps-eusb2-phy",
+ "qcom,sm8550-snps-eusb2-phy";
+ reg = <0x0 0x088e3000 0x0 0x154>;
+ #phy-cells = <0>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "ref";
+
+ resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+
+ status = "disabled";
+ };
+
+ usb_dp_qmpphy: phy@88e8000 {
+ compatible = "qcom,eliza-qmp-usb3-dp-phy",
+ "qcom,sm8650-qmp-usb3-dp-phy";
+ reg = <0x0 0x088e8000 0x0 0x4000>;
+
+ clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
+ <&tcsr TCSR_USB3_CLKREF_EN>,
+ <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+ <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+ clock-names = "aux",
+ "ref",
+ "com_aux",
+ "usb3_pipe";
+
+ resets = <&gcc GCC_USB3_PHY_PRIM_BCR>,
+ <&gcc GCC_USB3_DP_PHY_PRIM_BCR>;
+ reset-names = "phy",
+ "common";
+
+ power-domains = <&gcc GCC_USB3_PHY_GDSC>;
+
+ #clock-cells = <1>;
+ #phy-cells = <1>;
+
+ orientation-switch;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_dp_qmpphy_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_dp_qmpphy_usb_ss_in: endpoint {
+ remote-endpoint = <&usb_dwc3_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb_dp_qmpphy_dp_in: endpoint {
+ };
+ };
+ };
+ };
+
+ usb: usb@a600000 {
+ compatible = "qcom,eliza-dwc3", "qcom,snps-dwc3";
+ reg = <0x0 0x0a600000 0x0 0xfc100>;
+
+ interrupts-extended = <&intc GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <&pdc 14 IRQ_TYPE_EDGE_BOTH>,
+ <&pdc 15 IRQ_TYPE_EDGE_BOTH>,
+ <&pdc 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "dwc_usb3",
+ "pwr_event",
+ "hs_phy_irq",
+ "dp_hs_phy_irq",
+ "dm_hs_phy_irq",
+ "ss_phy_irq";
+
+ clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_SLEEP_CLK>,
+ <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "cfg_noc",
+ "core",
+ "iface",
+ "sleep",
+ "mock_utmi",
+ "xo";
+
+ assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>;
+ assigned-clock-rates = <19200000>,
+ <200000000>;
+
+ resets = <&gcc GCC_USB30_PRIM_BCR>;
+
+ phys = <&usb_hsphy>,
+ <&usb_dp_qmpphy QMP_USB43DP_USB3_PHY>;
+ phy-names = "usb2-phy",
+ "usb3-phy";
+
+ interconnects = <&aggre1_noc MASTER_USB3_0 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_USB3_0 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "usb-ddr", "apps-usb";
+
+ iommus = <&apps_smmu 0x40 0x0>;
+
+ power-domains = <&gcc GCC_USB30_PRIM_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
+
+ snps,hird-threshold = /bits/ 8 <0x0>;
+ snps,usb2-gadget-lpm-disable;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
+ snps,is-utmi-l1-suspend;
+ snps,usb3_lpm_capable;
+ snps,usb2-lpm-disable;
+ snps,has-lpm-erratum;
+ tx-fifo-resize;
+
+ dma-coherent;
+ usb-role-switch;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_dwc3_hs: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_dwc3_ss: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_usb_ss_in>;
+ };
+ };
+ };
+ };
+
pdc: interrupt-controller@b220000 {
compatible = "qcom,eliza-pdc", "qcom,pdc";
reg = <0x0 0x0b220000 0x0 0x40000>,
@@ -957,6 +1205,19 @@ tsens2: thermal-sensor@c22a000 {
#thermal-sensor-cells = <1>;
};
+ aoss_qmp: power-management@c300000 {
+ compatible = "qcom,eliza-aoss-qmp", "qcom,aoss-qmp";
+ reg = <0x0 0x0c300000 0x0 0x400>;
+
+ interrupt-parent = <&ipcc>;
+ interrupts-extended = <&ipcc IPCC_CLIENT_AOP IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+
+ mboxes = <&ipcc IPCC_CLIENT_AOP IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ #clock-cells = <0>;
+ };
+
spmi: arbiter@c400000 {
compatible = "qcom,eliza-spmi-pmic-arb",
"qcom,x1e80100-spmi-pmic-arb";
--
2.48.1
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: qcom: eliza: Add ADSP and USB support
From: Abel Vesa @ 2026-03-31 10:37 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
The following patchsets document all necessary bindings:
https://lore.kernel.org/all/20260327-eliza-bindings-mailbox-ipcc-v1-1-3f1c89bdf72e@oss.qualcomm.com/
https://lore.kernel.org/all/20260327-eliza-remoteproc-adsp-v1-1-1c46c5e5f809@oss.qualcomm.com/
https://lore.kernel.org/all/20260327-eliza-bindings-phy-eusb2-v1-1-1f8a9ad6a033@oss.qualcomm.com/
https://lore.kernel.org/all/20260318-eliza-bindings-qmp-phy-v1-1-96a0d529ad2d@oss.qualcomm.com/
https://lore.kernel.org/all/20260327-eliza-bindings-dwc3-v2-1-28439482ebce@oss.qualcomm.com/
https://lore.kernel.org/all/20260327-eliza-bindings-aoss-v1-1-70df76adc69b@oss.qualcomm.com/
https://lore.kernel.org/all/20260327-eliza-bindings-pmic-glink-v1-1-f9a65495f599@oss.qualcomm.com/
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Abel Vesa (3):
arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes
arm64: dts: qcom: Add Eliza-specific PM7750BA dtsi
arm64: dts: qcom: eliza-mtp: Enable USB and ADSP support
arch/arm64/boot/dts/qcom/eliza-mtp.dts | 83 +++++++++
arch/arm64/boot/dts/qcom/eliza.dtsi | 261 +++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/pm7550ba-eliza.dtsi | 69 +++++++
3 files changed, 413 insertions(+)
---
base-commit: 5e59a51e3378f5d31e1f4f8efcb9763db3e322cf
change-id: 20260330-eliza-adsp-usb-8ef2b1b0fc13
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
^ 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