* Re: [PATCH v2 1/3] ARM: dts: ti: am335x-guardian: Drop unused isink-en property
From: Krzysztof Kozlowski @ 2026-07-20 6:49 UTC (permalink / raw)
To: Eduard Bostina
Cc: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Jingoo Han, Kevin Hilman,
Krzysztof Kozlowski, Lee Jones, linux-input, linux-kernel,
linux-leds, linux-omap, Pavel Machek, Rob Herring, Roger Quadros,
Tony Lindgren, daniel.baluta, simona.toaca, goledhruva,
m-chawdhry
In-Reply-To: <20260718215632.3295049-2-egbostina@gmail.com>
On Sat, Jul 18, 2026 at 09:56:30PM +0000, Eduard Bostina wrote:
> The 'isink-en' property is not read by any driver, so remove it from the
"...is not documented and not read by any driver..."
> TPS65217 backlight node.
With this change:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: hwmon: add binding for adi,adt7470
From: Krzysztof Kozlowski @ 2026-07-20 6:47 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong,
Uwe Kleine-König, linux-hwmon, devicetree, linux-kernel,
linux-pwm
In-Reply-To: <20260717-adt7470_thermalzone-v2-1-a55147958fad@gmail.com>
On Fri, Jul 17, 2026 at 05:59:14PM -0300, Luiz Angelo Daros de Luca wrote:
> The Analog Devices ADT7470 is a temperature monitor and PWM fan
> controller. It supports up to 10 external temperature sensors and
> up to 4 PWM fan outputs.
A nit, subject: drop second/last, redundant "binding for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
>
> Add the YAML device tree binding documentation for it. This includes
s/YAML//
There is no YAML in Devicetree.
> support for the thermal framework by defining the "#thermal-sensor-cells"
> property, and support for the PWM subsystem by defining the "#pwm-cells"
> property.
>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
> ---
> .../devicetree/bindings/hwmon/adi,adt7470.yaml | 62 ++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml b/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml
> new file mode 100644
> index 000000000000..14bb6359c91f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/adi,adt7470.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADT7470 hwmon sensor
> +
> +maintainers:
> + - Luiz Angelo Daros de Luca <luizluca@gmail.com>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + The ADT7470 is a temperature monitor and multiple PWM outputs.
> + It supports monitoring up to 10 external temperature sensors and controlling
> + up to four fans.
"controling fans" is confusing and suggests this is a fan controller, so
you would need to reference proper schema for that. It is just PWM
output, no? PWM output could also go to LEDs or motors (well, fan is a
motor).
> +
> +properties:
> + compatible:
> + const: adi,adt7470
> +
> + reg:
> + maxItems: 1
> +
> + "#pwm-cells":
> + const: 2
> + description: |
> + Number of cells in a PWM specifier.
> + - The first cell is the PWM channel (0 to 3).
> + - The second cell is the PWM period in nanoseconds.
> +
> + "#thermal-sensor-cells":
> + const: 1
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Number of cells required to uniquely identify the temperature sensors.
> + Valid index values are 0 to 9, corresponding to temp1 through temp10.
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adt7470: hwmon@2f {
> + compatible = "adi,adt7470";
> + reg = <0x2f>;
> + #pwm-cells = <2>;
> + #thermal-sensor-cells = <1>;
> + };
> + };
> +
> + fan0 {
Drio the node, not relevant. And then drop adt7470 label from hwmon
node.
> + compatible = "pwm-fan";
> + /* Connects to PWM channel 0 with a 50000 ns (20 kHz) period */
> + pwms = <&adt7470 0 50000>;
> + cooling-levels = <0 100 150 255>;
> + };
>
> --
> 2.55.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] soc/tegra: pmc: Add Tegra210B01 support
From: sashiko-bot @ 2026-07-20 6:45 UTC (permalink / raw)
To: Aaron Kling; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260720-t210b01-pmc-v2-2-ca5317f8507b@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The PMC driver will fail to probe on Tegra210B01 if the device tree contains legacy or unsupported powergate nodes (such as 'venc' or 've2').
- [Medium] Undocumented behavioral change silently disabling MBIST workarounds and I/O pad write-enables on Tegra210B01.
--
--- Patch [2]: [PATCH v2 2/2] soc/tegra: pmc: Add Tegra210B01 support ---
Note: The format of this review has been altered to provide a free-form summary
of the findings without quoting the original patch code due to recitation
restrictions.
commit c36910d71ccf4e86f0df7aa19d1325b68ba7e824
Author: Azkali Manad <a.ffcc7@gmail.com>
soc/tegra: pmc: Add Tegra210B01 support
The PMC in Tegra210B01 is very similar to the one in the original
Tegra210, but has a few powergate differences. Add support for this soc.
[Severity: High]
Will the PMC driver fail to probe on Tegra210B01 devices that reuse the
standard tegra210.dtsi?
The standard device tree contains venc and ve2 powergate nodes. Since
these are omitted from the new tegra210b01_powergates array,
tegra_powergate_lookup() will return -ENODEV for them.
During initialization, tegra_powergate_init() iterates over all child nodes
using for_each_child_of_node_scoped(). If tegra_powergate_add() returns an
error for any node, the loop breaks and propagates the error, aborting the
entire PMC probe. Could the loop be updated to safely skip unsupported
powergate nodes instead of failing?
[Severity: Medium]
Is it intentional that the mbist workaround and I/O pad write-enables are
disabled for this SoC?
The new tegra210b01_pmc_soc definition sets needs_mbist_war and
has_io_pad_wren to false, which diverges from the base tegra210_pmc_soc
where they are set to true.
The commit message mentions powergate differences, but doesn't mention
disabling these hardware flags. If the B01 hardware stepping resolved these
errata physically, could this be documented in the commit message? Otherwise,
will omitting these flags cause hardware initialization issues?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-t210b01-pmc-v2-0-ca5317f8507b@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v5 3/3] drm/bridge: ti-sn65dsi83: Add reversed lvds lanes support
From: Wojciech Dubowik @ 2026-07-20 6:39 UTC (permalink / raw)
To: Luca Ceresoli
Cc: linux-kernel, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Marek Vasut, dri-devel, devicetree
In-Reply-To: <178432135989.269908.12890193389587995172.b4-review@b4>
On Fri, Jul 17, 2026 at 10:49:19PM +0200, Luca Ceresoli wrote:
> On Fri, 17 Jul 2026 13:50:01 +0200, Wojciech Dubowik <wojciech.dubowik@mt.com> wrote:
Hello Luca,
>
> Hello,
>
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > index f8a786953526..df44df2e872a 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > @@ -845,6 +863,19 @@ static int sn65dsi83_parse_lvds_endpoint(struct sn65dsi83 *ctx, int channel)
> > else
> > return -EINVAL;
> >
> > + ret_data = of_property_read_u32_array(endpoint, "data-lanes", data_lanes,
> > + ARRAY_SIZE(data_lanes));
> > + if (!ret_data) {
> > + if (memcmp(data_lanes,
> > + supported_data_lane_mapping[LANE_MAPPING_REVERSE],
> > + ARRAY_SIZE(data_lanes)) == 0)
>
> Did you have a look at this sashiko report? It seems valid:
> | sashiko-bot@kernel.org <sashiko-bot@kernel.org>:
> |
> | [Severity: Medium]
> | Does this code compare the entire array? memcmp() expects the length in
> | bytes, but ARRAY_SIZE(data_lanes) evaluates to 4 (the number of elements).
> |
> | Because data_lanes is an array of u32, checking only 4 bytes means only
> | the first element is compared. Should this be using sizeof(data_lanes)
> | instead?
> |
> | via: https://patch.msgid.link/20260717115630.C58A61F000E9@smtp.kernel.org
>
> > + ctx->lvds_reverse_lanes_conf[channel] = true;
> > + else if (memcmp(data_lanes,
> > + supported_data_lane_mapping[LANE_MAPPING_NORMAL],
> > + ARRAY_SIZE(data_lanes)) != 0)
>
My stupid copy/paste error. I don't know how I have missed it. It has passed
my basic testing as it compares only firs lane. I will fix it in v6.
Regards,
Wojtek
> Same here.
>
> Otherwise looks good.
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: soc: tegra: pmc: Document Tegra210B01
From: Aaron Kling via B4 Relay @ 2026-07-20 6:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter
Cc: Thierry Reding, devicetree, linux-tegra, linux-kernel,
Aaron Kling
In-Reply-To: <20260720-t210b01-pmc-v2-0-ca5317f8507b@gmail.com>
From: Aaron Kling <webgeek1234@gmail.com>
The PMC in Tegra210B01 is very similar to the one in the original
Tegra210, but has a few powergate differences. Document this soc.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml
index f516960dbbefb..8ec36c49f9594 100644
--- a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml
@@ -18,6 +18,7 @@ properties:
- nvidia,tegra114-pmc
- nvidia,tegra124-pmc
- nvidia,tegra210-pmc
+ - nvidia,tegra210b01-pmc
reg:
maxItems: 1
@@ -346,7 +347,9 @@ allOf:
properties:
compatible:
contains:
- const: nvidia,tegra210-pmc
+ enum:
+ - nvidia,tegra210-pmc
+ - nvidia,tegra210b01-pmc
then:
properties:
pinmux:
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/2] soc/tegra: pmc: Add Tegra210B01 support
From: Aaron Kling via B4 Relay @ 2026-07-20 6:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter
Cc: Thierry Reding, devicetree, linux-tegra, linux-kernel,
Aaron Kling, Azkali Manad, Thomas Makin
This series adds support for the Tegra210B01 SoC to the Tegra PMC driver
and documents the new compatible.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Changes in v2:
- Address sashiko report and drop duplicated structs
- Link to v1: https://lore.kernel.org/r/20260717-t210b01-pmc-v1-0-bf776be8b3a7@gmail.com
---
Aaron Kling (1):
dt-bindings: soc: tegra: pmc: Document Tegra210B01
Azkali Manad (1):
soc/tegra: pmc: Add Tegra210B01 support
.../bindings/soc/tegra/nvidia,tegra20-pmc.yaml | 5 +-
drivers/soc/tegra/pmc.c | 62 ++++++++++++++++++++++
2 files changed, 66 insertions(+), 1 deletion(-)
---
base-commit: 1a1757b76427f6201bfe0bf1bea9f7574f332a93
change-id: 20260713-t210b01-pmc-1a3f8b908044
Best regards,
--
Aaron Kling <webgeek1234@gmail.com>
^ permalink raw reply
* [PATCH v2 2/2] soc/tegra: pmc: Add Tegra210B01 support
From: Aaron Kling via B4 Relay @ 2026-07-20 6:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter
Cc: Thierry Reding, devicetree, linux-tegra, linux-kernel,
Aaron Kling, Azkali Manad, Thomas Makin
In-Reply-To: <20260720-t210b01-pmc-v2-0-ca5317f8507b@gmail.com>
From: Azkali Manad <a.ffcc7@gmail.com>
The PMC in Tegra210B01 is very similar to the one in the original
Tegra210, but has a few powergate differences. Add support for this soc.
Signed-off-by: Azkali Manad <a.ffcc7@gmail.com>
Co-developed-by: Thomas Makin <halorocker89@gmail.com>
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
drivers/soc/tegra/pmc.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index f419a5395545f..48ae4ff3f00db 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -3897,6 +3897,67 @@ static const struct tegra_pmc_soc tegra210_pmc_soc = {
.has_single_mmio_aperture = true,
};
+static const char * const tegra210b01_powergates[] = {
+ [TEGRA_POWERGATE_CPU] = "crail",
+ [TEGRA_POWERGATE_3D] = "3d",
+ [TEGRA_POWERGATE_PCIE] = "pcie",
+ [TEGRA_POWERGATE_MPE] = "mpe",
+ [TEGRA_POWERGATE_SATA] = "sata",
+ [TEGRA_POWERGATE_CPU1] = "cpu1",
+ [TEGRA_POWERGATE_CPU2] = "cpu2",
+ [TEGRA_POWERGATE_CPU3] = "cpu3",
+ [TEGRA_POWERGATE_CPU0] = "cpu0",
+ [TEGRA_POWERGATE_C0NC] = "c0nc",
+ [TEGRA_POWERGATE_SOR] = "sor",
+ [TEGRA_POWERGATE_DIS] = "dis",
+ [TEGRA_POWERGATE_DISB] = "disb",
+ [TEGRA_POWERGATE_XUSBA] = "xusba",
+ [TEGRA_POWERGATE_XUSBB] = "xusbb",
+ [TEGRA_POWERGATE_XUSBC] = "xusbc",
+ [TEGRA_POWERGATE_VIC] = "vic",
+ [TEGRA_POWERGATE_IRAM] = "iram",
+ [TEGRA_POWERGATE_NVDEC] = "nvdec",
+ [TEGRA_POWERGATE_NVJPG] = "nvjpg",
+ [TEGRA_POWERGATE_AUD] = "aud",
+ [TEGRA_POWERGATE_DFD] = "dfd",
+};
+
+static const struct tegra_pmc_soc tegra210b01_pmc_soc = {
+ .supports_core_domain = false,
+ .num_powergates = ARRAY_SIZE(tegra210b01_powergates),
+ .powergates = tegra210b01_powergates,
+ .num_cpu_powergates = ARRAY_SIZE(tegra210_cpu_powergates),
+ .cpu_powergates = tegra210_cpu_powergates,
+ .has_tsense_reset = true,
+ .has_gpu_clamps = true,
+ .needs_mbist_war = false,
+ .has_io_pad_wren = false,
+ .maybe_tz_only = true,
+ .num_io_pads = ARRAY_SIZE(tegra210_io_pads),
+ .io_pads = tegra210_io_pads,
+ .num_io_pad_vctrls = ARRAY_SIZE(tegra210_io_pad_vctrls),
+ .io_pad_vctrls = tegra210_io_pad_vctrls,
+ .num_pin_descs = ARRAY_SIZE(tegra210_pin_descs),
+ .pin_descs = tegra210_pin_descs,
+ .regs = &tegra20_pmc_regs,
+ .init = tegra20_pmc_init,
+ .setup_irq_polarity = tegra20_pmc_setup_irq_polarity,
+ .powergate_set = tegra114_powergate_set,
+ .irq_set_wake = tegra210_pmc_irq_set_wake,
+ .irq_set_type = tegra210_pmc_irq_set_type,
+ .reset_sources = tegra210_reset_sources,
+ .num_reset_sources = ARRAY_SIZE(tegra210_reset_sources),
+ .reset_levels = NULL,
+ .num_reset_levels = 0,
+ .num_wake_events = ARRAY_SIZE(tegra210_wake_events),
+ .wake_events = tegra210_wake_events,
+ .pmc_clks_data = tegra_pmc_clks_data,
+ .num_pmc_clks = ARRAY_SIZE(tegra_pmc_clks_data),
+ .has_blink_output = true,
+ .has_usb_sleepwalk = true,
+ .has_single_mmio_aperture = true,
+};
+
static const struct tegra_io_pad_soc tegra186_io_pads[] = {
TEGRA_IO_PAD(TEGRA_IO_PAD_CSIA, 0, 0x74, 0x78, "csia"),
TEGRA_IO_PAD(TEGRA_IO_PAD_CSIB, 1, 0x74, 0x78, "csib"),
@@ -4824,6 +4885,7 @@ static const struct of_device_id tegra_pmc_match[] = {
{ .compatible = "nvidia,tegra194-pmc", .data = &tegra194_pmc_soc },
{ .compatible = "nvidia,tegra186-pmc", .data = &tegra186_pmc_soc },
{ .compatible = "nvidia,tegra210-pmc", .data = &tegra210_pmc_soc },
+ { .compatible = "nvidia,tegra210b01-pmc", .data = &tegra210b01_pmc_soc },
{ .compatible = "nvidia,tegra132-pmc", .data = &tegra124_pmc_soc },
{ .compatible = "nvidia,tegra124-pmc", .data = &tegra124_pmc_soc },
{ .compatible = "nvidia,tegra114-pmc", .data = &tegra114_pmc_soc },
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 7/7] soc: mediatek: mtk-mmsys: Add resets for mt8167
From: Krzysztof Kozlowski @ 2026-07-20 6:30 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717163959.714561-8-l.scorcia@gmail.com>
On Fri, Jul 17, 2026 at 06:39:18PM +0200, Luca Leonardo Scorcia wrote:
> The mt8167 SoC has 64 MMSYS resets, split in two contiguous 32-bits
> registers, MMSYS_SW0_RST_B (0x140) and MMSYS_SW1_RST_B (0x144), as
> also stated in the downstream kernel for the Lenovo Smart Clock
> in the ddp_reg.h header.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> drivers/soc/mediatek/mt8167-mmsys.h | 41 +++++++++++++++++++++++++++++
> drivers/soc/mediatek/mtk-mmsys.c | 3 +++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mt8167-mmsys.h b/drivers/soc/mediatek/mt8167-mmsys.h
> index eef14083c47b..dc3e882a9893 100644
> --- a/drivers/soc/mediatek/mt8167-mmsys.h
> +++ b/drivers/soc/mediatek/mt8167-mmsys.h
> @@ -3,6 +3,47 @@
> #ifndef __SOC_MEDIATEK_MT8167_MMSYS_H
> #define __SOC_MEDIATEK_MT8167_MMSYS_H
>
> +#include <linux/soc/mediatek/mtk-mmsys.h>
> +#include <dt-bindings/reset/mediatek,mt8167-resets.h>
> +
> +#define MT8167_MMSYS_SW0_RST_B 0x140
> +#define MT8167_MMSYS_SW1_RST_B 0x144
> +
> +/* MMSYS resets */
> +static const u8 mmsys_mt8167_rst_tb[] = {
No, data structures NEVER go to the headers because it leads easily to
duplicated data.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree
From: Joseph Guo @ 2026-07-20 6:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, qijian.guo,
justin.jiang, joy.zou, Joseph Guo
In-Reply-To: <20260720-imx952_frdm-v1-0-6d145eaaa5c4@nxp.com>
Add basic device tree support for i.MX952 FRDM Board.
The board-common hardware description is placed in imx952-frdm.dtsi
so that it can be shared with future i.MX952-based FRDM derivative
boards.
The following peripherals are enabled:
- LPUART1 (console), LPUART5 (BT)
- USDHC1, USDHC2, USDHC3,
- FlexCAN2, FlexCAN3,
- USB1, USB2,
- LPI2C2, LPI2C4
- WDOG3
- MICFIL (PDM)
- LPSPI3
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
arch/arm64/boot/dts/freescale/imx952-frdm.dts | 9 +
arch/arm64/boot/dts/freescale/imx952-frdm.dtsi | 727 +++++++++++++++++++++++++
3 files changed, 738 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index be3c858f1eeb1a807cb8ac36269c581143f755df..a9554dfc785fc43305ad45bb0b80772041e91737 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -702,6 +702,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-verdin-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx952-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx952-frdm.dtb
+
imx8mm-kontron-dl-dtbs := imx8mm-kontron-bl.dtb imx8mm-kontron-dl.dtbo
imx8mm-kontron-bl-lte-dtbs := imx8mm-kontron-bl.dtb imx8mm-kontron-bl-lte.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dts b/arch/arm64/boot/dts/freescale/imx952-frdm.dts
new file mode 100644
index 0000000000000000000000000000000000000000..0b9d74eea37668b455b945b25feb7d9c4fa5a439
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+
+#include "imx952.dtsi"
+#include "imx952-frdm.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
new file mode 100644
index 0000000000000000000000000000000000000000..b9ef6bec2bd5af522bb63f0244379524000957c8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
@@ -0,0 +1,727 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+#include <dt-bindings/usb/pd.h>
+
+#define BRD_SM_CTRL_SD3_WAKE 0x8000U /*!< PCAL6408A-0 */
+#define BRD_SM_CTRL_M2M_WAKE 0x8003U /*!< PCAL6408A-6 */
+#define BRD_SM_CTRL_BUTTON 0x8004U /*!< PCAL6408A-7 */
+
+/ {
+ compatible = "fsl,imx952-frdm", "fsl,imx952";
+ model = "NXP i.MX952 FRDM board";
+
+ aliases {
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ gpio3 = &gpio4;
+ gpio4 = &gpio5;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ i2c3 = &lpi2c4;
+ i2c4 = &lpi2c5;
+ i2c5 = &lpi2c6;
+ i2c6 = &lpi2c7;
+ i2c7 = &lpi2c8;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart1;
+ serial4 = &lpuart5;
+ spi2 = &lpspi3;
+ };
+
+ bt_sco_codec: audio-codec-bt-sco {
+ compatible = "linux,bt-sco";
+ #sound-dai-cells = <1>;
+ };
+
+ chosen {
+ stdout-path = &lpuart1;
+ };
+
+ dmic: dmic {
+ compatible = "dmic-codec";
+ #sound-dai-cells = <0>;
+ num-channels = <2>;
+ };
+
+ flexcan2_phy: can-phy0 {
+ compatible = "nxp,tja1051";
+ #phy-cells = <0>;
+ max-bitrate = <8000000>;
+ silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
+ };
+
+ flexcan3_phy: can-phy1 {
+ compatible = "nxp,tja1051";
+ #phy-cells = <0>;
+ max-bitrate = <8000000>;
+ silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "+V1.8_SW";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "+V3.3_SW";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+
+ reg_5p0v: regulator-5p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "+V5.0_SW";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ };
+
+ reg_vref_1v8: regulator-adc-vref {
+ compatible = "regulator-fixed";
+ regulator-name = "vref_1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_dummy: regulator-dummy {
+ compatible = "regulator-fixed";
+ regulator-name = "dummy";
+ };
+
+ reg_ext_12v: regulator-ext-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "VCCEXT_12V";
+ regulator-max-microvolt = <12000000>;
+ regulator-min-microvolt = <12000000>;
+ vin-supply = <®_ext_5v>;
+ };
+
+ reg_ext_3v3: regulator-ext-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCCEXT_3V3";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&pcal6416 13 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ reg_ext_5v: regulator-ext-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "VCCEXT_5V";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&pcal6416 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ reg_m2_pwr: regulator-m2-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "M.2-power";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&pcal6416 11 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_SD2_3V3";
+ off-on-delay-us = <12000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc3_vmmc: regulator-usdhc3 {
+ compatible = "regulator-fixed";
+ regulator-name = "WLAN_EN";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ vin-supply = <®_m2_pwr>;
+ gpio = <&pcal6416 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ /*
+ * IW612 wifi chip needs more delay than other wifi chips to complete
+ * the host interface initialization after power up, otherwise the
+ * internal state of IW612 may be unstable, resulting in the failure of
+ * the SDIO3.0 switch voltage.
+ */
+ startup-delay-us = <20000>;
+ };
+
+ reg_usb_vbus: regulator-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_VBUS";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&pcal6416 15 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ ranges;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ linux_cma: linux,cma {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0 0x80000000 0 0x7f000000>;
+ reusable;
+ size = <0 0x3c000000>;
+ linux,cma-default;
+ };
+ };
+
+ sound-bt-sco {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-inversion;
+ simple-audio-card,bitclock-master = <&btcpu>;
+ simple-audio-card,format = "dsp_a";
+ simple-audio-card,frame-master = <&btcpu>;
+ simple-audio-card,name = "bt-sco-audio";
+
+ simple-audio-card,codec {
+ sound-dai = <&bt_sco_codec 1>;
+ };
+
+ btcpu: simple-audio-card,cpu {
+ dai-tdm-slot-num = <2>;
+ dai-tdm-slot-width = <16>;
+ sound-dai = <&sai5>;
+ };
+ };
+
+ sound-micfil {
+ compatible = "fsl,imx-audio-card";
+ model = "micfil-audio";
+
+ pri-dai-link {
+ format = "i2s";
+ link-name = "micfil hifi";
+
+ codec {
+ sound-dai = <&dmic>;
+ };
+
+ cpu {
+ sound-dai = <&micfil>;
+ };
+ };
+ };
+
+ usdhc3_pwrseq: usdhc3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pcal6416 8 GPIO_ACTIVE_LOW>;
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0 0x80000000>;
+ };
+};
+
+&adc1 {
+ vref-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+&asrc1 {
+ assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX952_CLK_ASRC1>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>, <3612672000>,
+ <393216000>, <361267200>, <49152000>;
+ fsl,asrc-rate = <48000>;
+ status = "okay";
+};
+
+&asrc2 {
+ assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX952_CLK_ASRC2>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>, <3612672000>,
+ <393216000>, <361267200>, <49152000>;
+ fsl,asrc-rate = <48000>;
+ status = "okay";
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ phys = <&flexcan2_phy>;
+ status = "okay";
+};
+
+&flexcan3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan3>;
+ phys = <&flexcan3_phy>;
+ status = "okay";
+};
+
+&lpi2c2 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c2>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ pcal6416: gpio@20 {
+ compatible = "nxp,pcal6416";
+ reg = <0x20>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio5>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ pinctrl-0 = <&pinctrl_pcal6416>;
+ pinctrl-names = "default";
+ vcc-supply = <®_3p3v>;
+
+ /* When low, select CAN; When high, select gpio. */
+ can-gpio-sel-hog {
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ gpio-hog;
+ output-low;
+ };
+ };
+};
+
+&lpi2c4 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c4>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ptn5110: tcpc@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&pinctrl_ptn5110>;
+ pinctrl-names = "default";
+
+ typec_con: connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ label = "USB-C";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&lpspi3 {
+ cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&pinctrl_lpspi3>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&lpuart1 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&lpuart5 {
+ /* BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+&micfil {
+ assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX952_CLK_PDM>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>, <3612672000>,
+ <393216000>, <361267200>, <49152000>;
+ pinctrl-0 = <&pinctrl_pdm>;
+ pinctrl-1 = <&pinctrl_pdm_sleep>;
+ pinctrl-names = "default", "sleep";
+ status = "okay";
+};
+
+&sai5 {
+ assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX952_CLK_SAI5>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>, <&scmi_clk IMX952_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>, <3612672000>, <393216000>, <361267200>, <12288000>;
+ #sound-dai-cells = <0>;
+ pinctrl-0 = <&pinctrl_sai5>;
+ pinctrl-names = "default";
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ IMX952_PAD_GPIO_IO25__WAKEUPMIX_TOP_CAN2_TX 0x39e
+ IMX952_PAD_GPIO_IO27__WAKEUPMIX_TOP_CAN2_RX 0x39e
+ >;
+ };
+
+ pinctrl_flexcan3: flexcan3grp {
+ fsl,pins = <
+ IMX952_PAD_CCM_CLKO3__WAKEUPMIX_TOP_CAN3_TX 0x39e
+ IMX952_PAD_CCM_CLKO4__WAKEUPMIX_TOP_CAN3_RX 0x39e
+ >;
+ };
+
+ pinctrl_lpi2c2: lpi2c2grp {
+ fsl,pins = <
+ IMX952_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL 0x40000b9e
+ IMX952_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c4: lpi2c4grp {
+ fsl,pins = <
+ IMX952_PAD_GPIO_IO30__WAKEUPMIX_TOP_LPI2C4_SDA 0x40000b9e
+ IMX952_PAD_GPIO_IO31__WAKEUPMIX_TOP_LPI2C4_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpspi3: lpspi3grp {
+ fsl,pins = <
+ IMX952_PAD_GPIO_IO08__WAKEUPMIX_TOP_GPIO2_IO_8 0x39e
+ IMX952_PAD_GPIO_IO09__WAKEUPMIX_TOP_LPSPI3_SIN 0x39e
+ IMX952_PAD_GPIO_IO10__WAKEUPMIX_TOP_LPSPI3_SOUT 0x39e
+ IMX952_PAD_GPIO_IO11__WAKEUPMIX_TOP_LPSPI3_SCK 0x39e
+ >;
+ };
+
+ pinctrl_pcal6416: pcal6416grp {
+ fsl,pins = <
+ IMX952_PAD_GPIO_IO34__WAKEUPMIX_TOP_GPIO5_IO_14 0x31e
+ >;
+ };
+
+ pinctrl_pdm: pdmgrp {
+ fsl,pins = <
+ IMX952_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e
+ IMX952_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_0 0x31e
+ >;
+ };
+
+ pinctrl_pdm_sleep: pdmsleepgrp {
+ fsl,pins = <
+ IMX952_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_8 0x31e
+ IMX952_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_9 0x31e
+ >;
+ };
+
+ pinctrl_ptn5110: ptn5110grp {
+ fsl,pins = <
+ IMX952_PAD_XSPI1_DATA2__WAKEUPMIX_TOP_GPIO5_IO_2 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ IMX952_PAD_SD2_RESET_B__WAKEUPMIX_TOP_GPIO3_IO_7 0x31e
+ >;
+ };
+
+ pinctrl_sai5: sai5grp {
+ fsl,pins = <
+ IMX952_PAD_XSPI1_DATA4__WAKEUPMIX_TOP_SAI5_TX_DATA_0 0x31e
+ IMX952_PAD_XSPI1_DATA5__WAKEUPMIX_TOP_SAI5_TX_SYNC 0x31e
+ IMX952_PAD_XSPI1_DATA6__WAKEUPMIX_TOP_SAI5_TX_BCLK 0x31e
+ IMX952_PAD_XSPI1_DATA7__WAKEUPMIX_TOP_SAI5_RX_DATA_0 0x31e
+ >;
+ };
+
+ pinctrl_tpm3: tpm3grp {
+ fsl,pins = <
+ IMX952_PAD_GPIO_IO04__WAKEUPMIX_TOP_TPM3_CH0 0x51e
+ IMX952_PAD_GPIO_IO12__WAKEUPMIX_TOP_TPM3_CH2 0x51e
+ >;
+ };
+
+ pinctrl_tpm4: tpm4grp {
+ fsl,pins = <
+ IMX952_PAD_GPIO_IO13__WAKEUPMIX_TOP_TPM4_CH2 0x51e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ IMX952_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x31e
+ IMX952_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ IMX952_PAD_DAP_TDO_TRACESWO__WAKEUPMIX_TOP_LPUART5_TX 0x31e
+ IMX952_PAD_DAP_TDI__WAKEUPMIX_TOP_LPUART5_RX 0x31e
+ IMX952_PAD_DAP_TMS_SWDIO__WAKEUPMIX_TOP_LPUART5_RTS_B 0x31e
+ IMX952_PAD_DAP_TCLK_SWCLK__WAKEUPMIX_TOP_LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ IMX952_PAD_SD1_CLK__WAKEUPMIX_TOP_USDHC1_CLK 0x158e
+ IMX952_PAD_SD1_CMD__WAKEUPMIX_TOP_USDHC1_CMD 0x138e
+ IMX952_PAD_SD1_DATA0__WAKEUPMIX_TOP_USDHC1_DATA0 0x138e
+ IMX952_PAD_SD1_DATA1__WAKEUPMIX_TOP_USDHC1_DATA1 0x138e
+ IMX952_PAD_SD1_DATA2__WAKEUPMIX_TOP_USDHC1_DATA2 0x138e
+ IMX952_PAD_SD1_DATA3__WAKEUPMIX_TOP_USDHC1_DATA3 0x138e
+ IMX952_PAD_SD1_DATA4__WAKEUPMIX_TOP_USDHC1_DATA4 0x138e
+ IMX952_PAD_SD1_DATA5__WAKEUPMIX_TOP_USDHC1_DATA5 0x138e
+ IMX952_PAD_SD1_DATA6__WAKEUPMIX_TOP_USDHC1_DATA6 0x138e
+ IMX952_PAD_SD1_DATA7__WAKEUPMIX_TOP_USDHC1_DATA7 0x138e
+ IMX952_PAD_SD1_STROBE__WAKEUPMIX_TOP_USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ IMX952_PAD_SD1_CLK__WAKEUPMIX_TOP_USDHC1_CLK 0x158e
+ IMX952_PAD_SD1_CMD__WAKEUPMIX_TOP_USDHC1_CMD 0x138e
+ IMX952_PAD_SD1_DATA0__WAKEUPMIX_TOP_USDHC1_DATA0 0x138e
+ IMX952_PAD_SD1_DATA1__WAKEUPMIX_TOP_USDHC1_DATA1 0x138e
+ IMX952_PAD_SD1_DATA2__WAKEUPMIX_TOP_USDHC1_DATA2 0x138e
+ IMX952_PAD_SD1_DATA3__WAKEUPMIX_TOP_USDHC1_DATA3 0x138e
+ IMX952_PAD_SD1_DATA4__WAKEUPMIX_TOP_USDHC1_DATA4 0x138e
+ IMX952_PAD_SD1_DATA5__WAKEUPMIX_TOP_USDHC1_DATA5 0x138e
+ IMX952_PAD_SD1_DATA6__WAKEUPMIX_TOP_USDHC1_DATA6 0x138e
+ IMX952_PAD_SD1_DATA7__WAKEUPMIX_TOP_USDHC1_DATA7 0x138e
+ IMX952_PAD_SD1_STROBE__WAKEUPMIX_TOP_USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ IMX952_PAD_SD1_CLK__WAKEUPMIX_TOP_USDHC1_CLK 0x159e
+ IMX952_PAD_SD1_CMD__WAKEUPMIX_TOP_USDHC1_CMD 0x139e
+ IMX952_PAD_SD1_DATA0__WAKEUPMIX_TOP_USDHC1_DATA0 0x139e
+ IMX952_PAD_SD1_DATA1__WAKEUPMIX_TOP_USDHC1_DATA1 0x139e
+ IMX952_PAD_SD1_DATA2__WAKEUPMIX_TOP_USDHC1_DATA2 0x139e
+ IMX952_PAD_SD1_DATA3__WAKEUPMIX_TOP_USDHC1_DATA3 0x139e
+ IMX952_PAD_SD1_DATA4__WAKEUPMIX_TOP_USDHC1_DATA4 0x139e
+ IMX952_PAD_SD1_DATA5__WAKEUPMIX_TOP_USDHC1_DATA5 0x139e
+ IMX952_PAD_SD1_DATA6__WAKEUPMIX_TOP_USDHC1_DATA6 0x139e
+ IMX952_PAD_SD1_DATA7__WAKEUPMIX_TOP_USDHC1_DATA7 0x139e
+ IMX952_PAD_SD1_STROBE__WAKEUPMIX_TOP_USDHC1_STROBE 0x159e
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ IMX952_PAD_SD2_CD_B__WAKEUPMIX_TOP_GPIO3_IO_0 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ IMX952_PAD_SD2_CLK__WAKEUPMIX_TOP_USDHC2_CLK 0x158e
+ IMX952_PAD_SD2_CMD__WAKEUPMIX_TOP_USDHC2_CMD 0x138e
+ IMX952_PAD_SD2_DATA0__WAKEUPMIX_TOP_USDHC2_DATA0 0x138e
+ IMX952_PAD_SD2_DATA1__WAKEUPMIX_TOP_USDHC2_DATA1 0x138e
+ IMX952_PAD_SD2_DATA2__WAKEUPMIX_TOP_USDHC2_DATA2 0x138e
+ IMX952_PAD_SD2_DATA3__WAKEUPMIX_TOP_USDHC2_DATA3 0x138e
+ IMX952_PAD_SD2_VSELECT__WAKEUPMIX_TOP_USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ IMX952_PAD_SD2_CLK__WAKEUPMIX_TOP_USDHC2_CLK 0x158e
+ IMX952_PAD_SD2_CMD__WAKEUPMIX_TOP_USDHC2_CMD 0x138e
+ IMX952_PAD_SD2_DATA0__WAKEUPMIX_TOP_USDHC2_DATA0 0x138e
+ IMX952_PAD_SD2_DATA1__WAKEUPMIX_TOP_USDHC2_DATA1 0x138e
+ IMX952_PAD_SD2_DATA2__WAKEUPMIX_TOP_USDHC2_DATA2 0x138e
+ IMX952_PAD_SD2_DATA3__WAKEUPMIX_TOP_USDHC2_DATA3 0x138e
+ IMX952_PAD_SD2_VSELECT__WAKEUPMIX_TOP_USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ IMX952_PAD_SD2_CLK__WAKEUPMIX_TOP_USDHC2_CLK 0x158e
+ IMX952_PAD_SD2_CMD__WAKEUPMIX_TOP_USDHC2_CMD 0x138e
+ IMX952_PAD_SD2_DATA0__WAKEUPMIX_TOP_USDHC2_DATA0 0x138e
+ IMX952_PAD_SD2_DATA1__WAKEUPMIX_TOP_USDHC2_DATA1 0x138e
+ IMX952_PAD_SD2_DATA2__WAKEUPMIX_TOP_USDHC2_DATA2 0x138e
+ IMX952_PAD_SD2_DATA3__WAKEUPMIX_TOP_USDHC2_DATA3 0x138e
+ IMX952_PAD_SD2_VSELECT__WAKEUPMIX_TOP_USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ IMX952_PAD_SD3_CLK__WAKEUPMIX_TOP_USDHC3_CLK 0x158e
+ IMX952_PAD_SD3_CMD__WAKEUPMIX_TOP_USDHC3_CMD 0x138e
+ IMX952_PAD_SD3_DATA0__WAKEUPMIX_TOP_USDHC3_DATA0 0x138e
+ IMX952_PAD_SD3_DATA1__WAKEUPMIX_TOP_USDHC3_DATA1 0x138e
+ IMX952_PAD_SD3_DATA2__WAKEUPMIX_TOP_USDHC3_DATA2 0x138e
+ IMX952_PAD_SD3_DATA3__WAKEUPMIX_TOP_USDHC3_DATA3 0x138e
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ IMX952_PAD_SD3_CLK__WAKEUPMIX_TOP_USDHC3_CLK 0x158e
+ IMX952_PAD_SD3_CMD__WAKEUPMIX_TOP_USDHC3_CMD 0x138e
+ IMX952_PAD_SD3_DATA0__WAKEUPMIX_TOP_USDHC3_DATA0 0x138e
+ IMX952_PAD_SD3_DATA1__WAKEUPMIX_TOP_USDHC3_DATA1 0x138e
+ IMX952_PAD_SD3_DATA2__WAKEUPMIX_TOP_USDHC3_DATA2 0x138e
+ IMX952_PAD_SD3_DATA3__WAKEUPMIX_TOP_USDHC3_DATA3 0x138e
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ IMX952_PAD_SD3_CLK__WAKEUPMIX_TOP_USDHC3_CLK 0x158e
+ IMX952_PAD_SD3_CMD__WAKEUPMIX_TOP_USDHC3_CMD 0x138e
+ IMX952_PAD_SD3_DATA0__WAKEUPMIX_TOP_USDHC3_DATA0 0x138e
+ IMX952_PAD_SD3_DATA1__WAKEUPMIX_TOP_USDHC3_DATA1 0x138e
+ IMX952_PAD_SD3_DATA2__WAKEUPMIX_TOP_USDHC3_DATA2 0x138e
+ IMX952_PAD_SD3_DATA3__WAKEUPMIX_TOP_USDHC3_DATA3 0x138e
+ >;
+ };
+};
+
+&scmi_misc {
+ nxp,ctrl-ids = <BRD_SM_CTRL_SD3_WAKE 1
+ BRD_SM_CTRL_M2M_WAKE 1
+ BRD_SM_CTRL_BUTTON 1>;
+};
+
+&tpm3 {
+ pinctrl-0 = <&pinctrl_tpm3>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&tpm4 {
+ pinctrl-0 = <&pinctrl_tpm4>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb1 {
+ adp-disable;
+ disable-over-current;
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ usb-role-switch;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usb2 {
+ disable-over-current;
+ dr_mode = "host";
+ vbus-supply = <®_usb_vbus>;
+ status = "okay";
+};
+
+&usdhc1 {
+ bus-width = <8>;
+ non-removable;
+ no-sd;
+ no-sdio;
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ pinctrl-3 = <&pinctrl_usdhc1>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ status = "okay";
+};
+
+&usdhc2 {
+ bus-width = <4>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ vmmc-supply = <®_usdhc2_vmmc>;
+ fsl,cd-gpio-wakeup-disable;
+ status = "okay";
+};
+
+&usdhc3 {
+ bus-width = <4>;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ non-removable;
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ pinctrl-3 = <&pinctrl_usdhc3>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ vmmc-supply = <®_usdhc3_vmmc>;
+ wakeup-source;
+ status = "okay";
+};
+
+&wdog3 {
+ fsl,ext-reset-output;
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: arm: fsl: add i.MX952 FRDM board
From: Joseph Guo @ 2026-07-20 6:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, qijian.guo,
justin.jiang, joy.zou, Joseph Guo
In-Reply-To: <20260720-imx952_frdm-v1-0-6d145eaaa5c4@nxp.com>
Add DT compatible string for NXP i.MX952 FRDM board.
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7b57a6ee1b50dc22ece292d6d9b53b5aa834ee96..f67b3f6d57d3623d41364f852a64802ad2217560 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1536,6 +1536,7 @@ properties:
items:
- enum:
- fsl,imx952-evk # i.MX952 EVK Board
+ - fsl,imx952-frdm # i.MX952 FRDM Board
- const: fsl,imx952
- description: PHYTEC i.MX 95 FPSC based Boards
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] Add i.MX952 FRDM board support
From: Joseph Guo @ 2026-07-20 6:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, qijian.guo,
justin.jiang, joy.zou, Joseph Guo
i.MX952 FRDM Board is a low-cost and compact board featuring the i.MX952
application processor.
Add dt-bindings and basic device tree for i.MX952 FRDM board.
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Joseph Guo (2):
dt-bindings: arm: fsl: add i.MX952 FRDM board
arm64: dts: freescale: add i.MX952 FRDM Board support device tree
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
arch/arm64/boot/dts/freescale/imx952-frdm.dts | 9 +
arch/arm64/boot/dts/freescale/imx952-frdm.dtsi | 727 +++++++++++++++++++++++++
4 files changed, 739 insertions(+)
---
base-commit: 139fb260e37938042c6ffaad796e236fde2bafed
change-id: 20260717-imx952_frdm-e8fb415ae4d4
Best regards,
--
Joseph Guo <qijian.guo@nxp.com>
^ permalink raw reply
* [PATCH v10 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-07-20 6:28 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260720062829.7343-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG encoder block found in the
MediaTek MT8189 SoC.
Unlike some previous SoCs, the MT8189 JPEG encoder requires 34-bit IOVA
address space support. Therefore, it is added as a standalone compatible
string without falling back to the generic "mediatek,mtk-jpgenc" to
ensure the driver applies the correct hardware-specific configurations.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 38 ++++++++++++++++---
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..d2f035715a2e 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,17 @@ description: |-
properties:
compatible:
- items:
+ oneOf:
- enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mtk-jpgenc
+
reg:
maxItems: 1
@@ -45,6 +49,15 @@ properties:
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
Ports are according to the HW.
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ A phandle to the local arbiter (SMI LARB) node. This explicitly
+ describes the hardware topology where the JPEG block is connected
+ to a dedicated SMI LARB for memory bandwidth arbitration. It is
+ required to accurately represent the hardware connection independently
+ of the IOMMU.
+
required:
- compatible
- reg
@@ -54,6 +67,19 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgenc
+ then:
+ required:
+ - mediatek,larb
+ else:
+ properties:
+ mediatek,larb: false
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v10 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-07-20 6:28 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260720062829.7343-1-jianhua.lin@mediatek.com>
Compared to the previous generation ICs, the MT8189 uses a 34-bit IOVA
address space (16GB) and requires a single clock configuration.
Therefore, add new compatible strings ("mediatek,mt8189-jpgenc" and
"mediatek,mt8189-jpgdec") along with their specific driver data to
support the JPEG encoder and decoder of the MT8189 SoC.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483081..14f2991a4053 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1868,6 +1868,10 @@ static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
{ .id = "jpgdec" },
};
+static struct clk_bulk_data mtk_jpeg_dec_clocks[] = {
+ { .id = "jpgdec" },
+};
+
static const struct mtk_jpeg_variant mt8173_jpeg_drvdata = {
.clks = mt8173_jpeg_dec_clocks,
.num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks),
@@ -1899,6 +1903,38 @@ static const struct mtk_jpeg_variant mtk_jpeg_drvdata = {
.multi_core = false,
};
+static const struct mtk_jpeg_variant mtk8189_jpegenc_drvdata = {
+ .clks = mtk_jpeg_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_clocks),
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .irq_handler = mtk_jpeg_enc_irq,
+ .hw_reset = mtk_jpeg_enc_reset,
+ .m2m_ops = &mtk_jpeg_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .support_34bit = true,
+};
+
+static const struct mtk_jpeg_variant mtk8189_jpegdec_drvdata = {
+ .clks = mtk_jpeg_dec_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_dec_clocks),
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .irq_handler = mtk_jpeg_dec_irq,
+ .hw_reset = mtk_jpeg_dec_reset,
+ .m2m_ops = &mtk_jpeg_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .support_34bit = true,
+};
+
static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.formats = mtk_jpeg_enc_formats,
.num_formats = MTK_JPEG_ENC_NUM_FORMATS,
@@ -1938,6 +1974,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mtk-jpgenc",
.data = &mtk_jpeg_drvdata,
},
+ {
+ .compatible = "mediatek,mt8189-jpgenc",
+ .data = &mtk8189_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8189-jpgdec",
+ .data = &mtk8189_jpegdec_drvdata,
+ },
{
.compatible = "mediatek,mt8195-jpgenc",
.data = &mtk8195_jpegenc_drvdata,
--
2.45.2
^ permalink raw reply related
* [PATCH v10 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-07-20 6:28 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260720062829.7343-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG decoder block found in the
MediaTek MT8189 SoC.
Compared to previous generation ICs, the MT8189 JPEG decoder requires
34-bit IOVA address space support and only needs a single clock
("jpgdec") instead of two. Therefore, it is added as a standalone
compatible string without falling back to older SoCs.
Update the binding schema to include the new compatible string and add
an `allOf` block with conditional checks. This enforces the single clock
requirement for MT8189 while preserving the two-clock requirement
("jpgdec-smi", "jpgdec") for older SoCs.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 50 ++++++++++++++++---
1 file changed, 42 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index a4aacd3eb189..654360c19c48 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -15,10 +15,10 @@ description: |-
properties:
compatible:
oneOf:
- - items:
- - enum:
- - mediatek,mt8173-jpgdec
- - mediatek,mt2701-jpgdec
+ - enum:
+ - mediatek,mt2701-jpgdec
+ - mediatek,mt8173-jpgdec
+ - mediatek,mt8189-jpgdec
- items:
- enum:
- mediatek,mt7623-jpgdec
@@ -32,13 +32,16 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ oneOf:
+ - items:
+ - const: jpgdec
+ - items:
+ - const: jpgdec-smi
+ - const: jpgdec
power-domains:
maxItems: 1
@@ -51,6 +54,15 @@ properties:
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
Ports are according to the HW.
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ A phandle to the local arbiter (SMI LARB) node. This explicitly
+ describes the hardware topology where the JPEG block is connected
+ to a dedicated SMI LARB for memory bandwidth arbitration. It is
+ required to accurately represent the hardware connection independently
+ of the IOMMU.
+
required:
- compatible
- reg
@@ -60,6 +72,28 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ required:
+ - mediatek,larb
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ mediatek,larb: false
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v10 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-07-20 6:28 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
This series is based on linux-next tag next-20260707.
This series depends on commit 7560349ee0d9 ("media: mediatek: jpeg:
support 34bits"), which introduced the `support_34bit` field in struct
mtk_jpeg_variant. That commit has already been merged via the media
tree and is present in linux-next as of next-20260707.
Changes compared with v9:
- Patches 1/3 & 2/3 (dt-bindings: decoder & encoder):
- Explicitly set `mediatek,larb: false` in the `else` branch of
the `allOf` block for older SoCs to prevent incorrect configuration
and ensure backward compatibility.
Changes compared with v8:
- Patches 1/3 & 2/3 (dt-bindings: decoder & encoder):
- Expand the description of the `mediatek,larb` property to explicitly
explain its necessity for accurately describing the hardware topology
(SMI LARB connection for memory bandwidth arbitration), independent
of the IOMMU driver's implicit handling.
Changes compared with v7:
- Patches 1/3 (dt-bindings: decoder):
- In the allOf constraints, only keep maxItems: 1 in the then
branch and minItems: 2 in the else branch; remove duplicated
constraints already defined at the top level
Changes compared with v6:
- Patches 1/3 (dt-bindings: decoder):
update the existing `allOf` condition for mediatek,mt8189-jpgdec to
make the 'mediatek,larb' property strictly required for MT8189 SoC.
- Patches 2/3 (dt-bindings: encoder):
Add an `allOf` condition to enforce that the `mediatek,larb` property
is strictly required when the compatible string contains
mediatek,mt8189-jpgenc.
Changes compared with v5:
- Patches 1/3 (dt-bindings: decoder):
- Drop top-level minItems/maxItems for clock-names per Krzysztof's
review.
- Refine allOf block to strictly enforce clock constraints.
Changes compared with v4:
- Refines the device tree bindings for JPEG decoder and encoder.
- Patches 1/3 (dt-bindings: decoder):
Moved the standalone compatible string mediatek,mt8189-jpgdec
into the first oneOf entry along with mt2701 and mt8173, as
suggested by Rob Herring. This correctly groups all independent
ICs and removes the redundant items wrapper.
- Patches 2/3 (dt-bindings: encoder):
Applied the same logic suggested by Rob Herring to the encoder
binding. Restructured the compatible property to clearly
distinguish between the standalone IC (mediatek,mt8189-jpgenc)
and the ICs that must fallback to mediatek,mtk-jpgenc.
Changes compared with v3:
- The v4 is resending the cover-letter, because the v3 cover-letter was
not sent successfully.
Changes compared with v2:
- Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
compatible) as it belongs to a different tree/series.
- Patches 1/3 (dt-bindings: decoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum`.
- Added an `allOf` block with conditional checks to enforce the single
clock ("jpgdec") requirement for MT8189, while preserving the
two-clock requirement for older SoCs.
- Updated commit message to reflect the schema structure changes and
hardware differences.
- Patches 2/3 (dt-bindings: encoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum` inside the `items` list, as it does not fallback to
"mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
- Updated commit message to explain the standalone compatible design.
- Patches 3/3 (media: mediatek: jpeg):
- Refined commit message for better clarity regarding 34-bit IOVA and
single clock configuration.
Changes compared with v1:
- Patches 1/4:
- Updating commit message
- Patches 2/4, 3/4:
- Updating commit message
- Adjusted property descriptions acorrding to hardware requirements
- Improved formatting for better readability and consistency
- Patches 4/4:
- Updating commit message
Jianhua Lin (3):
dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
string
dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
string
media: mediatek: jpeg: add compatible for MT8189 SoC
.../bindings/media/mediatek-jpeg-decoder.yaml | 50 ++++++++++++++++---
.../bindings/media/mediatek-jpeg-encoder.yaml | 38 +++++++++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 ++++++++++++++++
3 files changed, 118 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* Re: [PATCH v2 4/7] dt-bindings: reset: Add reset controller constants for mt8167
From: Krzysztof Kozlowski @ 2026-07-20 6:28 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717163959.714561-5-l.scorcia@gmail.com>
On Fri, Jul 17, 2026 at 06:39:15PM +0200, Luca Leonardo Scorcia wrote:
> Add the various bits that identify watchdog and mmsys resets. IDs for
> mmsys resets restart from zero as they are used in a different device.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../reset/mediatek,mt8167-resets.h | 53 +++++++++++++++++++
I do not see any user of this ABI nor explanation why you are doing it.
> 1 file changed, 53 insertions(+)
> create mode 100644 include/dt-bindings/reset/mediatek,mt8167-resets.h
>
> diff --git a/include/dt-bindings/reset/mediatek,mt8167-resets.h b/include/dt-bindings/reset/mediatek,mt8167-resets.h
> new file mode 100644
> index 000000000000..85d2d0e99c68
> --- /dev/null
> +++ b/include/dt-bindings/reset/mediatek,mt8167-resets.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */
> +#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT8167
> +#define _DT_BINDINGS_RESET_CONTROLLER_MT8167
> +
> +/* TOPRGU resets, these are actual bits in the register */
> +#define MT8167_TOPRGU_DDRPHY_FLASH_RST 0
> +#define MT8167_TOPRGU_AUD_PAD_RST 1
> +#define MT8167_TOPRGU_MM_RST 2
> +#define MT8167_TOPRGU_MFG_RST 3
> +#define MT8167_TOPRGU_MDSYS_RST 4
> +#define MT8167_TOPRGU_CONN_RST 5
> +#define MT8167_TOPRGU_PAD2CAM_DIG_MIPI_RX_RST 6
> +#define MT8167_TOPRGU_DIG_MIPI_TX_RST 7
> +#define MT8167_TOPRGU_SPI_PAD_MACRO_RST 8
> +/* bit 9 is reserved, unused according to data sheet */
NAK, how driver can reserve something? Fix your driver.
This is ABI for Linux driver.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: watchdog: Add compatible for MediaTek mt8167
From: Krzysztof Kozlowski @ 2026-07-20 6:26 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717163959.714561-4-l.scorcia@gmail.com>
On Fri, Jul 17, 2026 at 06:39:14PM +0200, Luca Leonardo Scorcia wrote:
> Currently mt8167 inherits its watchdog from the included mt8516 dtsi,
> which in turn falls back on mt6589-wdt. However according to the data
> sheet mt8167 has 15 sw resets instead of 12, and their order is different
Does 15 over 12 make it incompatible?
And how does the order matter? Order where? Binding does not have even a
single reset.
> from mt6589. Update the wdt binding to add a dedicated compatible for
> mt8167.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> index 953629cb9558..f514be8a5851 100644
> --- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> @@ -26,6 +26,7 @@ properties:
> - mediatek,mt6795-wdt
> - mediatek,mt7986-wdt
> - mediatek,mt7988-wdt
> + - mediatek,mt8167-wdt
> - mediatek,mt8183-wdt
> - mediatek,mt8186-wdt
> - mediatek,mt8188-wdt
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v6 08/14] dt-bindings: media: mediatek: vcodec: add decoder dt-bindings for mt8196
From: Kyrie Wu (吴晗) @ 2026-07-20 6:26 UTC (permalink / raw)
To: krzk@kernel.org
Cc: matthias.bgg@gmail.com, fshao@chromium.org,
Yunfei Dong (董云飞), conor+dt@kernel.org,
fanwu01@zju.edu.cn, jacopo.mondi@ideasonboard.com,
haoxiang_li2024@163.com, tfiga@chromium.org,
AngeloGioacchino Del Regno,
Andrew-CT Chen (陳智迪),
linux-media@vger.kernel.org, ribalda@chromium.org,
wenst@chromium.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, kees@kernel.org,
rongqianfeng@vivo.com, Irui Wang (王瑞),
krzk+dt@kernel.org, linux-mediatek@lists.infradead.org,
Tiffany Lin (林慧珊),
sakari.ailus@linux.intel.com, benjamin.gaignard@collabora.com,
p.zabel@pengutronix.de, mchehab@kernel.org,
sebastian.fricke@collabora.com, robh@kernel.org,
linux-arm-kernel@lists.infradead.org,
nicolas.dufresne@collabora.com, hverkuil+cisco@kernel.org,
laurent.pinchart+renesas@ideasonboard.com
In-Reply-To: <f499f2c3-f31d-4c2c-84fb-d1d9d95fc868@kernel.org>
On Mon, 2026-07-20 at 07:49 +0200, Krzysztof Kozlowski wrote:
> On 20/07/2026 07:46, Krzysztof Kozlowski wrote:
> > On Mon, Jul 20, 2026 at 09:20:50AM +0800, Kyrie Wu wrote:
> > > Add the MT8196 compatible string to the MediaTek vcodec subdev
> > > decoder binding.
> > >
> > > Compared to previous ICs, the MT8196 supports a 10-bit decoder
> > > and has a decoding capability of 4K@120fps. It also supports
> > > 36-bit DRAM IOVA address and Video Power Control to optimize
> > > bandwidth and voltage usage.
> >
> > Please wrap commit message according to Linux coding style /
> > submission
> > process (neither too early nor over the limit):
> > https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst*L597__;Iw!!CTRNKA9wMg0ARbw!gDjbq0EZNkhLTzuJM_w5PopnDFej1mG4qnkRFgyoiU7Dvhm7tj3MeG5eZYNGA0L0G_61j-cmdIxORA$
> >
> >
> > >
> > > Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
> > > Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > > ---
> > > .../bindings/media/mediatek,vcodec-subdev-decoder.yaml
> > > | 1 +
> > > 1 file changed, 1 insertion(+)
> >
> > Acked-by: Krzysztof Kozlowski
> > <krzysztof.kozlowski@oss.qualcomm.com>
>
> Actually no. I checked previous comments and you received feedback
> which
> you basically ignored, so explain why this model has flexible number
> of
> clocks
>
> Best regards,
> Krzysztof
Dear Krzysztof,
As mentioned in the previous version of the communication, the
information regarding clk was incorrect, and I have corrected it in
this version.
Thank you for your attention and reminder.
Regards,
Kyrie.
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: reset: Add MT6589 toprgu reset IDs
From: Krzysztof Kozlowski @ 2026-07-20 6:25 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717163959.714561-2-l.scorcia@gmail.com>
On Fri, Jul 17, 2026 at 06:39:12PM +0200, Luca Leonardo Scorcia wrote:
> Add reset constants for the 12 MT6589 toprgu resets.
This is not a single-patch patchset. Seven patches.
So one posting per 24h, so we actually have a possibility to review it.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../reset/mediatek,mt6589-resets.h | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 include/dt-bindings/reset/mediatek,mt6589-resets.h
>
> diff --git a/include/dt-bindings/reset/mediatek,mt6589-resets.h b/include/dt-bindings/reset/mediatek,mt6589-resets.h
> new file mode 100644
> index 000000000000..ee08c39df513
> --- /dev/null
> +++ b/include/dt-bindings/reset/mediatek,mt6589-resets.h
Why is this header being added outside of patch documenting compatible?
You have entire commit msg to say something useful instead of repeating
the subject.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: Replace maintainer for Xilinx CAN driver
From: Rao, Appana Durga Kedareswara @ 2026-07-20 6:16 UTC (permalink / raw)
To: Harini T, mkl, mailhol, robh, krzk+dt, conor+dt, michal.simek
Cc: linux-can, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260717021415.2234865-2-harini.t@amd.com>
On 7/17/2026 7:44 AM, Harini T wrote:
> Replace Appana Durga Kedareswara rao with Harini T as the maintainer
> of the Xilinx CAN driver. Kedar is no longer maintaining it.
>
> Signed-off-by: Harini T <harini.t@amd.com>
> ---
> Documentation/devicetree/bindings/net/can/xilinx,can.yaml | 2 +-
> MAINTAINERS | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
> index 40835497050a..e705c719f7b5 100644
> --- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
> +++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
> @@ -8,7 +8,7 @@ title:
> Xilinx CAN and CANFD controller
>
> maintainers:
> - - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
> + - Harini T <harini.t@amd.com>
>
> properties:
> compatible:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7a2ffd9d37d5..db619dcaddbf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -28874,7 +28874,7 @@ F: Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
> F: drivers/net/ethernet/xilinx/xilinx_axienet*
>
> XILINX CAN DRIVER
> -M: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
> +M: Harini T <harini.t@amd.com>
> L: linux-can@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/net/can/xilinx,can.yaml
Acked-by: Appana Durga Kedareswara rao
<appana.durga.kedareswara.rao@amd.com>
Regards,
Kedar
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: monaco: enable audio ML offload memory and SMMU mappings
From: Krzysztof Kozlowski @ 2026-07-20 6:12 UTC (permalink / raw)
To: Pratyush Meduri
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Manivannan Sadhasivam, linux-arm-msm, linux-remoteproc,
devicetree, linux-kernel
In-Reply-To: <20260717095825.3962666-4-pratyush.meduri@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 03:28:25PM +0530, Pratyush Meduri wrote:
> The audio ML (machine-learning) offload use case requires a contiguous,
> physically addressable buffer shared with the audio DSP/SPF, and issues
> DMA transactions through additional SMMU stream IDs that are not
> covered by the existing ADSP mapping.
>
> Add a dedicated reusable shared-dma-pool CMA region (16 MiB, 4 MiB
> aligned) and wire it to the q6apm DAIs node via memory-region. A
> dedicated pool guarantees the alignment and contiguity the DSP expects
> and isolates these allocations from the default CMA region.
>
> Under the EL2 (Gunyah/hypervisor) configuration the SMMU is fully
> enforcing, so the ML transactions are otherwise blocked and faulted:
>
> arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x2060
> arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x2062
>
> Add the ML-related stream IDs (0x3060 mask 0x9, 0x3062 mask 0x1) to the
> remoteproc_adsp iommus property in the EL2 overlay so these buffers are
> translated by the SMMU instead of being rejected.
>
> Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco-el2.dtso | 4 +++-
> arch/arm64/boot/dts/qcom/monaco.dtsi | 9 +++++++++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
NAK, you keep ignoring us.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: lemans: enable audio ML offload memory and SMMU mappings
From: Krzysztof Kozlowski @ 2026-07-20 6:12 UTC (permalink / raw)
To: Pratyush Meduri
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Manivannan Sadhasivam, linux-arm-msm, linux-remoteproc,
devicetree, linux-kernel
In-Reply-To: <20260717095825.3962666-3-pratyush.meduri@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 03:28:24PM +0530, Pratyush Meduri wrote:
> The audio ML (machine-learning) offload use case requires a contiguous,
> physically addressable buffer shared with the audio DSP/SPF, and issues
> DMA transactions through additional SMMU stream IDs that are not
> covered by the existing ADSP mapping.
>
> Add a dedicated reusable shared-dma-pool CMA region (16 MiB, 4 MiB
> aligned) and wire it to the q6apm DAIs node via memory-region. A
> dedicated pool guarantees the alignment and contiguity the DSP expects
> and isolates these allocations from the default CMA region.
>
> Under the EL2 (Gunyah/hypervisor) configuration the SMMU is fully
> enforcing, so the ML transactions are otherwise blocked and faulted:
>
> arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x3060
> arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x3062
>
> Add the ML-related stream IDs (0x3060 mask 0x9, 0x3062 mask 0x1) to the
> remoteproc_adsp iommus property in the EL2 overlay so these buffers are
> translated by the SMMU instead of being rejected.
>
> Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/lemans-el2.dtso | 4 +++-
> arch/arm64/boot/dts/qcom/lemans.dtsi | 9 +++++++++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/lemans-el2.dtso b/arch/arm64/boot/dts/qcom/lemans-el2.dtso
> index 621ad930cf54..5b477346ef90 100644
> --- a/arch/arm64/boot/dts/qcom/lemans-el2.dtso
> +++ b/arch/arm64/boot/dts/qcom/lemans-el2.dtso
> @@ -19,7 +19,9 @@ &iris {
> };
>
> &remoteproc_adsp {
> - iommus = <&apps_smmu 0x3000 0x0>;
> + iommus = <&apps_smmu 0x3000 0x0>,
> + <&apps_smmu 0x3060 0x9>,
> + <&apps_smmu 0x3062 0x1>;
> };
>
> &remoteproc_cdsp0 {
> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 3b0539e27b51..060565113784 100644
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
> @@ -624,6 +624,14 @@ reserved-memory {
> #size-cells = <2>;
> ranges;
>
> + audio_cma_mem: qcom,audio-ml {
NAK. You ignore feedback and keep sending us downstream junk
directly.
DO NOT SEND downstream code. EVER.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/2] arm64: dts: qcom: lemans: enable audio ML offload memory and SMMU mappings
From: Krzysztof Kozlowski @ 2026-07-20 6:11 UTC (permalink / raw)
To: Konrad Dybcio, Pratyush Meduri, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <e3dc38a8-b2a3-437a-819b-924ab13136c6@oss.qualcomm.com>
On 16/07/2026 18:24, Konrad Dybcio wrote:
> On 7/16/26 5:18 PM, Pratyush Meduri wrote:
>>
>> &remoteproc_cdsp0 {
>> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
>> index 3b0539e27b51..060565113784 100644
>> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
>> @@ -624,6 +624,14 @@ reserved-memory {
>> #size-cells = <2>;
>> ranges;
>>
>> + audio_cma_mem: qcom,audio-ml {
>
> Node names *must not* contain commas and should be generic
That's a pure downstream code dump. Not acceptable really.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: remoteproc: qcom,pas-common: allow up to 3 iommus
From: Krzysztof Kozlowski @ 2026-07-20 6:10 UTC (permalink / raw)
To: Pratyush Meduri
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Manivannan Sadhasivam, linux-arm-msm, linux-remoteproc,
devicetree, linux-kernel
In-Reply-To: <20260717095825.3962666-2-pratyush.meduri@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 03:28:23PM +0530, Pratyush Meduri wrote:
> The ADSP PAS on several Qualcomm SoCs (e.g. SA8775P/lemans, QCS8300,
> Monaco) needs more than a single SMMU stream ID for the audio ML
> (machine-learning) offload use case. In addition to the primary
> ADSP stream ID, the DSP/SPF issues DMA transactions through extra
> stream IDs that are not covered by the existing single-entry mapping.
>
> Relax the iommus constraint to allow between 1 and 3 entries so the
> additional ML offload stream IDs can be described, fixing dtb_check
> schema violations on device trees that add them.
What dtb_check violations? Do not reference non-existing warnings. If
this is real, then place the warning here - and be sure we can actually
reproduce it.
>
> Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
> ---
> .../devicetree/bindings/remoteproc/qcom,pas-common.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> index 11faf655f530..fb656bda8527 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> @@ -33,7 +33,8 @@ properties:
> maxItems: 6
>
> iommus:
> - maxItems: 1
> + minItems: 1
> + maxItems: 3
So now all devices have three streams as well? Or only these three? You
said only newer, so why are you raising this also for sm8150?
Beside, you need to list the items.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 0/7] clk: qcom: Add common clkref support and migrate Glymur and Mahua
From: Qiang Yu @ 2026-07-20 6:10 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Kees Cook,
Gustavo A. R. Silva, Konrad Dybcio, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-hardening, Krzysztof Kozlowski,
Konrad Dybcio
In-Reply-To: <alv1Q0ZmGVdUTGCu@baldur>
On Sat, Jul 18, 2026 at 04:52:34PM -0500, Bjorn Andersson wrote:
> On Mon, Jul 13, 2026 at 09:59:35PM -0700, Qiang Yu wrote:
> > This series adds a common clkref_en implementation and converts glymur
> > and mahua to use it, along with the related binding and DTS updates.
> >
> > The PCIe clkref clocks on Glymur and Mahua gate the QREF block which
> > provides reference clocks to the PCIe PHYs. QREF requires LDO supplies
> > and a reference voltage from the refgen block to operate. The refgen
> > block itself requires vdda-refgen_0p9 and vdda-refgen_1p2 LDOs to
> > function.
> >
> > Previously, these QREF votes were done in PHY drivers. In earlier
> > discussion [1], the feedback was that this is the wrong ownership point:
> > those supplies are for the QREF controlled by clkref registers, not for
> > the PHY directly. Based on that feedback, this series keeps the
> > regulator handling with the clkref control path.
> >
> > Another reason for this series is reuse. clkref_en registers may live in
> > different blocks across platforms (for example TCSR on Glymur, TLMM on
> > SM8750 [2]), while the behavior is the same. The common helper lets each
> > driver provide simple descriptors (name, offset, optional supplies) and
> > reuse shared registration and runtime logic.
> >
> > Glymur and Mahua share the same QREF TX/RPT/RX component naming but
> > have different PCIe QREF topologies. Both are handled in tcsrcc-glymur.c
> > via match_data to select the correct descriptor table per compatible.
> >
> > [1] https://lore.kernel.org/lkml/aEBfV2M-ZqDF7aRz@hovoldconsulting.com/
> > [2] https://lore.kernel.org/linux-arm-msm/20260202-topic-8750_tcsr-v1-0-cd7e6648c64f@oss.qualcomm.com/
> >
> > Changes in v9:
> > - Add reviewed-by tags, no code change.
> > - Link to v8: https://lore.kernel.org/all/20260708-tcsr_qref_0708-v8-0-62c42b5fa269@oss.qualcomm.com/
> >
> > Changes in v8:
> > - Define refs with __counted_by(num_refs) and make provider a single allocation
> > - Use mahua_tcsr_tx1_rpt012_rx2_regulators for PCIe6.
> > - Link to v7: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
> >
> > Changes in v7:
> > - Define compatible as an enum and add the per-compatible allOf/if/then block upfront for glymur. Reword commit msg for patch1
> > - Drop Krzysztof's Reviewed-by since the patch changed substantially from what he reviewed.
> > - Added a comment noting that on Mahua the REFGEN4 block is supplied by the vdda-refgen3-* regulators, and mentioned this in the commit message for patch2.
> > - Change the descriptor array to an array of pointers (const struct qcom_clk_ref_desc * const *). Skip unpopulated indices with if (!desc)
> > - Convert tcsr_cc_glymur_clk_descs[] and tcsr_cc_mahua_clk_descs[] to a pointer array.
> > - Add regulator lists for clkref_en on Mahua.
> > - Null-check device_get_match_data() result in probe.
> > - Add rx0 regulator in mahua tcsr node
> > - Squashed the former patch 8 (switch pcie5_phy ref clock to RPMH_CXO_CLK) into patch7, so Mahua PCIe probes at every commit.
> > - Link to v6: https://lore.kernel.org/all/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com/
> >
> > Changes in v6:
> > - Split dt-bindings patch into two: one to move glymur-tcsr to its own
> > binding file, and one to add mahua support
> > - Use regmap_set_bits()/regmap_clear_bits() instead of regmap_update_bits()
> > in clk-ref.c
> > - Move clk_init_data from struct qcom_clk_ref to a stack variable in
> > qcom_clk_ref_register()
> > - Add Co-developed-by/Reviewed-by tags from Konrad Dybcio
> > - Add missing regulator supplies for EDP and USB clkref_en on glymur
> > - Link to v5: https://patch.msgid.link/20260602-tcsr_qref_0527-v5-0-8ea174a59d7e@oss.qualcomm.com
> >
> > Changes in v5:
> > - Return 0 if regmap_read fail
> > - Add a separate file for glymur-tcsr and mahua-tcsr
> > - Link to v4: https://patch.msgid.link/20260527-tcsr_qref_0527-v4-0-ded83866c9d9@oss.qualcomm.com
> >
> > Changes in v4:
> > - Add mahua QREF support (binding, driver, DTS) to avoid dtb check error
> > - Override pcie5_phy ref clock to RPMH_CXO_CLK on mahua since
> > TCSR_PCIE_1_CLKREF_EN is not available
> > - Rename regulator arrays to topology-based names and merge duplicates
> > - Remove else: false blocks from binding
> > - Sort supply properties alphabetically in binding and DTS
> > - Link to v3: https://lore.kernel.org/all/20260506-qref_vote_0506-v3-0-5ab71d2e6f16@oss.qualcomm.com/
> >
> > Changes in v3:
> > - Fix dtb check error: allOf:0: 'then' is a dependency of 'if'.
> > - Link to v2: https://lore.kernel.org/all/20260420-vote_qref_in_tcsrcc-v2-0-589a23ae640a@oss.qualcomm.com/
> >
> > Changes in v2:
> > - RFC tag dropped
> > - Changed back to additionalProperties: false
> > - Moved all Glymur supply properties into top-level properties so they are explicitly defined.
> > - Link to v1: https://lore.kernel.org/all/20260331-qref_vote-v1-0-3fd7fbf87864@oss.qualcomm.com/
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > Qiang Yu (7):
> > dt-bindings: clock: qcom: Move glymur TCSR to own binding
> > dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
> > clk: qcom: Add generic clkref_en support
> > clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper
> > clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
> > arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
> > arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
> >
> > .../bindings/clock/qcom,glymur-tcsr.yaml | 146 +++++++
> > .../bindings/clock/qcom,sm8550-tcsr.yaml | 2 -
> > arch/arm64/boot/dts/qcom/glymur-crd.dts | 20 +
> > arch/arm64/boot/dts/qcom/mahua-crd.dts | 16 +
> > arch/arm64/boot/dts/qcom/mahua.dtsi | 13 +
> > drivers/clk/qcom/Makefile | 1 +
> > drivers/clk/qcom/clk-ref.c | 205 +++++++++
> > drivers/clk/qcom/tcsrcc-glymur.c | 471 +++++++++++----------
> > include/linux/clk/qcom.h | 67 +++
> > 9 files changed, 704 insertions(+), 237 deletions(-)
> > ---
> > base-commit: 3da905eb243cad56200f09bb7eaa060537aed0cc
>
> I was hoping to apply this series, but I don't have this commit and
> patch 4 ("migrate to clk_ref helper") doesn't apply to my tree.
>
> What did you base this on? Why don't you test your changes on latest
> mainline or linux-next?
>
> Please rebase and test on a relevant branch.
Sorry for the trouble, I based v9 on next-20260713, but I forgot to
drop this patch
https://lore.kernel.org/all/20260420133616.88740-2-krzysztof.kozlowski@oss.qualcomm.com/,
which is a dependency for another series I'm working on, before
running b4 prep -n.
I can git am v9 cleanly onto latest linux-next (next-20260717), but
I'm not sure if that's the branch you apply against. Could you
confirm which branch I should rebase onto, so I don't run into the
same issue again?
- Qiang Yu
^ 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