* [PATCH v9 0/3] thermal: imx: Add temperature offset support
From: Haoning CHENG via B4 Relay @ 2026-07-17 6:35 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: linux-pm, devicetree, imx, linux-arm-kernel, linux-kernel,
Haoning CHENG, Krzysztof Kozlowski, Frank Li
Some i.MX boards need the reported temperature to represent the SoC
package-surface temperature rather than the internal die temperature.
This series adds an optional DT property to specify a board-specific
conversion offset and implements the corresponding support in the
imx_thermal driver.
Patch 1 documents the new fsl,temp-calibration-offset-millicelsius
property in the i.MX thermal DT binding. The offset is board-specific,
determined through thermal characterization, and limited to ±20 °C.
Patch 2 fixes the i.MX7D alarm temperature conversion to use
ceiling division (DIV_ROUND_UP() for non-negative, plain /
for negative) and clamp() to stay within the 9-bit register range.
Patch 3 reads this property in the imx_thermal driver and applies
the offset symmetrically: it is added when reporting temperature to
the thermal framework (to produce a package-surface estimate) and
subtracted when programming hardware alarm thresholds (to keep trip
point semantics consistent). Out-of-range values are rejected with
-EINVAL at probe time. When the property is absent, the default
offset is 0.
Signed-off-by: Haoning CHENG <Haoning.CHENG@cn.bosch.com>
---
Changes in v9:
- Rephrase the series to clarify that the offset converts the internal
TEMPMON reading to a package-surface temperature estimate, rather than
calibrating the sensor for better die temperature accuracy (Frieder)
- dt-bindings: update the property description to explicitly state it is
a board-specific conversion offset, not a sensor calibration
- driver commit message: distinguish die temperature from package-surface
temperature in the symmetric offset mechanism explanation
- Pick up Reviewed-by tags from Frank Li (patches 2,3) and Lukasz Luba
(patches 1,2,3)
- Link to v8: https://patch.msgid.link/20260714-b4-symana21-11221-imx-thermal-support-upstream-6-18-v8-0-d54d8690e16e@cn.bosch.com
Changes in v8:
- binding: s/behaviour/behavior/ (Lukasz)
- New prep patch: use ceiling division (DIV_ROUND_UP() for non-negative, plain /
for negative) and clamp() for i.MX7D, extracted into a separate patch (Frank)
- driver commit message: add offset mechanism explanation with a +3000 m°C calculation example (Lukasz)
- probe: reject out-of-range offset with -EINVAL instead of silently clamping (Lukasz)
- prep patch: handle negative alarm_temp with plain division (C rounds toward zero)
- Link to v7: https://patch.msgid.link/20260713-b4-symana21-11221-imx-thermal-support-upstream-6-18-v7-0-09b6b7669be1@cn.bosch.com
Changes in v7:
- Align the author name with the Signed-off-by trailer.
- Link to v6: https://patch.msgid.link/20260713-b4-symana21-11221-imx-thermal-support-upstream-6-18-v6-0-88a378faeca5@cn.bosch.com
Changes in v6:
- Align the author name with the Signed-off-by trailer.
- Link to v5: https://patch.msgid.link/20260713-b4-symana21-11221-imx-thermal-support-upstream-6-18-v5-0-69405c306c6b@cn.bosch.com
Changes in v5:
- Move calibration offset application out of c2 initialization, instead
apply it in imx_get_temp(), imx_set_alarm_temp() and imx_set_panic_temp()
for consistent style across i.MX6 and i.MX7D
- Subtract calibration offset from alarm_temp before the if-else block in
imx_set_alarm_temp(), simplifying both SoC branches (Frank's suggestion)
- Link to v4: https://patch.msgid.link/20260710-b4-symana21-11221-imx-thermal-support-upstream-6-18-v4-0-1fef97d1c750@cn.bosch.com
Changes in v4:
- dt-bindings: drop maxItems to allow minimum/maximum constraints for
temp-calibration-offset-millicelsius
- Link to v3: https://patch.msgid.link/20260710-b4-symana21-11221-imx-thermal-support-upstream-6-18-v3-0-db9fc2947c55@cn.bosch.com
Changes in v3:
- dt-bindings: add minimum/maximum (-28580/+28580) for
temp-calibration-offset-millicelsius, as suggested by Conor Dooley
- Link to v2: https://patch.msgid.link/20260709-b4-symana21-11221-imx-thermal-support-upstream-6-18-v2-0-00ff72495e24@cn.bosch.com
Changes in v2:
- dt-bindings: Removed explicit `$ref: /schemas/types.yaml#/definitions/int32`
for fsl,temp-calibration-offset-millicelsius; the `-millicelsius` suffix
already resolves to int32-array via property-units.yaml (Rob).
- dt-bindings: Fixed example indentation.
- driver: Replaced C integer division (/) with DIV_ROUND_CLOSEST() in
imx_set_alarm_temp() to prevent off-by-one alarm threshold mismatch that
could cause IRQ storms on i.MX7D.
- driver: Added clamp() bounds check for alarm_value [0, 0x1ff] to avoid
corrupting adjacent register fields (PANIC_ALARM).
- Link to v1: https://patch.msgid.link/20260709-b4-symana21-11221-imx-thermal-support-upstream-6-18-v1-0-00f88f42930b@cn.bosch.com
To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Lukasz Luba <lukasz.luba@arm.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Shawn Guo <shawnguo@kernel.org>
To: Sascha Hauer <s.hauer@pengutronix.de>
To: Pengutronix Kernel Team <kernel@pengutronix.de>
To: Fabio Estevam <festevam@gmail.com>
Cc: linux-pm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Haoning CHENG (3):
dt-bindings: thermal: imx: Document temperature offset property
thermal/drivers/imx: Fix rounding and clamp for i.MX7D alarm
thermal/drivers/imx: Add temperature offset support
.../devicetree/bindings/thermal/imx-thermal.yaml | 15 +++++++++
drivers/thermal/imx_thermal.c | 39 ++++++++++++++++++++--
2 files changed, 51 insertions(+), 3 deletions(-)
---
base-commit: c50a940dcde35c647e097e89a9150003abd48329
change-id: 20260709-b4-symana21-11221-imx-thermal-support-upstream-6-18-a084984deb76
Best regards,
--
Haoning Cheng <Haoning.CHENG@cn.bosch.com>
^ permalink raw reply
* [PATCH v9 3/3] thermal/drivers/imx: Add temperature offset support
From: Haoning CHENG via B4 Relay @ 2026-07-17 6:35 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: linux-pm, devicetree, imx, linux-arm-kernel, linux-kernel,
Haoning CHENG, Frank Li
In-Reply-To: <20260717-b4-symana21-11221-imx-thermal-support-upstream-6-18-v9-0-75f4af8974f4@cn.bosch.com>
From: Haoning CHENG <Haoning.CHENG@cn.bosch.com>
Some boards need a small per-design offset to make the TEMPMON reading
better correspond to the SoC package-surface temperature. This is not a
sensor calibration that improves the die temperature accuracy; it is a
board-specific conversion from the internal sensor reading to a
package-surface temperature estimate required by certain applications.
Read the optional fsl,temp-calibration-offset-millicelsius property from
DT and apply it uniformly to the i.MX6/6SX/7D formulas.
The offset is applied symmetrically at two points to keep the trip point
semantics consistent:
1. In imx_set_alarm_temp() and imx_set_panic_temp(): the temperature
threshold is *subtracted* by the offset before being converted to a
hardware register value. This shifts the hardware IRQ trigger to the
die temperature that corresponds to the intended package-surface
threshold.
2. In imx_get_temp(): after computing the die temperature from the
hardware register, the offset is *added* to produce a value that
better correlates with the package-surface temperature. The thermal
framework always sees this package-surface estimate.
For example, if DT sets offset = +3000 m°C and the passive trip is 95°C:
imx_set_alarm_temp(95000):
alarm_temp = 95000 - 3000 = 92000
→ hardware register programmed for 92°C die temperature
Hardware IRQ fires at 92°C die temperature
imx_get_temp():
reads hardware, computes 92°C die temperature
*temp = 92000 + 3000 = 95000
→ thermal framework sees 95°C → correct trip
When the property is not present, the offset defaults to 0, preserving
the current behavior.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Haoning Cheng <Haoning.CHENG@cn.bosch.com>
---
drivers/thermal/imx_thermal.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 7f7d1116b9d6..d471acc16bce 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -85,6 +85,10 @@ enum imx_thermal_trip {
#define TEMPMON_IMX6SX 2
#define TEMPMON_IMX7D 3
+/* Calibration offset limits (±20 °C in millicelsius) */
+#define IMX_TEMP_CALIB_OFFSET_MIN (-20000)
+#define IMX_TEMP_CALIB_OFFSET_MAX 20000
+
struct thermal_soc_data {
u32 version;
@@ -207,6 +211,7 @@ struct imx_thermal_data {
struct regmap *tempmon;
u32 c1, c2; /* See formula in imx_init_calib() */
int temp_max;
+ s32 calibration_offset;
int alarm_temp;
int last_temp;
bool irq_enabled;
@@ -223,6 +228,7 @@ static void imx_set_panic_temp(struct imx_thermal_data *data,
struct regmap *map = data->tempmon;
int critical_value;
+ panic_temp -= data->calibration_offset;
critical_value = (data->c2 - panic_temp) / data->c1;
regmap_write(map, soc_data->panic_alarm_ctrl + REG_CLR,
@@ -239,6 +245,7 @@ static void imx_set_alarm_temp(struct imx_thermal_data *data,
int alarm_value;
data->alarm_temp = alarm_temp;
+ alarm_temp -= data->calibration_offset;
if (data->socdata->version == TEMPMON_IMX7D) {
if (alarm_temp >= 0)
@@ -283,6 +290,7 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
*temp = (n_meas - data->c1 + 25) * 1000;
else
*temp = data->c2 - n_meas * data->c1;
+ *temp += data->calibration_offset;
/* Update alarm value to next higher trip point for TEMPMON_IMX6Q */
if (data->socdata->version == TEMPMON_IMX6Q) {
@@ -635,6 +643,25 @@ static int imx_thermal_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
+ if (of_property_present(dev->of_node,
+ "fsl,temp-calibration-offset-millicelsius")) {
+ ret = of_property_read_s32(dev->of_node,
+ "fsl,temp-calibration-offset-millicelsius",
+ &data->calibration_offset);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to read calibration offset\n");
+
+ if (data->calibration_offset < IMX_TEMP_CALIB_OFFSET_MIN ||
+ data->calibration_offset > IMX_TEMP_CALIB_OFFSET_MAX)
+ return dev_err_probe(dev, -EINVAL,
+ "calibration offset %d millicelsius out of range\n",
+ data->calibration_offset);
+
+ dev_dbg(dev, "calibration offset: %d millicelsius\n",
+ data->calibration_offset);
+ }
+
if (of_property_present(dev->of_node, "nvmem-cells")) {
ret = imx_init_from_nvmem_cells(pdev);
if (ret)
--
2.43.0
^ permalink raw reply related
* [PATCH v9 2/3] thermal/drivers/imx: Fix rounding and clamp for i.MX7D alarm
From: Haoning CHENG via B4 Relay @ 2026-07-17 6:35 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: linux-pm, devicetree, imx, linux-arm-kernel, linux-kernel,
Haoning CHENG, Frank Li
In-Reply-To: <20260717-b4-symana21-11221-imx-thermal-support-upstream-6-18-v9-0-75f4af8974f4@cn.bosch.com>
From: Haoning CHENG <Haoning.CHENG@cn.bosch.com>
Convert the alarm temperature from millicelsius to degrees for i.MX7D
using ceiling division instead of integer division, ensuring rounding
errors do not cause the alarm to trigger below the intended threshold.
Use DIV_ROUND_UP() for non-negative values and plain integer division
for negative values, since C rounds toward zero which is equivalent to
ceiling when the divisor is positive.
Add clamp() to ensure the hardware register value stays within the 9-bit
range (0..0x1ff) of the i.MX7D alarm field, preventing silent truncation
if an out-of-range value is written.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Haoning Cheng <Haoning.CHENG@cn.bosch.com>
---
drivers/thermal/imx_thermal.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 38c993d1bcb3..7f7d1116b9d6 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -240,10 +240,16 @@ static void imx_set_alarm_temp(struct imx_thermal_data *data,
data->alarm_temp = alarm_temp;
- if (data->socdata->version == TEMPMON_IMX7D)
- alarm_value = alarm_temp / 1000 + data->c1 - 25;
- else
+ if (data->socdata->version == TEMPMON_IMX7D) {
+ if (alarm_temp >= 0)
+ alarm_temp = DIV_ROUND_UP(alarm_temp, 1000);
+ else
+ alarm_temp /= 1000;
+ alarm_value = alarm_temp + data->c1 - 25;
+ alarm_value = clamp(alarm_value, 0, 0x1ff);
+ } else {
alarm_value = (data->c2 - alarm_temp) / data->c1;
+ }
regmap_write(map, soc_data->high_alarm_ctrl + REG_CLR,
soc_data->high_alarm_mask);
--
2.43.0
^ permalink raw reply related
* [PATCH v9 1/3] dt-bindings: thermal: imx: Document temperature offset property
From: Haoning CHENG via B4 Relay @ 2026-07-17 6:35 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: linux-pm, devicetree, imx, linux-arm-kernel, linux-kernel,
Haoning CHENG, Krzysztof Kozlowski
In-Reply-To: <20260717-b4-symana21-11221-imx-thermal-support-upstream-6-18-v9-0-75f4af8974f4@cn.bosch.com>
From: Haoning CHENG <Haoning.CHENG@cn.bosch.com>
Some boards need the reported temperature to reflect the SoC
package-surface temperature rather than the internal die temperature.
Document the optional fsl,temp-calibration-offset-millicelsius property,
a signed offset in millicelsius applied to the internally measured
temperature to make it better correspond to the package-surface
temperature. The offset is board-specific and is determined through
thermal characterization. When absent, the offset is zero.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Haoning CHENG <Haoning.CHENG@cn.bosch.com>
---
.../devicetree/bindings/thermal/imx-thermal.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
index 949b154856c5..6c268d56291b 100644
--- a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
@@ -59,6 +59,20 @@ properties:
clocks:
maxItems: 1
+ fsl,temp-calibration-offset-millicelsius:
+ minimum: -20000
+ maximum: 20000
+ description:
+ A signed offset, in millicelsius, added to the calculated
+ sensor temperature to make the TEMPMON reading better correspond
+ to the SoC package-surface temperature observed during board-level
+ thermal characterization. This is not a sensor calibration offset;
+ it is a board-specific conversion offset derived from the
+ relationship between the internal sensor reading and the
+ package-surface temperature, which depends on the package, PCB
+ layout, cooling arrangement, and operating environment. The range
+ is limited to ±20 °C. When absent, no offset is applied.
+
"#thermal-sensor-cells":
const: 0
@@ -109,6 +123,7 @@ examples:
nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
nvmem-cell-names = "calib", "temp_grade";
clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>;
+ fsl,temp-calibration-offset-millicelsius = <(-6400)>;
#thermal-sensor-cells = <0>;
};
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v7 01/13] dt-bindings: phy: Add zx297520v3 USB phy documentation
From: Krzysztof Kozlowski @ 2026-07-17 6:32 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, Vinod Koul,
Neil Armstrong, Russell King, linux-clk, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <20260717-zx29clk-v7-1-408411cfcf36@gmail.com>
On Fri, Jul 17, 2026 at 12:35:37AM +0300, Stefan Dösinger wrote:
> This binding will be used as a subnode of topcrm, which will be added in
> the next patch.
Irrelevant, drop. Also not true, because next patch is driver patch.
>
> Why is this a child node and not #phy-cells added to topcrm itself,
> like clocks and resets as writing-bindings.rst suggests? Because
> of_phy_provider_register checks if the of_node the PHY provider is added
> to belongs to the device or is a child of the device, so I can't put the
> PHY driver into an MFD (or AUX) child without its own node.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
> How do I handle examples? It would be identical to the example in
> topcrm. The example needs the reset defines from the next patch in
> either case.
1. No, it does not need. Just use whatever numbers.
2. Other code would give you the hint: one example in parent's schema.
> ---
> .../bindings/phy/zte,zx297520v3-usb-phy.yaml | 96 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/phy/phy-zte-zx297520v3-usb.h | 12 +++
> 3 files changed, 110 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.yaml b/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.yaml
> new file mode 100644
> index 000000000000..8bad9365d5cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/zte,zx297520v3-usb-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ZTE zx297520v3 USB and HSIC PHY
> +
> +maintainers:
> + - Stefan Dösinger <stefandoesinger@gmail.com>
> +
> +description: |
> + This PHY is found on zx297520v3 boards. It has no configurability on its own,
> + but it does require a correct reset and wait sequence to initialize. It can
> + provide interrupt notification when USB is connected and disconnected.
> +
> + The phy is a component of the board's topcrm controller. The hardware needs to
> + be declared as a child node of the zte,zx297520v3-topcrm node.
> +
> + The register space and IRQs always account for two PHYs: One USB 2.0 OTG phy
> + and a HSIC PHY. Not all boards have both. If one is missing, the corresponding
> + ready flag will never be set.
> +
> + The "include/dt-bindings/phy/phy-zte-zx297520v3-usb.h" header contains the
> + definition for the PHY indices.
> +
> +properties:
> + compatible:
> + const: zte,zx297520v3-usb-phy
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + items:
> + - description: IRQ reporting USB connection
> + - description: IRQ reporting USB disconnection
> + - description: IRQ reporting HSIC connection
> + - description: IRQ reporting HSIC disconnection
> +
> + interrupt-names:
> + items:
> + - const: usb-up
> + - const: usb-down
> + - const: hsic-up
> + - const: hsic-down
> +
> + resets:
> + items:
> + - description: USB phy reset
> + - description: HSIC phy reset
Why do you reference here resets from the parent? That's a clear signal
you have one device, so one device node regardless of Linux phy core
behavior.
> +
> + reset-names:
> + items:
> + - const: usb
> + - const: hsic
> +
> + "#phy-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-names
> + - resets
> + - reset-names
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/phy/phy-zte-zx297520v3-usb.h>
> +
> + topcrm: clock-controller {
> + compatible = "zte,zx297520v3-topcrm", "syscon";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #reset-cells = <1>;
Drop node, you have warnings.
> +
> + usb-phy@84 {
> + compatible = "zte,zx297520v3-usb-phy";
> + reg = <0x84>;
> + interrupts = <GIC_SPI 42 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 43 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 45 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 46 IRQ_TYPE_EDGE_RISING>;
Align it properly/
> + interrupt-names = "usb-up", "usb-down", "hsic-up", "hsic-down";
> + resets = <&topcrm 18>,
> + <&topcrm 20>;
Same here.
> + reset-names = "usb", "hsic";
> + #phy-cells = <1>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8729cea57c3d..cb50c2e3b4ea 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3878,8 +3878,10 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Odd fixes
> F: Documentation/arch/arm/zte/
> F: Documentation/devicetree/bindings/arm/zte.yaml
> +F: Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.yaml
> F: arch/arm/boot/dts/zte/
> F: arch/arm/mach-zte/
> +F: include/dt-bindings/phy/phy-zte-zx297520v3-usb.h
>
> ARM/ZYNQ ARCHITECTURE
> M: Michal Simek <michal.simek@amd.com>
> diff --git a/include/dt-bindings/phy/phy-zte-zx297520v3-usb.h b/include/dt-bindings/phy/phy-zte-zx297520v3-usb.h
> new file mode 100644
> index 000000000000..8a0a3ccbdd63
> --- /dev/null
> +++ b/include/dt-bindings/phy/phy-zte-zx297520v3-usb.h
Filename MUST match compatible.
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (C) Stefan Dösinger.
> + */
> +
> +#ifndef __DT_BINDINGS_PHY_USB_ZX297520V3_H
> +#define __DT_BINDINGS_PHY_USB_ZX297520V3_H
> +
> +#define ZX297520V3_USB_PHY 0
> +#define ZX297520V3_HSIC_PHY 1
> +
> +#endif /* __DT_BINDINGS_PHY_USB_ZX297520V3_H */
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [RFC PATCH 06/10] net: pcs: xpcs: improve SGMII AN state handling for Rockchip RK3568
From: Coia Prant @ 2026-07-17 6:28 UTC (permalink / raw)
To: Jiawen Wu
Cc: Andrew Lunn, kuba, davem, edumazet, pabeni, andrew+netdev, robh,
krzk+dt, heiko, netdev, linux-rockchip, devicetree,
linux-arm-kernel, linux-phy, Mengyuan Lou
In-Reply-To: <000c01dd1593$2ac0b0f0$804212d0$@trustnetic.com>
Jiawen Wu <jiawenwu@trustnetic.com> 于2026年7月17日周五 10:23写道：
>
> On Wed, Jul 15, 2026 7:05 AM, Coia Prant wrote:
> > Andrew Lunn <andrew@lunn.ch> 于2026年7月15日周三 06:44写道：
> > >
> > > On Wed, Jul 15, 2026 at 03:08:34AM +0800, Coia Prant wrote:
> > > > Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> > >
> > > You do not appear to Cc: the Wangxun NIC people. It would be good to
> > > have there comments on this change.
> >
> > I apologize; the output from get_maintainer.pl is very long. I’ve
> > heard that having too many recipients can cause the PATCH to be
> > rejected by the LKML mail server.
> >
> > I have added Wangxun maintainer (Jiawen Wu <jiawenwu@trustnetic.com>
> > and Mengyuan Lou <mengyuanlou@net-swift.com>) to the CC list.
> >
> > > > Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> > > > Signed-off-by: Coia Prant <coiaprant@gmail.com>
> > >
> > > Please don't mix fixed and new code. Is this a real fix? Should it be
> > > back ported to stable?
> >
> > I am not sure if this is a specific characteristic of Wangxun NICs, as
> > I do not have any available for testing.
> >
> > The behavior of the Rockchip DW XPCS IP core matches what is described
> > in the commit message (even though phylink brings the link to down
> > based on the phydev link status).
> >
> > This appears to be a bug (at least on Rockchip platforms) or Wangxun
> > NICs features.
> >
> > However, I cannot confirm whether Wangxun NICs behave the same way.
> > Therefore, I have kept their code as is for now.
> >
> > Could a Wangxun NICs maintainer provide some feedback based on testing?
> >
> > If we can confirm that this is indeed a bug, I can submit a separate fix.
> >
> > I would greatly appreciate it.
> >
> > Thanks.
>
> Hi Coia,
>
> I have tested this patch and it works on Wangxun NICs, thanks.
>
> The commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> is too long ago for me to recall exactly what that thought was.
>
> The log shows:
>
> "On this device, CL37_ANSGM_STS (bit[4:1] of VR_MII_AN_INTR_STS) indicates
> the status received from remote link during the auto-negotiation, and
> self-clear after the auto-negotiation is complete.
> Meanwhile, CL37_ANCMPLT_INTR will be set to 1, to indicate CL37 AN is
> complete. So add another way to get the state for CL37 SGMII."
>
> I tried to reproduce this issue, but it didn't seem to exist.
> In the current logic:
>
> link up -> read status from CL37_ANSGM_STS -> CL37_ANCMPLT_INTR not clear
> link down -> read status from BMCR -> CL37_ANCMPLT_INTR clear
>
> It also works, although CL37_ANCMPLT_INTR is not cleared every time, and AN
> restart is absent. But BMCR looks like it only wants to be return as 0, it is
> weird.
>
> So I think Wangxun NICs also can be applied to general code as well, for
> getting state in C37 SGMII mode.
Hi Jiawen,
Thanks so much for testing and confirming that the patch works on Wangxun
NICs. That's a huge relief.
You're right to ask about the CL37_ANCMPLT_INTR clear and ANRESTART. Let
me explain what I observed on RK3568.
The key difference is that on RK3568's XPCS, we're working in the MAC
side (TX_CONFIG = 0), whereas on Wangxun it seems you're in the PHY side
(TX_CONFIG = 1). This is based on the commit 2a22b7ae2fa3 where you set
TX_CONFIG = 1.
> However, I am wondering whether CL37_ANCMPLT_INTR clear and ANRESTART are
> necessary.
On the RK3568 (MAC side), according to the DesignWare XPCS TRM, the
hardware behavior is as follows:
- After a software reset (BMCR_RESET), ANENABLE is automatically set to 1
(the hardware reset value). So auto-negotiation starts automatically.
- When the link is up, CL37_ANSGM_STS contains the negotiated speed/duplex
and the link status.
- When the link goes down, CL37_ANSGM_STS becomes all zero, but
CL37_ANCMPLT_INTR remains set to 1.
- Crucially, the PCS does **not** automatically restart AN when the link
comes back up. Without an explicit ANRESTART, the link stays down
forever.
So on RK3568, the ANRESTART is mandatory to recover from a link-down
event. Without it, the link never comes back up after a cable disconnect.
In my current logic:
1. If CL37_ANSGM_STS has valid speed/duplex bits, report the link as up
and return.
2. If CL37_ANSGM_STS is zero but CL37_ANCMPLT_INTR is set, the link is
down. We clear the interrupt and issue an ANRESTART to start a new
negotiation.
This works reliably on RK3568 in SGMII MAC side mode.
Since you confirmed that the general code path also works on Wangxun, I
wonder: does the ANRESTART also work on your side? If yes, perhaps we can
make this the common path for all hardware, not just RK3568.
If you can test the ANRESTART logic on Wangxun and it works, I'd be happy
to submit a standalone fix that makes this the common code path.
Otherwise, the current approach (skipping the ANRESTART trigger on
Wangxun NICs in c37_sgmii_get_state) remains safe.
If you're comfortable with the change, I'd appreciate it if you could add
your Tested-by tag to the commit. I'll also make sure to include you on
the CC list for any future revisions or related fixes.
Thanks again for testing!
^ permalink raw reply
* Re: [PATCH v8 3/3] thermal/drivers/imx: Add calibration offset support
From: CHENG Haoning (BCSC/ENG1) @ 2026-07-17 6:23 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5a000235-5e17-4d54-8bbe-42fda0b59db0@kontron.de>
On Wed, Jul 15, 2026 at 11:06:07AM +0200, Frieder Schrempf wrote:
> On 14.07.26 12:28, Haoning CHENG via B4 Relay wrote:
> > Some boards need a small per-design correction to align the reported CPU
> > temperature with board-level measurements. Read the optional
> > fsl,temp-calibration-offset-millicelsius property from DT and apply it
> > uniformly to the i.MX6/6SX/7D calibration formulas.
>
> Sorry to chime in so late. I just want to understand what this
> calibration offset is about. Why would there be a need of a
> board-specific offset? The sensor is in the SoC and if you add a
> board-specific offset, you no longer measure the SoC core temperature,
> right?
>
> How would you determine the offset in the first place? How would I know
> what fsl,temp-calibration-offset-millicelsius should be set to? I could
> put a sensor on the SoC case and use the delta as offset, but then I
> would just account for the thermal resistance of the casing and not
> measure the SoC core temperature anymore, right?
Hi Frieder,
Thanks for pointing this out. Your understanding is correct: after
applying the offset, the reported value no longer represents the raw
SoC die or junction temperature.
For this board, the required "SoC temperature" is the package-surface
temperature. The offset was derived by comparing the TEMPMON reading
against a calibrated external sensor placed near the SoC package
surface under steady-state thermal conditions, and is used to
approximate the package-surface temperature from the internal TEMPMON
reading.
The Linux thermal framework does not require a thermal zone to use a
specific temperature reference. It only requires the reported
temperature and trip points to use the same temperature domain.
In this driver, the offset is added in get_temp() and subtracted in
set_alarm() and set_panic() when programming the hardware thresholds.
This keeps the reported temperature and trip points in the same
package-surface temperature domain. Doing this in the driver is
necessary because the hardware alarm thresholds must also be offset-
corrected; applying the offset only in userspace would cause the
TEMPMON IRQ to fire at the wrong die temperature.
I agree that "calibration offset" is misleading, since this does not
calibrate TEMPMON to a more accurate junction temperature. In the next
revision, the commit messages and DT binding have been updated to
describe this as a board-specific conversion offset from the internal
sensor reading to an estimated package-surface temperature.
Thanks,
Haoning
^ permalink raw reply
* Re: [PATCH V17 2/9] dt-bindings: iio: imu: icm42600: Add icm42607
From: Krzysztof Kozlowski @ 2026-07-17 6:21 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,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260716182637.24310-3-macroalpha82@gmail.com>
On Thu, Jul 16, 2026 at 01:26:29PM -0500, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add the ICM42607 and ICM42607P inertial measurement unit.
>
> This device is functionally very similar to the icm42600 series with a
> very different register layout. The icm42607 currently does not use an
> interrupt because wake on movement and buffers are not supported, and
> cannot be implemented on my test device which lacks an interrupt line.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
> .../bindings/iio/imu/invensense,icm42600.yaml | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 2/2] iio: adc: add Axiado SARADC driver
From: Petar Stepanovic @ 2026-07-17 5:53 UTC (permalink / raw)
To: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Petar Stepanovic
In-Reply-To: <20260716-axiado-ax3000-ax3005-saradc-v4-0-810527a9d27f@axiado.com>
Add support for the SARADC controller found on Axiado AX3000 and
AX3005 SoCs.
The driver supports single-shot voltage reads through the IIO
subsystem. The number of available input channels is selected from
the SoC match data, allowing AX3000 and AX3005 variants to use the
same driver.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
MAINTAINERS | 1 +
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axiado_saradc.c | 286 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 299 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d6f4febfe4fd..d2e99c2260fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4319,6 +4319,7 @@ M: Prasad Bolisetty <pbolisetty@axiado.com>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml
+F: drivers/iio/adc/axiado_saradc.c
AXIS ARTPEC ARM64 SoC SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a9dedbb8eb46..c6fe026dc70e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -631,6 +631,17 @@ config AT91_SAMA5D2_ADC
To compile this driver as a module, choose M here: the module will be
called at91-sama5d2_adc.
+config AXIADO_SARADC
+ tristate "Axiado SARADC driver"
+ depends on ARCH_AXIADO || COMPILE_TEST
+ select REGMAP_MMIO
+ help
+ Say yes here to build support for the SARADC found in Axiado
+ SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called axiado_saradc.
+
config AXP20X_ADC
tristate "X-Powers AXP20X and AXP22X ADC driver"
depends on MFD_AXP20X
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 097357d146ba..96de0ce1d90a 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_ADI_AXI_ADC) += adi-axi-adc.o
obj-$(CONFIG_ASPEED_ADC) += aspeed_adc.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
+obj-$(CONFIG_AXIADO_SARADC) += axiado_saradc.o
obj-$(CONFIG_AXP20X_ADC) += axp20x_adc.o
obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
diff --git a/drivers/iio/adc/axiado_saradc.c b/drivers/iio/adc/axiado_saradc.c
new file mode 100644
index 000000000000..b802fceb9c7b
--- /dev/null
+++ b/drivers/iio/adc/axiado_saradc.c
@@ -0,0 +1,286 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2021-2026 Axiado Corporation
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/units.h>
+
+#include <linux/iio/iio.h>
+
+/* Register offsets */
+#define AX_SARADC_GLOBAL_CTRL_REG 0x0004
+#define AX_SARADC_MANUAL_CTRL_REG 0x0008
+#define AX_SARADC_DOUT_REG 0x001C
+
+/* GLOBAL_CTRL register fields */
+#define AX_SARADC_GLOBAL_CTRL_CH_EN_MASK GENMASK(31, 16)
+#define AX_SARADC_GLOBAL_CTRL_SAMPLE_MASK GENMASK(6, 5)
+#define AX_SARADC_GLOBAL_CTRL_MODE_MASK GENMASK(4, 3)
+#define AX_SARADC_GLOBAL_CTRL_PD BIT(2)
+#define AX_SARADC_GLOBAL_CTRL_ENABLE BIT(0)
+
+/* GLOBAL_CTRL register values */
+#define AX_SARADC_GLOBAL_CTRL_SAMPLE_16 \
+ FIELD_PREP(AX_SARADC_GLOBAL_CTRL_SAMPLE_MASK, 0)
+
+#define AX_SARADC_GLOBAL_CTRL_MODE_MANUAL \
+ FIELD_PREP(AX_SARADC_GLOBAL_CTRL_MODE_MASK, 1)
+
+/* MANUAL_CTRL register fields */
+#define AX_SARADC_MANUAL_CTRL_ENABLE BIT(0)
+#define AX_SARADC_MANUAL_CTRL_CH_SEL_MASK GENMASK(4, 1)
+
+#define AX_SARADC_MANUAL_CTRL_EN(ch) \
+ (AX_SARADC_MANUAL_CTRL_ENABLE | \
+ FIELD_PREP(AX_SARADC_MANUAL_CTRL_CH_SEL_MASK, ch))
+
+#define AX_RESOLUTION_BITS 10
+#define AX_SARADC_CONV_CYCLES 13
+#define AX_SARADC_CONV_DELAY_MARGIN_US 10
+
+struct axiado_saradc {
+ struct regmap *regmap;
+ struct clk *clk;
+ struct mutex lock; /* Serializes ADC conversions. */
+ unsigned long clk_rate;
+ int vref_uV;
+};
+
+static const struct regmap_config axiado_saradc_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = AX_SARADC_DOUT_REG,
+};
+
+
+static int axiado_saradc_conversion(struct axiado_saradc *info,
+ struct iio_chan_spec const *chan, int *val)
+{
+ unsigned long usecs;
+ unsigned int regval;
+ int stop_ret;
+ int ret;
+
+ guard(mutex)(&info->lock);
+
+ /* Select the channel to be used and trigger conversion */
+ ret = regmap_write(info->regmap, AX_SARADC_MANUAL_CTRL_REG,
+ AX_SARADC_MANUAL_CTRL_EN(chan->channel));
+ if (ret)
+ return ret;
+
+
+ /* Hardware requires 13 conversion cycles at clk_rate */
+ usecs = DIV_ROUND_UP(AX_SARADC_CONV_CYCLES * USEC_PER_SEC,
+ info->clk_rate);
+ fsleep(usecs + AX_SARADC_CONV_DELAY_MARGIN_US);
+
+ ret = regmap_read(info->regmap, AX_SARADC_DOUT_REG, ®val);
+
+ /* Stop manual conversion */
+ stop_ret = regmap_write(info->regmap, AX_SARADC_MANUAL_CTRL_REG, 0);
+
+ if (ret)
+ return ret;
+ if (stop_ret)
+ return stop_ret;
+
+ *val = regval & GENMASK(AX_RESOLUTION_BITS - 1, 0);
+ return 0;
+}
+
+static int axiado_saradc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ struct axiado_saradc *info = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = axiado_saradc_conversion(info, chan, val);
+ if (ret)
+ return ret;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = info->vref_uV / (MICRO / MILLI);
+ *val2 = AX_RESOLUTION_BITS;
+ return IIO_VAL_FRACTIONAL_LOG2;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info axiado_saradc_iio_info = {
+ .read_raw = axiado_saradc_read_raw,
+};
+
+struct axiado_saradc_soc_data {
+ const char *name;
+ unsigned int num_channels;
+};
+
+static const struct axiado_saradc_soc_data ax3000_saradc_data = {
+ .name = "ax3000_saradc",
+ .num_channels = 16,
+};
+
+static const struct axiado_saradc_soc_data ax3005_saradc_data = {
+ .name = "ax3005_saradc",
+ .num_channels = 8,
+};
+
+#define AX_SARADC_CH(_index) \
+ { \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = (_index), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .datasheet_name = "adc" #_index, \
+ }
+
+static const struct iio_chan_spec axiado_saradc_iio_channels[] = {
+ AX_SARADC_CH(0),
+ AX_SARADC_CH(1),
+ AX_SARADC_CH(2),
+ AX_SARADC_CH(3),
+ AX_SARADC_CH(4),
+ AX_SARADC_CH(5),
+ AX_SARADC_CH(6),
+ AX_SARADC_CH(7),
+ AX_SARADC_CH(8),
+ AX_SARADC_CH(9),
+ AX_SARADC_CH(10),
+ AX_SARADC_CH(11),
+ AX_SARADC_CH(12),
+ AX_SARADC_CH(13),
+ AX_SARADC_CH(14),
+ AX_SARADC_CH(15),
+};
+
+static void axiado_saradc_disable(void *data)
+{
+ struct axiado_saradc *info = data;
+
+ regmap_write(info->regmap, AX_SARADC_GLOBAL_CTRL_REG,
+ AX_SARADC_GLOBAL_CTRL_PD);
+}
+
+static int axiado_saradc_probe(struct platform_device *pdev)
+{
+ const struct axiado_saradc_soc_data *soc_data;
+ struct device *dev = &pdev->dev;
+ struct axiado_saradc *info;
+ struct iio_dev *indio_dev;
+ void __iomem *regs;
+ u32 regval;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*info));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ info = iio_priv(indio_dev);
+
+ regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ info->regmap = devm_regmap_init_mmio(dev, regs,
+ &axiado_saradc_regmap_config);
+ if (IS_ERR(info->regmap))
+ return PTR_ERR(info->regmap);
+
+ info->clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(info->clk))
+ return PTR_ERR(info->clk);
+
+ info->clk_rate = clk_get_rate(info->clk);
+ if (!info->clk_rate)
+ return dev_err_probe(dev, -EINVAL, "invalid clock rate\n");
+
+ ret = devm_regulator_get_enable_read_voltage(dev, "vref");
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to get vref voltage\n");
+
+ info->vref_uV = ret;
+
+ soc_data = device_get_match_data(dev);
+ if (!soc_data)
+ return dev_err_probe(dev, -EINVAL, "failed to get match data\n");
+
+ ret = devm_mutex_init(dev, &info->lock);
+ if (ret)
+ return ret;
+
+ regval = FIELD_PREP(AX_SARADC_GLOBAL_CTRL_CH_EN_MASK,
+ GENMASK(soc_data->num_channels - 1, 0)) |
+ AX_SARADC_GLOBAL_CTRL_SAMPLE_16 |
+ AX_SARADC_GLOBAL_CTRL_MODE_MANUAL |
+ AX_SARADC_GLOBAL_CTRL_ENABLE;
+
+ ret = regmap_write(info->regmap, AX_SARADC_GLOBAL_CTRL_REG,
+ AX_SARADC_GLOBAL_CTRL_PD);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(info->regmap, AX_SARADC_GLOBAL_CTRL_REG, regval);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(dev, axiado_saradc_disable, info);
+ if (ret)
+ return ret;
+
+ indio_dev->name = soc_data->name;
+ indio_dev->info = &axiado_saradc_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = axiado_saradc_iio_channels;
+ indio_dev->num_channels = soc_data->num_channels;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct of_device_id axiado_saradc_match[] = {
+ {
+ .compatible = "axiado,ax3000-saradc",
+ .data = &ax3000_saradc_data,
+ },
+ {
+ .compatible = "axiado,ax3005-saradc",
+ .data = &ax3005_saradc_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, axiado_saradc_match);
+
+static struct platform_driver axiado_saradc_driver = {
+ .driver = {
+ .name = "axiado-saradc",
+ .of_match_table = axiado_saradc_match,
+ },
+ .probe = axiado_saradc_probe,
+};
+module_platform_driver(axiado_saradc_driver);
+
+MODULE_AUTHOR("AXIADO CORPORATION");
+MODULE_DESCRIPTION("AXIADO SARADC driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/2] iio: adc: Add Axiado SARADC driver
From: Petar Stepanovic @ 2026-07-17 5:53 UTC (permalink / raw)
To: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Petar Stepanovic, Conor Dooley
This series adds support for the SAR ADC controller found on Axiado
AX3000 and AX3005 SoCs.
A new driver is needed because this SAR ADC controller is a SoC-specific
hardware block used on Axiado SoCs. It has its own register layout,
channel enable handling, conversion control, and data readout sequence,
and it does not match any existing upstream IIO ADC driver.
AX3000 provides sixteen input channels, while AX3005 provides eight
input channels. The driver uses SoC match data to select the number of
available channels for each compatible.
The driver supports single-shot voltage reads through the IIO subsystem
and uses the reference voltage regulator for scale calculation.
The datasheet is not publicly available. Public high-level product
information is available at:
https://axiado.com/products/#AX3080
The register definitions and programming sequence used by this driver
are based on Axiado internal SoC documentation.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
Changes in v4:
- Converted direct MMIO register access from readl()/writel() to the regmap API.
- Added REGMAP_MMIO as a Kconfig selection.
- Added error handling for regmap read and write operations.
- Ensured manual conversion is stopped even if reading the conversion result fails.
- Fixed the regulator error path to return the actual error code instead of the
uninitialized reference voltage.
- Simplified the channel macro by generating datasheet_name from the
- channel index.
- Changed the channel array to use one channel entry per line.
- Link to v3: https://lore.kernel.org/r/20260622-axiado-ax3000-ax3005-saradc-v3-0-e57c7c7ae675@axiado.com
Changes in v3:
- Fixed vref regulator error handling.
- Added linux/units.h and used MICRO / MILLI in scale calculation.
- Reordered struct axiado_saradc members to improve the structure
layout.
- Fixed indentation/alignment of multi-line FIELD_PREP(), GENMASK(), and
writel() expressions.
- Removed the blank line before module_platform_driver().
- Link to v2: https://lore.kernel.org/r/20260611-axiado-ax3000-ax3005-saradc-v2-0-913c9de7c64c@axiado.com
Changes in v2:
- Fixed the devicetree example node name to use the generic ADC node name.
- Removed the explicit `depends on OF` from Kconfig.
- Cleaned up and reordered header includes.
- Added missing includes for `bits.h`, `clk.h`, `cleanup.h`, and `err.h`.
- Removed unused `linux/kernel.h` include.
- Renamed register offset macros to use the `_REG` suffix.
- Renamed register bitfield macros to include the register name prefix.
- Added separate macros for `GLOBAL_CTRL` and `MANUAL_CTRL` register
fields and values.
- Replaced `iowrite32()` / `ioread32()` with `writel()` / `readl()`.
- Moved ADC conversion locking into `axiado_saradc_conversion()` using
`guard(mutex)`.
- Replaced `usleep_range()` with `fsleep()`.
- Renamed `vref_uv` to `vref_uV`.
- Added SoC-specific device names in `axiado_saradc_soc_data`.
- Used the fixed SoC-specific name for `indio_dev->name`.
- Removed unused buffered scan configuration from IIO channels.
- Added a managed cleanup action to disable the SARADC hardware on driver
unbind or probe failure.
- Switched to a local `struct device *dev` helper in probe.
- Used `devm_mutex_init()` for mutex initialization.
- Simplified error handling by using `dev_err_probe()`.
- Updated probe variable declarations to follow reverse Christmas tree
order.
- Fixed the `of_device_id` terminator style.
- Replaced `KBUILD_MODNAME` with a fixed driver name string.
- Link to v1: https://lore.kernel.org/r/20260528-axiado-ax3000-ax3005-saradc-v1-0-345dd5f6608a@axiado.com
---
Petar Stepanovic (2):
dt-bindings: iio: adc: add Axiado AX3000/AX3005 SARADC
iio: adc: add Axiado SARADC driver
.../bindings/iio/adc/axiado,ax3000-saradc.yaml | 63 +++++
MAINTAINERS | 9 +
drivers/iio/adc/Kconfig | 11 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axiado_saradc.c | 286 +++++++++++++++++++++
5 files changed, 370 insertions(+)
---
base-commit: 51f0c0b8545b23963afd5d43a8f56ee05bfa54da
change-id: 20260508-axiado-ax3000-ax3005-saradc-151aed5d25da
Best regards,
--
Petar Stepanovic <pstepanovic@axiado.com>
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: iio: adc: add Axiado AX3000/AX3005 SARADC
From: Petar Stepanovic @ 2026-07-17 5:53 UTC (permalink / raw)
To: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Petar Stepanovic, Conor Dooley
In-Reply-To: <20260716-axiado-ax3000-ax3005-saradc-v4-0-810527a9d27f@axiado.com>
The Axiado AX3000 and AX3005 SoCs include a 10-bit SAR ADC controller.
AX3000 supports 16 input channels, while AX3005 supports 8 input
channels.
Document the compatible strings, register region, clock, reference
voltage supply, and IIO channel cells.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../bindings/iio/adc/axiado,ax3000-saradc.yaml | 63 ++++++++++++++++++++++
MAINTAINERS | 8 +++
2 files changed, 71 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml
new file mode 100644
index 000000000000..b910852aa56f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/axiado,ax3000-saradc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axiado AX3000/AX3005 Successive Approximation Register ADC
+
+description:
+ The Axiado AX3000/AX3005 SAR ADC is a 10-bit ADC with sixteen input
+ channels on AX3000 and eight input channels on AX3005.
+
+maintainers:
+ - Petar Stepanovic <pstepanovic@axiado.com>
+ - Akhila Kavi <akavi@axiado.com>
+ - Prasad Bolisetty <pbolisetty@axiado.com>
+
+properties:
+ compatible:
+ enum:
+ - axiado,ax3000-saradc
+ - axiado,ax3005-saradc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: saradc
+
+ '#io-channel-cells':
+ const: 1
+
+ vref-supply:
+ description: Reference voltage regulator supplying the ADC
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#io-channel-cells'
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ adc@806a0000 {
+ compatible = "axiado,ax3000-saradc";
+ reg = <0x0 0x806a0000 0x0 0x400>;
+ clocks = <&pclk>;
+ clock-names = "saradc";
+ vref-supply = <&vref_reg>;
+ #io-channel-cells = <1>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index b2040011a386..d6f4febfe4fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4312,6 +4312,14 @@ S: Orphan
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXIADO SARADC DRIVER
+M: Petar Stepanovic <pstepanovic@axiado.com>
+M: Akhila Kavi <akavi@axiado.com>
+M: Prasad Bolisetty <pbolisetty@axiado.com>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml
+
AXIS ARTPEC ARM64 SoC SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
M: Lars Persson <lars.persson@axis.com>
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 3/7] drm/panel: simple: Add waiken WKS101WX001-WCT support
From: Liu Ying @ 2026-07-17 5:48 UTC (permalink / raw)
To: Frank.Li
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Jessica Zhang,
Thierry Reding, Sam Ravnborg, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, dri-devel, devicetree,
linux-kernel, imx, linux-arm-kernel, Robert Chiras, Frank Li
In-Reply-To: <20260715-dxl_lcdif-v2-3-da797562636e@nxp.com>
On Wed, Jul 15, 2026 at 02:34:48PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Add support for WKS101WX001-WCT panel, which is an industrial-grade
> 10.1-inch IPS TFT LCD capacitive touch screen display module.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> change in v2
> - update height to 135 from 136 (sashiko)
> ---
> drivers/gpu/drm/panel/panel-simple.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index c09bf3db5e78a..73a21303a612a 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -5171,6 +5171,34 @@ static const struct panel_desc vl050_8048nt_c01 = {
> .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
> };
>
> +static const struct drm_display_mode waiken_101wx001_mode = {
> + .clock = 71100,
> + .hdisplay = 1280,
> + .hsync_start = 1280 + 70,
> + .hsync_end = 1280 + 70 + 10,
> + .htotal = 1280 + 70 + 10 + 80,
> + .vdisplay = 800,
> + .vsync_start = 800 + 10,
> + .vsync_end = 800 + 10 + 3,
> + .vtotal = 800 + 10 + 3 + 10,
> + .width_mm = 217,
> + .height_mm = 135,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> +};
> +
> +static const struct panel_desc waiken_101wx001_panel = {
> + .modes = &waiken_101wx001_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 217,
> + .height = 135,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
I find a panel specification in link [1] and guess it's for this panel.
It indicates that each color component width is 8 in 'RGB Input Interface
Description' table.
[1] https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Optimizing-eLCDIF-throughput/m-p/982741/highlight/true?profile.language=en#M5348
> + .connector_type = DRM_MODE_CONNECTOR_DPI,
Seems that the panel also supports LVDS input according to the specification,
since it mentions 'RGB or LVDS Interface'?
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
> +};
> +
> static const struct drm_display_mode waveshare_28_lcd_mode = {
> .clock = 50000,
> .hdisplay = 480,
> @@ -6155,6 +6183,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "vxt,vl050-8048nt-c01",
> .data = &vl050_8048nt_c01,
> + }, {
> + .compatible = "waiken,101wx001",
> + .data = &waiken_101wx001_panel,
> }, {
> .compatible = "waveshare,2.8inch-panel",
> .data = &waveshare_28_lcd_panel
>
> --
> 2.43.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: shikra: add vph_pwr and fix supply parent mappings
From: sashiko-bot @ 2026-07-17 5:45 UTC (permalink / raw)
To: Rakesh Kota; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260717-pm2250-fix-supply-parent-v1-3-a6213a42a3b5@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Physically impossible hardware topology: 1.8V LDOs are configured to be supplied by a 1.396V source.
- [Medium] Missing parent supply properties for the s1 and s2 buck converters in the PM4125 regulator node.
--
--- Patch [3]: [PATCH 3/3] arm64: dts: qcom: shikra: add vph_pwr and fix supply parent mappings ---
commit 64d116ee25fe416f23ec9e23adfecfac498cc60e
Author: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
arm64: dts: qcom: shikra: add vph_pwr and fix supply parent mappings
This commit adds a fixed vph_pwr regulator to represent the PM4125 charger
output. It also configures the per-group supply properties for the regulators
and adds the s1 and s4 nodes.
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> index dc3861489f64d..6e4c23a730fb6 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
[ ... ]
> @@ -52,12 +62,33 @@ &pm8005_regulators {
> &rpm_requests {
> regulators {
> compatible = "qcom,rpm-pm2250-regulators";
> + vdd_s4-supply = <&vph_pwr>;
> + vdd_l1-supply = <&pm4125_s4>;
[Severity: Medium]
Are the parent supply properties for the s1 and s2 buck converters intentionally
omitted here?
Leaving out vdd_s1-supply and vdd_s2-supply prevents the regulator core from
resolving the full supply chain, which could lead to power management
dependencies failing if the parent supply is turned off while s1 or s2 are
active.
> + vdd_l2_l3-supply = <&pm4125_s4>;
> + vdd_l5_l6_l7_l11_l12-supply = <&pm4125_s4>;
> + vdd_l8_l9-supply = <&pm4125_s4>;
> + vdd_l10-supply = <&pm4125_s4>;
> + vdd_l13_l14-supply = <&pm4125_s1>;
> + vdd_l15_l16-supply = <&pm4125_s1>;
[Severity: High]
Is it possible to supply 1.8V LDOs from a 1.396V source?
The s1 regulator is configured with a 1.396V output later in this patch:
> + pm4125_s1: s1 {
> + regulator-min-microvolt = <1396000>;
> + regulator-max-microvolt = <1396000>;
> + };
But l13 through l16 are defined elsewhere in the file as requiring 1.8V:
arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi:regulators {
pm4125_l13: l13 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
Since a Low-Dropout Regulator (LDO) can only step down voltage, it seems like
supplying these LDOs from pm4125_s1 will prevent them from reaching their
target output voltage and cause hardware malfunction.
> + vdd_l17_l22-supply = <&vph_pwr>;
> + vdd_l18_l19-supply = <&vph_pwr>;
> + vdd_l4_l20_l21-supply = <&vph_pwr>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-pm2250-fix-supply-parent-v1-0-a6213a42a3b5@oss.qualcomm.com?part=3
^ permalink raw reply
* Re: [PATCH v3 3/3] clk: ultrarisc: Add DP1000 clock driver
From: Jia Wang @ 2026-07-17 5:35 UTC (permalink / raw)
To: Brian Masney
Cc: wangjia, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-clk, devicetree,
linux-kernel
In-Reply-To: <alkgIyhI43ypvZdb@redhat.com>
On 2026-07-16 14:17 -0400, Brian Masney wrote:
> Hi Jia,
>
> I have one minor question below.
>
> On Tue, Jul 14, 2026 at 09:35:09AM +0800, Jia Wang via B4 Relay wrote:
> > From: Jia Wang <wangjia@ultrarisc.com>
> >
> > Add a clock driver for the UltraRISC DP1000 SoC.
> >
> > The clock tree is driven by a SYSPLL and provides fixed-factor clocks for
> > the subsystem and PCIe, divider-based root clocks for GMAC and the UART,
> > I2C, and SPI blocks, and per-instance gate clocks for UART0-3, I2C0-3,
> > and SPI0-1.
> >
> > Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/clk/Kconfig | 1 +
> > drivers/clk/Makefile | 1 +
> > drivers/clk/ultrarisc/Kconfig | 18 ++
> > drivers/clk/ultrarisc/Makefile | 4 +
> > drivers/clk/ultrarisc/clk-dp1000.c | 154 +++++++++++++
> > drivers/clk/ultrarisc/clk-ultrarisc.c | 407 ++++++++++++++++++++++++++++++++++
> > drivers/clk/ultrarisc/clk-ultrarisc.h | 71 ++++++
> > 8 files changed, 657 insertions(+)
>
> [snip]
>
> >
> > +static int ultrarisc_clk_register_dividers(struct platform_device *pdev,
> > + struct clk_hw_onecell_data *clk_data,
> > + const struct ultrarisc_clk_soc_data *soc_data,
> > + void __iomem *base,
> > + spinlock_t *lock)
> > +{
> > + struct device *dev = &pdev->dev;
> > + u32 i;
> > +
> > + for (i = 0; i < soc_data->num_dividers; i++) {
> > + const struct ultrarisc_divider_desc *desc;
> > + struct clk_hw *parent_hw;
> > + struct clk_hw *hw;
> > +
> > + desc = &soc_data->dividers[i];
> > + if (desc->id >= clk_data->num || desc->parent_id >= clk_data->num)
> > + return -EINVAL;
> > +
> > + parent_hw = clk_data->hws[desc->parent_id];
> > + if (!parent_hw)
> > + return -EINVAL;
> > +
> > + hw = ultrarisc_clk_register_divider(dev, desc, parent_hw, base,
> > + lock);
> > + if (IS_ERR(hw))
> > + return PTR_ERR(hw);
> > +
> > + if (desc->max_rate) {
> > + unsigned long rate;
> > +
> > + clk_hw_set_rate_range(hw, 0, desc->max_rate);
> > +
> > + rate = clk_hw_get_rate(hw);
> > + if (rate > desc->max_rate)
> > + dev_warn(dev, "%s rate %lu exceeds max %lu\n",
> > + desc->name, rate, desc->max_rate);
>
> At this point in the probe, the clock tree may not be fully propagated
> yet. Is this check needed?
>
Agreed, I will drop this diagnostic check in the next version and keep
only the rate range constraint.
> Everything else in the driver looks fine to me.
>
> Brian
>
>
Best regards,
Jia Wang
^ permalink raw reply
* [PATCH 3/3] arm64: dts: qcom: shikra: add vph_pwr and fix supply parent mappings
From: Rakesh Kota @ 2026-07-17 5:32 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, devicetree, Kamal Wadhwa,
jishnu.prakash, Rakesh Kota
In-Reply-To: <20260717-pm2250-fix-supply-parent-v1-0-a6213a42a3b5@oss.qualcomm.com>
Add the vph_pwr fixed regulator representing the PM4125 charger output
supplied by VBAT, and add the correct per-group supply properties
matching the actual PM4125 pin connections on Shikra. Also add the
pm4125_s1 and pm4125_s4 regulator nodes.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi | 31 ++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
index dc3861489f64..6e4c23a730fb 100644
--- a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
@@ -27,6 +27,16 @@ key-volume-up {
linux,can-disable;
};
};
+
+ /* PM4125 charger out, supplied by VBAT */
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&pm4125_gpios {
@@ -52,12 +62,33 @@ &pm8005_regulators {
&rpm_requests {
regulators {
compatible = "qcom,rpm-pm2250-regulators";
+ vdd_s4-supply = <&vph_pwr>;
+ vdd_l1-supply = <&pm4125_s4>;
+ vdd_l2_l3-supply = <&pm4125_s4>;
+ vdd_l5_l6_l7_l11_l12-supply = <&pm4125_s4>;
+ vdd_l8_l9-supply = <&pm4125_s4>;
+ vdd_l10-supply = <&pm4125_s4>;
+ vdd_l13_l14-supply = <&pm4125_s1>;
+ vdd_l15_l16-supply = <&pm4125_s1>;
+ vdd_l17_l22-supply = <&vph_pwr>;
+ vdd_l18_l19-supply = <&vph_pwr>;
+ vdd_l4_l20_l21-supply = <&vph_pwr>;
+
+ pm4125_s1: s1 {
+ regulator-min-microvolt = <1396000>;
+ regulator-max-microvolt = <1396000>;
+ };
pm4125_s2: s2 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1200000>;
};
+ pm4125_s4: s4 {
+ regulator-min-microvolt = <640000>;
+ regulator-max-microvolt = <1408000>;
+ };
+
pm4125_l3: l3 {
regulator-min-microvolt = <624000>;
regulator-max-microvolt = <650000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: qcom: qrb2210: fix PM4125 regulator supply parent mappings
From: Rakesh Kota @ 2026-07-17 5:32 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, devicetree, Kamal Wadhwa,
jishnu.prakash, Rakesh Kota
In-Reply-To: <20260717-pm2250-fix-supply-parent-v1-0-a6213a42a3b5@oss.qualcomm.com>
The qrb2210-arduino-imola and qrb2210-rb1 DTS files used coarsely
grouped supply parent names that do not reflect the actual physical
pin connections on the PM4125 PMIC. Since supply rail connections
to PMIC pins are fixed in hardware, these grouped names were
inaccurate descriptions of the hardware topology.
Replace them with the correct per-group supply properties matching
the actual PM4125 pin connections, and align with the companion
driver change that sets supply names to NULL in the qcom_smd-regulator
descriptor so that the correct supply topology is captured in DT.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 13 ++++++++++---
arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 13 ++++++++++---
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
index c472e13fceca..90e6eb284a66 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
@@ -262,9 +262,16 @@ regulators {
compatible = "qcom,rpm-pm2250-regulators";
vdd_s3-supply = <&vph_pwr>;
vdd_s4-supply = <&vph_pwr>;
- vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12-supply = <&pm4125_s3>;
- vdd_l4_l17_l18_l19_l20_l21_l22-supply = <&vph_pwr>;
- vdd_l13_l14_l15_l16-supply = <&pm4125_s4>;
+ vdd_l1-supply = <&pm4125_s3>;
+ vdd_l2_l3-supply = <&pm4125_s3>;
+ vdd_l5_l6_l7_l11_l12-supply = <&pm4125_s3>;
+ vdd_l8_l9-supply = <&pm4125_s3>;
+ vdd_l10-supply = <&pm4125_s3>;
+ vdd_l13_l14-supply = <&pm4125_s4>;
+ vdd_l15_l16-supply = <&pm4125_s4>;
+ vdd_l17_l22-supply = <&vph_pwr>;
+ vdd_l18_l19-supply = <&vph_pwr>;
+ vdd_l4_l20_l21-supply = <&vph_pwr>;
pm4125_s3: s3 {
/* 0.4V-1.6625V -> 1.3V (Power tree requirements) */
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
index bf6fb12ad990..3432022274d8 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
@@ -465,9 +465,16 @@ regulators {
compatible = "qcom,rpm-pm2250-regulators";
vdd_s3-supply = <&vph_pwr>;
vdd_s4-supply = <&vph_pwr>;
- vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12-supply = <&pm4125_s3>;
- vdd_l4_l17_l18_l19_l20_l21_l22-supply = <&vph_pwr>;
- vdd_l13_l14_l15_l16-supply = <&pm4125_s4>;
+ vdd_l1-supply = <&pm4125_s3>;
+ vdd_l2_l3-supply = <&pm4125_s3>;
+ vdd_l5_l6_l7_l11_l12-supply = <&pm4125_s3>;
+ vdd_l8_l9-supply = <&pm4125_s3>;
+ vdd_l10-supply = <&pm4125_s3>;
+ vdd_l13_l14-supply = <&pm4125_s4>;
+ vdd_l15_l16-supply = <&pm4125_s4>;
+ vdd_l17_l22-supply = <&vph_pwr>;
+ vdd_l18_l19-supply = <&vph_pwr>;
+ vdd_l4_l20_l21-supply = <&vph_pwr>;
/*
* S1 - VDD_APC
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] regulator: qcom_smd-regulator: fix PM2250 supply parent mappings
From: Rakesh Kota @ 2026-07-17 5:31 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, devicetree, Kamal Wadhwa,
jishnu.prakash, Rakesh Kota
In-Reply-To: <20260717-pm2250-fix-supply-parent-v1-0-a6213a42a3b5@oss.qualcomm.com>
The rpm_pm2250_regulators table hardcodes supply parent name strings
in the regulator descriptor, causing the Linux regulator framework to
look up and vote on parent supplies from APPS. This is both unnecessary
and incorrect for RPM-managed regulators.
On RPM-based platforms, the parent-child supply relationships are
managed entirely by the RPM firmware. The RPM ensures that parent
rails are maintained at the correct voltage with appropriate headroom,
based on all active child rail votes across all subsystems. No explicit
parent supply vote from APPS is required.
Furthermore, the supply rail connections to PMIC pins are fixed in
hardware. The previously hardcoded supply name strings were inaccurate
and did not reflect the actual physical pin connections on PM2250-based
platforms. The correct supply relationships are to be described in the
Device Tree, not hardcoded in the driver.
To avoid unnecessary APPS-side parent supply access while still
allowing correct hardware topology to be described in DT, set the
supply name field to NULL in the regulator descriptor.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
drivers/regulator/qcom_smd-regulator.c | 52 +++++++++++++++++-----------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
index 23ed594b574e..aed01f18af4a 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -800,32 +800,32 @@ static const struct rpm_regulator_data rpm_mp5496_regulators[] = {
};
static const struct rpm_regulator_data rpm_pm2250_regulators[] = {
- { "s1", QCOM_SMD_RPM_SMPA, 1, &pm2250_lvftsmps, "vdd_s1" },
- { "s2", QCOM_SMD_RPM_SMPA, 2, &pm2250_lvftsmps, "vdd_s2" },
- { "s3", QCOM_SMD_RPM_SMPA, 3, &pm2250_lvftsmps, "vdd_s3" },
- { "s4", QCOM_SMD_RPM_SMPA, 4, &pm2250_ftsmps, "vdd_s4" },
- { "l1", QCOM_SMD_RPM_LDOA, 1, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l2", QCOM_SMD_RPM_LDOA, 2, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l3", QCOM_SMD_RPM_LDOA, 3, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l4", QCOM_SMD_RPM_LDOA, 4, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l5", QCOM_SMD_RPM_LDOA, 5, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l6", QCOM_SMD_RPM_LDOA, 6, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l7", QCOM_SMD_RPM_LDOA, 7, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l8", QCOM_SMD_RPM_LDOA, 8, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l9", QCOM_SMD_RPM_LDOA, 9, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l10", QCOM_SMD_RPM_LDOA, 10, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l11", QCOM_SMD_RPM_LDOA, 11, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l12", QCOM_SMD_RPM_LDOA, 12, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l13", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo, "vdd_l13_l14_l15_l16" },
- { "l14", QCOM_SMD_RPM_LDOA, 14, &pm660_ht_lvpldo, "vdd_l13_l14_l15_l16" },
- { "l15", QCOM_SMD_RPM_LDOA, 15, &pm660_ht_lvpldo, "vdd_l13_l14_l15_l16" },
- { "l16", QCOM_SMD_RPM_LDOA, 16, &pm660_ht_lvpldo, "vdd_l13_l14_l15_l16" },
- { "l17", QCOM_SMD_RPM_LDOA, 17, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l18", QCOM_SMD_RPM_LDOA, 18, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l19", QCOM_SMD_RPM_LDOA, 19, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l20", QCOM_SMD_RPM_LDOA, 20, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l21", QCOM_SMD_RPM_LDOA, 21, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l22", QCOM_SMD_RPM_LDOA, 22, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &pm2250_lvftsmps, NULL },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &pm2250_lvftsmps, NULL },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, &pm2250_lvftsmps, NULL },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, &pm2250_ftsmps, NULL },
+ { "l1", QCOM_SMD_RPM_LDOA, 1, &pm660_nldo660, NULL },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, &pm660_nldo660, NULL },
+ { "l3", QCOM_SMD_RPM_LDOA, 3, &pm660_nldo660, NULL },
+ { "l4", QCOM_SMD_RPM_LDOA, 4, &pm660_pldo660, NULL },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, &pm660_nldo660, NULL },
+ { "l6", QCOM_SMD_RPM_LDOA, 6, &pm660_nldo660, NULL },
+ { "l7", QCOM_SMD_RPM_LDOA, 7, &pm660_nldo660, NULL },
+ { "l8", QCOM_SMD_RPM_LDOA, 8, &pm660_nldo660, NULL },
+ { "l9", QCOM_SMD_RPM_LDOA, 9, &pm660_nldo660, NULL },
+ { "l10", QCOM_SMD_RPM_LDOA, 10, &pm660_nldo660, NULL },
+ { "l11", QCOM_SMD_RPM_LDOA, 11, &pm660_nldo660, NULL },
+ { "l12", QCOM_SMD_RPM_LDOA, 12, &pm660_nldo660, NULL },
+ { "l13", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo, NULL },
+ { "l14", QCOM_SMD_RPM_LDOA, 14, &pm660_ht_lvpldo, NULL },
+ { "l15", QCOM_SMD_RPM_LDOA, 15, &pm660_ht_lvpldo, NULL },
+ { "l16", QCOM_SMD_RPM_LDOA, 16, &pm660_ht_lvpldo, NULL },
+ { "l17", QCOM_SMD_RPM_LDOA, 17, &pm660_pldo660, NULL },
+ { "l18", QCOM_SMD_RPM_LDOA, 18, &pm660_pldo660, NULL },
+ { "l19", QCOM_SMD_RPM_LDOA, 19, &pm660_pldo660, NULL },
+ { "l20", QCOM_SMD_RPM_LDOA, 20, &pm660_pldo660, NULL },
+ { "l21", QCOM_SMD_RPM_LDOA, 21, &pm660_pldo660, NULL },
+ { "l22", QCOM_SMD_RPM_LDOA, 22, &pm660_pldo660, NULL },
{}
};
--
2.34.1
^ permalink raw reply related
* [PATCH 0/3] regulator: qcom_smd-regulator: fix PM2250 supply parent mappings
From: Rakesh Kota @ 2026-07-17 5:31 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, devicetree, Kamal Wadhwa,
jishnu.prakash, Rakesh Kota
The rpm_pm2250_regulators table hardcodes supply parent name strings
in the regulator descriptor, causing the Linux regulator framework to
vote on parent supplies from APPS unnecessarily. On RPM-based platforms,
parent-child supply relationships are managed entirely by RPM firmware.
Fix this by setting supply names to NULL in the driver descriptor, and
correct the supply parent mappings in the qrb2210 and Shikra DTS files
to match the actual PM4125 pin connections.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Rakesh Kota (3):
regulator: qcom_smd-regulator: fix PM2250 supply parent mappings
arm64: dts: qcom: qrb2210: fix PM4125 regulator supply parent mappings
arm64: dts: qcom: shikra: add vph_pwr and fix supply parent mappings
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 13 ++++--
arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 13 ++++--
arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi | 31 +++++++++++++
drivers/regulator/qcom_smd-regulator.c | 52 +++++++++++-----------
4 files changed, 77 insertions(+), 32 deletions(-)
---
base-commit: 1a1757b76427f6201bfe0bf1bea9f7574f332a93
change-id: 20260714-pm2250-fix-supply-parent-b91bed1f65c6
Best regards,
--
Rakesh Kota <rakesh.kota@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: display: simple: Add waiken,101wx001
From: Liu Ying @ 2026-07-17 5:29 UTC (permalink / raw)
To: Frank.Li
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Jessica Zhang,
Thierry Reding, Sam Ravnborg, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, dri-devel, devicetree,
linux-kernel, imx, linux-arm-kernel, Robert Chiras, Frank Li
In-Reply-To: <20260715-dxl_lcdif-v2-2-da797562636e@nxp.com>
On Wed, Jul 15, 2026 at 02:34:47PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Add WKS101WX001-WCT panel, which is an industrial-grade 10.1-inch IPS TFT
> LCD capacitive touch screen display module.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 21453f0d7ce22..01da44ed3e20a 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -349,6 +349,8 @@ properties:
> - vivax,tpc9150-panel
> # VXT 800x480 color TFT LCD panel
> - vxt,vl050-8048nt-c01
> + # waiken 10.1-inch IPS TFT LCD panel with capacitive touch
To follow comment convention for each compatible string:
s/waiken/Waiken/
s/10.1-inch/10.1"/
> + - waiken,101wx001
Commit message mentions "WKS101WX001-WCT", so can you use full model name?
> # Waveshare 10.1" WXGA (1280x800) LCD panel
> - waveshare,10.1inch-c-panel
> # Waveshare 11.9" (320x1480) LCD panel
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 396044f368e7c..38d6765ed62ed 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1833,6 +1833,8 @@ patternProperties:
> description: VXT Ltd
> "^wacom,.*":
> description: Wacom
> + "^waiken,.*":
> + description: Waiken Technology Co.
Home page[1] mentions "Waiken Technology Limited", so use the same for
description?
[1] https://www.waikentech.com/
> "^wanchanglong,.*":
> description: Wanchanglong Electronics Technology（SHENZHEN）Co.，Ltd.
> "^wand,.*":
>
> --
> 2.43.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: imx93: Add i.MX93 Wireless FRDM board support
From: sashiko-bot @ 2026-07-17 5:25 UTC (permalink / raw)
To: Joseph Guo; +Cc: conor+dt, robh, devicetree, Frank.Li, imx
In-Reply-To: <20260717-imx93w_frdm-v1-3-0cca6c0ba2f5@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The i.MX93W FRDM device tree inherits an invalid Bluetooth configuration intended for an absent M.2 module, while omitting the correct configuration for the integrated IW610 chip.
--
--- Patch [3]: [PATCH 3/3] arm64: dts: imx93: Add i.MX93 Wireless FRDM board support ---
commit 54467df83181ba6647f33372016b6a5139213211
Author: Joseph Guo <qijian.guo@nxp.com>
arm64: dts: imx93: Add i.MX93 Wireless FRDM board support
This commit adds device tree support for the i.MX93 Wireless FRDM board.
It reuses the common FRDM device tree include but overrides specific pins
and configurations due to the hardware switch from an M.2 module to the
integrated IW610 chip.
> diff --git a/arch/arm64/boot/dts/freescale/imx93w-frdm.dts b/arch/arm64/boot/dts/freescale/imx93w-frdm.dts
> new file mode 100644
> index 0000000000000..766e942fe6638
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93w-frdm.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2026 NXP
> + */
> +
> +/dts-v1/;
> +
> +#include "imx93w.dtsi"
> +#include "imx93-11x11-frdm-common.dtsi"
[Severity: Medium]
Does this file need to explicitly disable the bluetooth node inherited from
the common dtsi file?
The imx93-11x11-frdm-common.dtsi unconditionally enables the M.2 bluetooth
node on lpuart5. Since the M.2 module is removed on the FRDM-IMX93W board,
will the kernel attempt to initialize a non-existent device and inadvertently
toggle I2C IO expander pins intended for the absent M.2 slot?
Should the lpuart5 bluetooth node be marked disabled here, and a new node
added for the correct IW610 Bluetooth interface mentioned in the commit
message?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-imx93w_frdm-v1-0-0cca6c0ba2f5@nxp.com?part=3
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: imx93-11x11-frdm: factor out common parts into dtsi
From: sashiko-bot @ 2026-07-17 5:19 UTC (permalink / raw)
To: Joseph Guo; +Cc: devicetree, conor+dt, imx, Frank.Li, robh
In-Reply-To: <20260717-imx93w_frdm-v1-1-0cca6c0ba2f5@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Dangling phandle reference to a board-specific label in the common `.dtsi` file.
--
--- Patch [1]: [PATCH 1/3] arm64: dts: imx93-11x11-frdm: factor out common parts into dtsi ---
commit 75e389bfc1f27ac338bceffb58faf699a50fada0
Author: Joseph Guo <qijian.guo@nxp.com>
Subject: arm64: dts: imx93-11x11-frdm: factor out common parts into dtsi
This commit extracts common hardware definitions from imx93-11x11-frdm.dts
into a new imx93-11x11-frdm-common.dtsi file to allow sharing with the
wireless FRDM board.
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi
[ ... ]
> +&lpuart5 {
> + pinctrl-0 = <&pinctrl_uart5>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + uart-has-rtscts;
> +
> + bluetooth {
> + compatible = "nxp,88w8987-bt";
> + device-wakeup-gpios = <&pcal6408 3 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&pcal6524 19 GPIO_ACTIVE_LOW>;
> + vcc-supply = <®_usdhc3_vmmc>;
> + };
[Severity: Medium]
Will other boards that include this common .dtsi fail to compile?
The bluetooth node in the new common .dtsi references ®_usdhc3_vmmc, but
the definition for this regulator was left behind in the board-specific file.
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
> index bd14ba28690c0..f2a31a0eacabf 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
[ ... ]
> reg_usdhc3_vmmc: regulator-usdhc3 {
> compatible = "regulator-fixed";
> regulator-name = "VPCIe_3V3";
> @@ -76,51 +19,6 @@ reg_usdhc3_vmmc: regulator-usdhc3 {
> enable-active-high;
> };
Since the reg_usdhc3_vmmc label is not defined in the common .dtsi, any other
board attempting to include the common file will hit a missing label error
during compilation.
Should this regulator definition be moved to the common file alongside the
bluetooth node, or should the vcc-supply property be set as an override in
the board-specific files instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-imx93w_frdm-v1-0-0cca6c0ba2f5@nxp.com?part=1
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: lcdif: add compatible string for i.MX8QXP and i.MX8DXL
From: Liu Ying @ 2026-07-17 5:19 UTC (permalink / raw)
To: Frank.Li
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Jessica Zhang,
Thierry Reding, Sam Ravnborg, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, dri-devel, devicetree,
linux-kernel, imx, linux-arm-kernel, Robert Chiras, Frank Li
In-Reply-To: <20260715-dxl_lcdif-v2-1-da797562636e@nxp.com>
On Wed, Jul 15, 2026 at 02:34:46PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> i.MX8QXP and i.MX8DXL have lcdif, which back compatible with i.MX6SX. Add
> front compatible string "fsl,imx8dxl-lcdif" and "fsl,imx8qxp-lcdif", which
> fallback to "fsl,imx6sx-lcdif".
>
> Required power-domains for both.
Need to add a constraint for both that only allows 3 clocks and clock-names?
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> change in v2
> - require power-domains (sashiko)
> ---
> Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index 2dd0411ec6516..f16bef7f68535 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -28,9 +28,11 @@ properties:
> - fsl,imx6sll-lcdif
> - fsl,imx6ul-lcdif
> - fsl,imx7d-lcdif
> + - fsl,imx8dxl-lcdif
> - fsl,imx8mm-lcdif
> - fsl,imx8mn-lcdif
> - fsl,imx8mq-lcdif
> + - fsl,imx8qxp-lcdif
> - const: fsl,imx6sx-lcdif
>
> reg:
> @@ -152,9 +154,11 @@ allOf:
> contains:
> enum:
> - fsl,imx6sl-lcdif
> + - fsl,imx8dxl-lcdif
> - fsl,imx8mm-lcdif
> - fsl,imx8mn-lcdif
> - fsl,imx8mp-lcdif
> + - fsl,imx8qxp-lcdif
> - fsl,imx93-lcdif
> then:
> required:
>
> --
> 2.43.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* [PATCH 3/3] arm64: dts: imx93: Add i.MX93 Wireless FRDM board support
From: Joseph Guo @ 2026-07-17 5:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joseph Guo
In-Reply-To: <20260717-imx93w_frdm-v1-0-0cca6c0ba2f5@nxp.com>
i.MX93 Wireless FRDM board(FRDM-IMX93W) is a low-cost and compact board featuring
the i.MX93W applications processor:https://www.nxp.com/products/IMX93W
FRDM-IMX93W board basically reuse the FRDM-IMX93 board, with some minor
functional and pin connection differences. Reuse the
imx93-11x11-frdm-common.dtsi and add the board-specific changes.
Here are the detailed differences between FRDM-IMX93 and FRDM-IMX93W board.
Function differences:
Function FRDM-IMX93W FRDM-IMX93
WIFI/BT IW610 in i.MX93W IW612 M.2 module
MQS N Y
M.2 N Y
RPi 40-pin HDR Limited support(pin conflict) Y
Pin connection differences:
Function Signal name i.MX93W EVK i.MX93 EVK
WIFI/BT SPI_FRM SAI1_TXFS (spi1.PCS0) GPIO_IO08 (spi3.PCS0)
SPI_TXD SAI1_TXC (spi1.SIN) GPIO_IO09 (spi3.SIN)
SPI_RXD SAI1_RXD0 (spi1.SOUT) GPIO_IO10 (spi3.SOUT)
SPI_CLK SAI1_TXD0 (spi1.SCK) GPIO_IO11 (spi3.SCK)
SPI_INT CCM_CLKO1 on-board IO expander
NB_WAKE_IN PDM_CLK on-module IO expander
WL_WAKE_IN PDM_BIT_STREAM0 on-module IO expander
IND_RST_WL PDM_BIT_STREAM1 on-module IO expander
IND_RST_NB GPIO_IO28 on-module IO expander
PDn GPIO_IO29 on-module IO expander
NB_WAKE_OUT GPIO_IO14 on-board IO expander
WL_WAKE_OUT GPIO_IO15 CCM_CLKO1
I2C3 I2C3_SDA GPIO_IO00 GPIO_IO28
I2C3_SCL GPIO_IO01 GPIO_IO29
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/imx93w-frdm.dts | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index be3c858f1eeb1a807cb8ac36269c581143f755df..d48ba7dee1861e0b39ab025c4b8108ffa68c9bf3 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -655,6 +655,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla-mini-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93w-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93w-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx943-evk.dtb
imx943-evk-pcie0-ep-dtbs += imx943-evk.dtb imx-pcie0-ep.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx93w-frdm.dts b/arch/arm64/boot/dts/freescale/imx93w-frdm.dts
new file mode 100644
index 0000000000000000000000000000000000000000..766e942fe6638330b602577c541d93f3526afe51
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93w-frdm.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+
+#include "imx93w.dtsi"
+#include "imx93-11x11-frdm-common.dtsi"
+
+/ {
+ model = "NXP i.MX93W FRDM board";
+ compatible = "fsl,imx93-wireless-frdm", "fsl,imx93";
+};
+
+&iomuxc {
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO01__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: arm: fsl: Add i.MX93 Wireless FRDM board
From: Joseph Guo @ 2026-07-17 5:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joseph Guo
In-Reply-To: <20260717-imx93w_frdm-v1-0-0cca6c0ba2f5@nxp.com>
Add DT compatible string for NXP i.MX93 Wireless FRDM board.
i.MX93 Wireless SiP is created by integrating i.MX93 and IW610 WLCSP
(Wi-Fi + BLE + 802.15.4). And i.MX93 Wireless FRDM board with the i.MX93
Wireless SiP basically reuse the i.MX93 11x11 FRDM board, with some minor
functional and pin connection differences.
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..9ab7af8c02d68c7f95cccfb5071662eafc8f93a0 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1513,6 +1513,7 @@ properties:
- fsl,imx93-11x11-frdm # i.MX93 11x11 FRDM Board
- fsl,imx93-14x14-evk # i.MX93 14x14 EVK Board
- fsl,imx93-wireless-evk # i.MX93 and IW610G WLCSP (Wi-Fi + BLE + 802.15.4) SiP EVK Board
+ - fsl,imx93-wireless-frdm # i.MX93 and IW610G WLCSP (Wi-Fi + BLE + 802.15.4) SiP FRDM Board
- const: fsl,imx93
- description: i.MX94 based Boards
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: imx93-11x11-frdm: factor out common parts into dtsi
From: Joseph Guo @ 2026-07-17 5:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joseph Guo
In-Reply-To: <20260717-imx93w_frdm-v1-0-0cca6c0ba2f5@nxp.com>
The i.MX93 Wireless FRDM board reuses most of the i.MX93 FRDM board.
To avoid duplication and DTS-to-DTS includes, extract common hardware
definitions from imx93-11x11-frdm.dts into imx93-11x11-frdm-common.dtsi
to allow the common description shared by both boards.
The FRDM-IMX93 board-specific .dts now includes the common dtsi and only
contains board-specific overrides.
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
.../dts/freescale/imx93-11x11-frdm-common.dtsi | 692 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts | 686 +-------------------
2 files changed, 694 insertions(+), 684 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi
new file mode 100644
index 0000000000000000000000000000000000000000..69e23570f71f40a3f3517d31e16a9ca1d3dfb1f2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi
@@ -0,0 +1,692 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include <dt-bindings/usb/pd.h>
+
+/ {
+
+ aliases {
+ can0 = &flexcan2;
+ ethernet0 = &fec;
+ ethernet1 = &eqos;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ mmc0 = &usdhc1; /* EMMC */
+ mmc1 = &usdhc2; /* uSD */
+ rtc0 = &pcf2131;
+ serial0 = &lpuart1;
+ serial4 = &lpuart5;
+ };
+
+ chosen {
+ stdout-path = &lpuart1;
+ };
+
+ flexcan2_phy: can-phy {
+ compatible = "nxp,tja1051";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ silent-gpios = <&pcal6524 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-k2 {
+ label = "Button K2";
+ linux,code = <BTN_1>;
+ gpios = <&pcal6524 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ button-k3 {
+ label = "Button K3";
+ linux,code = <BTN_2>;
+ gpios = <&pcal6524 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ off-on-delay-us = <12000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "VSD_3V3";
+ vin-supply = <&buck4>;
+ gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ ranges;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0 0x80000000 0 0x30000000>;
+ reusable;
+ size = <0 0x10000000>;
+ linux,cma-default;
+ };
+
+ rsc_table: rsc-table@2021e000 {
+ reg = <0 0x2021e000 0 0x1000>;
+ no-map;
+ };
+
+ vdev0vring0: vdev0vring0@a4000000 {
+ reg = <0 0xa4000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@a4008000 {
+ reg = <0 0xa4008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: vdev1vring0@a4010000 {
+ reg = <0 0xa4010000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: vdev1vring1@a4018000 {
+ reg = <0 0xa4018000 0 0x8000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@a4020000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa4020000 0 0x100000>;
+ no-map;
+ };
+ };
+};
+
+&adc1 {
+ vref-supply = <&buck5>;
+ status = "okay";
+};
+
+&mu1 {
+ status = "okay";
+};
+
+&cm33 {
+ mboxes = <&mu1 0 1>,
+ <&mu1 1 1>,
+ <&mu1 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+ status = "okay";
+};
+
+&eqos {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_eqos>;
+ pinctrl-1 = <&pinctrl_eqos_sleep>;
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <5000000>;
+
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ reset-gpios = <&pcal6524 15 GPIO_ACTIVE_LOW>;
+ realtek,clkout-disable;
+ };
+ };
+};
+
+&fec {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_fec>;
+ pinctrl-1 = <&pinctrl_fec_sleep>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy2>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <5000000>;
+
+ ethphy2: ethernet-phy@2 {
+ reg = <2>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ reset-gpios = <&pcal6524 16 GPIO_ACTIVE_LOW>;
+ realtek,clkout-disable;
+ };
+ };
+};
+
+&flexcan2 {
+ phys = <&flexcan2_phy>;
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ pinctrl-1 = <&pinctrl_flexcan2_sleep>;
+ pinctrl-names = "default", "sleep";
+ status = "okay";
+};
+
+&lpi2c1 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c1>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ pcal6408: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ reset-gpios = <&pcal6524 20 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&lpi2c2 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c2>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ pcal6524: gpio@22 {
+ compatible = "nxp,pcal6524";
+ reg = <0x22>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ pinctrl-0 = <&pinctrl_pcal6524>;
+ pinctrl-names = "default";
+ /* does not boot with supplier set, because it is the bucks interrupt parent */
+ /* vcc-supply = <&buck4>; */
+ };
+
+ pmic@25 {
+ compatible = "nxp,pca9451a";
+ reg = <0x25>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+
+ regulators {
+
+ buck1: BUCK1 {
+ regulator-name = "VDD_SOC_0V8";
+ regulator-min-microvolt = <610000>;
+ regulator-max-microvolt = <950000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "LPD4_x_VDDQ_0V6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <670000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck4: BUCK4 {
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck5: BUCK5 {
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "LPD4_x_VDD2_1V1";
+ regulator-min-microvolt = <1060000>;
+ regulator-max-microvolt = <1140000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "NVCC_BBSM_1V8";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4: LDO4 {
+ regulator-name = "VDD_ANA_0V8";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <840000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5: LDO5 {
+ regulator-name = "NVCC_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c256";
+ reg = <0x50>;
+ pagesize = <64>;
+ vcc-supply = <&buck4>;
+ };
+};
+
+&lpi2c3 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ptn5110: tcpc@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+
+ typec1_con: connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ label = "USB-C";
+ op-sink-microwatt = <15000000>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_VAR(5000, 20000, 3000)>;
+ 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>;
+ };
+ };
+ };
+ };
+ };
+
+ pcf2131: rtc@53 {
+ compatible = "nxp,pcf2131";
+ reg = <0x53>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&lpuart1 { /* console */
+ pinctrl-0 = <&pinctrl_uart1>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&lpuart5 {
+ pinctrl-0 = <&pinctrl_uart5>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ device-wakeup-gpios = <&pcal6408 3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pcal6524 19 GPIO_ACTIVE_LOW>;
+ vcc-supply = <®_usdhc3_vmmc>;
+ };
+};
+
+&usbotg1 {
+ 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>;
+ };
+ };
+};
+
+&usbotg2 {
+ disable-over-current;
+ dr_mode = "host";
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ status = "okay";
+};
+
+&usdhc1 {
+ bus-width = <8>;
+ non-removable;
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ vmmc-supply = <&buck4>;
+ status = "okay";
+};
+
+&usdhc2 {
+ bus-width = <4>;
+ cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+ no-mmc;
+ no-sdio;
+ 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_sleep>, <&pinctrl_usdhc2_gpio_sleep>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ vmmc-supply = <®_usdhc2_vmmc>;
+ status = "okay";
+};
+
+&wdog3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__ENET_QOS_MDC 0x57e
+ MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
+ MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
+ MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
+ MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
+ MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
+ MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e
+ MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
+ MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e
+ MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
+ MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
+ MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e
+ MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
+ >;
+ };
+
+ pinctrl_eqos_sleep: eqossleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__GPIO4_IO00 0x31e
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x31e
+ MX93_PAD_ENET1_RD0__GPIO4_IO10 0x31e
+ MX93_PAD_ENET1_RD1__GPIO4_IO11 0x31e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x31e
+ MX93_PAD_ENET1_RD3__GPIO4_IO13 0x31e
+ MX93_PAD_ENET1_RXC__GPIO4_IO09 0x31e
+ MX93_PAD_ENET1_RX_CTL__GPIO4_IO08 0x31e
+ MX93_PAD_ENET1_TD0__GPIO4_IO05 0x31e
+ MX93_PAD_ENET1_TD1__GPIO4_IO04 0x31e
+ MX93_PAD_ENET1_TD2__GPIO4_IO03 0x31e
+ MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e
+ MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e
+ MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e
+ >;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDC__ENET1_MDC 0x57e
+ MX93_PAD_ENET2_MDIO__ENET1_MDIO 0x57e
+ MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0 0x57e
+ MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e
+ MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e
+ MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x57e
+ MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e
+ MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e
+ MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e
+ MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e
+ MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e
+ MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e
+ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
+ >;
+ };
+
+ pinctrl_fec_sleep: fecsleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDC__GPIO4_IO14 0x51e
+ MX93_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
+ MX93_PAD_ENET2_RD0__GPIO4_IO24 0x51e
+ MX93_PAD_ENET2_RD1__GPIO4_IO25 0x51e
+ MX93_PAD_ENET2_RD2__GPIO4_IO26 0x51e
+ MX93_PAD_ENET2_RD3__GPIO4_IO27 0x51e
+ MX93_PAD_ENET2_RXC__GPIO4_IO23 0x51e
+ MX93_PAD_ENET2_RX_CTL__GPIO4_IO22 0x51e
+ MX93_PAD_ENET2_TD0__GPIO4_IO19 0x51e
+ MX93_PAD_ENET2_TD1__GPIO4_IO18 0x51e
+ MX93_PAD_ENET2_TD2__GPIO4_IO17 0x51e
+ MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e
+ MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e
+ MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO25__CAN2_TX 0x139e
+ MX93_PAD_GPIO_IO27__CAN2_RX 0x139e
+ >;
+ };
+
+ pinctrl_flexcan2_sleep: flexcan2sleepgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO25__GPIO2_IO25 0x31e
+ MX93_PAD_GPIO_IO27__GPIO2_IO27 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c1: lpi2c1grp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
+ MX93_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c2: lpi2c2grp {
+ fsl,pins = <
+ MX93_PAD_I2C2_SCL__LPI2C2_SCL 0x40000b9e
+ MX93_PAD_I2C2_SDA__LPI2C2_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_pcal6524: pcal6524grp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x31e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
+ MX93_PAD_UART1_TXD__LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
+ MX93_PAD_DAP_TDI__LPUART5_RX 0x31e
+ MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
+ MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ /* need to config the SION for data and cmd pad, refer to ERR052021 */
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x1582
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x40001382
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x40001382
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x40001382
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x40001382
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x40001382
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x40001382
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x40001382
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x40001382
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x40001382
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
+ >;
+ };
+
+ /* need to config the SION for data and cmd pad, refer to ERR052021 */
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000138e
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000138e
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000138e
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000138e
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000138e
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000138e
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000138e
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000138e
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000138e
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ /* need to config the SION for data and cmd pad, refer to ERR052021 */
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x400013fe
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x400013fe
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x400013fe
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x400013fe
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x400013fe
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x400013fe
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x400013fe
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x400013fe
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x400013fe
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2_gpio_sleep: usdhc2gpiosleepgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CD_B__GPIO3_IO00 0x51e
+ >;
+ };
+
+ /* need to config the SION for data and cmd pad, refer to ERR052021 */
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ /* need to config the SION for data and cmd pad, refer to ERR052021 */
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ /* need to config the SION for data and cmd pad, refer to ERR052021 */
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_sleep: usdhc2-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__GPIO3_IO01 0x51e
+ MX93_PAD_SD2_CMD__GPIO3_IO02 0x51e
+ MX93_PAD_SD2_DATA0__GPIO3_IO03 0x51e
+ MX93_PAD_SD2_DATA1__GPIO3_IO04 0x51e
+ MX93_PAD_SD2_DATA2__GPIO3_IO05 0x51e
+ MX93_PAD_SD2_DATA3__GPIO3_IO06 0x51e
+ MX93_PAD_SD2_VSELECT__GPIO3_IO19 0x51e
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX93_PAD_WDOG_ANY__WDOG1_WDOG_ANY 0x31e
+ >;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
index bd14ba28690c081817111aaabef12fb56a7c56a4..f2a31a0eacabff07532aee989eebd75a0c3e22e0 100644
--- a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
@@ -1,71 +1,14 @@
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
/dts-v1/;
-#include <dt-bindings/usb/pd.h>
#include "imx93.dtsi"
+#include "imx93-11x11-frdm-common.dtsi"
/ {
compatible = "fsl,imx93-11x11-frdm", "fsl,imx93";
model = "NXP i.MX93 11X11 FRDM board";
- aliases {
- can0 = &flexcan2;
- ethernet0 = &fec;
- ethernet1 = &eqos;
- i2c0 = &lpi2c1;
- i2c1 = &lpi2c2;
- i2c2 = &lpi2c3;
- mmc0 = &usdhc1; /* EMMC */
- mmc1 = &usdhc2; /* uSD */
- rtc0 = &pcf2131;
- serial0 = &lpuart1;
- serial4 = &lpuart5;
- };
-
- chosen {
- stdout-path = &lpuart1;
- };
-
- flexcan2_phy: can-phy {
- compatible = "nxp,tja1051";
- #phy-cells = <0>;
- max-bitrate = <5000000>;
- silent-gpios = <&pcal6524 23 GPIO_ACTIVE_HIGH>;
- };
-
- gpio-keys {
- compatible = "gpio-keys";
-
- button-k2 {
- label = "Button K2";
- linux,code = <BTN_1>;
- gpios = <&pcal6524 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
- interrupt-parent = <&pcal6524>;
- interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
- };
-
- button-k3 {
- label = "Button K3";
- linux,code = <BTN_2>;
- gpios = <&pcal6524 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
- interrupt-parent = <&pcal6524>;
- interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
- };
- };
-
- reg_usdhc2_vmmc: regulator-usdhc2 {
- compatible = "regulator-fixed";
- off-on-delay-us = <12000>;
- pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
- pinctrl-names = "default";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-name = "VSD_3V3";
- vin-supply = <&buck4>;
- gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
reg_usdhc3_vmmc: regulator-usdhc3 {
compatible = "regulator-fixed";
regulator-name = "VPCIe_3V3";
@@ -76,51 +19,6 @@ reg_usdhc3_vmmc: regulator-usdhc3 {
enable-active-high;
};
- reserved-memory {
- ranges;
- #address-cells = <2>;
- #size-cells = <2>;
-
- linux,cma {
- compatible = "shared-dma-pool";
- alloc-ranges = <0 0x80000000 0 0x30000000>;
- reusable;
- size = <0 0x10000000>;
- linux,cma-default;
- };
-
- rsc_table: rsc-table@2021e000 {
- reg = <0 0x2021e000 0 0x1000>;
- no-map;
- };
-
- vdev0vring0: vdev0vring0@a4000000 {
- reg = <0 0xa4000000 0 0x8000>;
- no-map;
- };
-
- vdev0vring1: vdev0vring1@a4008000 {
- reg = <0 0xa4008000 0 0x8000>;
- no-map;
- };
-
- vdev1vring0: vdev1vring0@a4010000 {
- reg = <0 0xa4010000 0 0x8000>;
- no-map;
- };
-
- vdev1vring1: vdev1vring1@a4018000 {
- reg = <0 0xa4018000 0 0x8000>;
- no-map;
- };
-
- vdevbuffer: vdevbuffer@a4020000 {
- compatible = "shared-dma-pool";
- reg = <0 0xa4020000 0 0x100000>;
- no-map;
- };
- };
-
sound-mqs {
compatible = "fsl,imx-audio-mqs";
model = "mqs-audio";
@@ -134,269 +32,6 @@ usdhc3_pwrseq: mmc-pwrseq {
};
};
-&adc1 {
- vref-supply = <&buck5>;
- status = "okay";
-};
-
-&mu1 {
- status = "okay";
-};
-
-&cm33 {
- mboxes = <&mu1 0 1>,
- <&mu1 1 1>,
- <&mu1 3 1>;
- mbox-names = "tx", "rx", "rxdb";
- memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
- <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
- status = "okay";
-};
-
-&eqos {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&pinctrl_eqos>;
- pinctrl-1 = <&pinctrl_eqos_sleep>;
- phy-handle = <ðphy1>;
- phy-mode = "rgmii-id";
- status = "okay";
-
- mdio {
- compatible = "snps,dwmac-mdio";
- #address-cells = <1>;
- #size-cells = <0>;
- clock-frequency = <5000000>;
-
- ethphy1: ethernet-phy@1 {
- reg = <1>;
- reset-assert-us = <10000>;
- reset-deassert-us = <80000>;
- reset-gpios = <&pcal6524 15 GPIO_ACTIVE_LOW>;
- realtek,clkout-disable;
- };
- };
-};
-
-&fec {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&pinctrl_fec>;
- pinctrl-1 = <&pinctrl_fec_sleep>;
- phy-mode = "rgmii-id";
- phy-handle = <ðphy2>;
- fsl,magic-packet;
- status = "okay";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- clock-frequency = <5000000>;
-
- ethphy2: ethernet-phy@2 {
- reg = <2>;
- reset-assert-us = <10000>;
- reset-deassert-us = <80000>;
- reset-gpios = <&pcal6524 16 GPIO_ACTIVE_LOW>;
- realtek,clkout-disable;
- };
- };
-};
-
-&flexcan2 {
- phys = <&flexcan2_phy>;
- pinctrl-0 = <&pinctrl_flexcan2>;
- pinctrl-1 = <&pinctrl_flexcan2_sleep>;
- pinctrl-names = "default", "sleep";
- status = "okay";
-};
-
-&lpi2c1 {
- clock-frequency = <400000>;
- pinctrl-0 = <&pinctrl_lpi2c1>;
- pinctrl-names = "default";
- status = "okay";
-
- pcal6408: gpio@20 {
- compatible = "nxp,pcal6408";
- reg = <0x20>;
- #gpio-cells = <2>;
- gpio-controller;
- reset-gpios = <&pcal6524 20 GPIO_ACTIVE_LOW>;
- };
-};
-
-&lpi2c2 {
- clock-frequency = <400000>;
- pinctrl-0 = <&pinctrl_lpi2c2>;
- pinctrl-names = "default";
- status = "okay";
-
- pcal6524: gpio@22 {
- compatible = "nxp,pcal6524";
- reg = <0x22>;
- #interrupt-cells = <2>;
- interrupt-controller;
- interrupt-parent = <&gpio3>;
- interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
- #gpio-cells = <2>;
- gpio-controller;
- pinctrl-0 = <&pinctrl_pcal6524>;
- pinctrl-names = "default";
- /* does not boot with supplier set, because it is the bucks interrupt parent */
- /* vcc-supply = <&buck4>; */
- };
-
- pmic@25 {
- compatible = "nxp,pca9451a";
- reg = <0x25>;
- interrupt-parent = <&pcal6524>;
- interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
-
- regulators {
-
- buck1: BUCK1 {
- regulator-name = "VDD_SOC_0V8";
- regulator-min-microvolt = <610000>;
- regulator-max-microvolt = <950000>;
- regulator-always-on;
- regulator-boot-on;
- regulator-ramp-delay = <3125>;
- };
-
- buck2: BUCK2 {
- regulator-name = "LPD4_x_VDDQ_0V6";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <670000>;
- regulator-always-on;
- regulator-boot-on;
- regulator-ramp-delay = <3125>;
- };
-
- buck4: BUCK4 {
- regulator-name = "VDD_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- buck5: BUCK5 {
- regulator-name = "VDD_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- buck6: BUCK6 {
- regulator-name = "LPD4_x_VDD2_1V1";
- regulator-min-microvolt = <1060000>;
- regulator-max-microvolt = <1140000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo1: LDO1 {
- regulator-name = "NVCC_BBSM_1V8";
- regulator-min-microvolt = <1620000>;
- regulator-max-microvolt = <1980000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo4: LDO4 {
- regulator-name = "VDD_ANA_0V8";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <840000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo5: LDO5 {
- regulator-name = "NVCC_SD";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- regulator-boot-on;
- };
- };
- };
-
- eeprom: eeprom@50 {
- compatible = "atmel,24c256";
- reg = <0x50>;
- pagesize = <64>;
- vcc-supply = <&buck4>;
- };
-};
-
-&lpi2c3 {
- clock-frequency = <400000>;
- pinctrl-0 = <&pinctrl_lpi2c3>;
- pinctrl-names = "default";
- status = "okay";
-
- ptn5110: tcpc@50 {
- compatible = "nxp,ptn5110", "tcpci";
- reg = <0x50>;
- interrupt-parent = <&gpio3>;
- interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
-
- typec1_con: connector {
- compatible = "usb-c-connector";
- data-role = "dual";
- label = "USB-C";
- op-sink-microwatt = <15000000>;
- power-role = "dual";
- self-powered;
- sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
- PDO_VAR(5000, 20000, 3000)>;
- 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>;
- };
- };
- };
- };
- };
-
- pcf2131: rtc@53 {
- compatible = "nxp,pcf2131";
- reg = <0x53>;
- interrupt-parent = <&pcal6524>;
- interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
- };
-};
-
-&lpuart1 { /* console */
- pinctrl-0 = <&pinctrl_uart1>;
- pinctrl-names = "default";
- status = "okay";
-};
-
-&lpuart5 {
- pinctrl-0 = <&pinctrl_uart5>;
- pinctrl-names = "default";
- status = "okay";
-
- uart-has-rtscts;
-
- bluetooth {
- compatible = "nxp,88w8987-bt";
- device-wakeup-gpios = <&pcal6408 3 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&pcal6524 19 GPIO_ACTIVE_LOW>;
- vcc-supply = <®_usdhc3_vmmc>;
- };
-};
-
&mqs1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mqs1>;
@@ -418,57 +53,6 @@ &sai1 {
status = "okay";
};
-&usbotg1 {
- 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>;
- };
- };
-};
-
-&usbotg2 {
- disable-over-current;
- dr_mode = "host";
- samsung,picophy-dc-vol-level-adjust = <7>;
- samsung,picophy-pre-emp-curr-control = <3>;
- status = "okay";
-};
-
-&usdhc1 {
- bus-width = <8>;
- non-removable;
- pinctrl-0 = <&pinctrl_usdhc1>;
- pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
- pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
- pinctrl-names = "default", "state_100mhz", "state_200mhz";
- vmmc-supply = <&buck4>;
- status = "okay";
-};
-
-&usdhc2 {
- bus-width = <4>;
- cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
- no-mmc;
- no-sdio;
- 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_sleep>, <&pinctrl_usdhc2_gpio_sleep>;
- pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
- vmmc-supply = <®_usdhc2_vmmc>;
- status = "okay";
-};
-
&usdhc3 {
bus-width = <4>;
keep-power-in-suspend;
@@ -483,126 +67,8 @@ &usdhc3 {
status = "okay";
};
-&wdog3 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_wdog>;
- fsl,ext-reset-output;
- status = "okay";
-};
&iomuxc {
-
- pinctrl_eqos: eqosgrp {
- fsl,pins = <
- MX93_PAD_ENET1_MDC__ENET_QOS_MDC 0x57e
- MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
- MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
- MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
- MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
- MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
- MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e
- MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
- MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
- MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e
- MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
- MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
- MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e
- MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
- >;
- };
-
- pinctrl_eqos_sleep: eqossleepgrp {
- fsl,pins = <
- MX93_PAD_ENET1_MDC__GPIO4_IO00 0x31e
- MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x31e
- MX93_PAD_ENET1_RD0__GPIO4_IO10 0x31e
- MX93_PAD_ENET1_RD1__GPIO4_IO11 0x31e
- MX93_PAD_ENET1_RD2__GPIO4_IO12 0x31e
- MX93_PAD_ENET1_RD3__GPIO4_IO13 0x31e
- MX93_PAD_ENET1_RXC__GPIO4_IO09 0x31e
- MX93_PAD_ENET1_RX_CTL__GPIO4_IO08 0x31e
- MX93_PAD_ENET1_TD0__GPIO4_IO05 0x31e
- MX93_PAD_ENET1_TD1__GPIO4_IO04 0x31e
- MX93_PAD_ENET1_TD2__GPIO4_IO03 0x31e
- MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e
- MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e
- MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e
- >;
- };
-
- pinctrl_fec: fecgrp {
- fsl,pins = <
- MX93_PAD_ENET2_MDC__ENET1_MDC 0x57e
- MX93_PAD_ENET2_MDIO__ENET1_MDIO 0x57e
- MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0 0x57e
- MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e
- MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e
- MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x57e
- MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e
- MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e
- MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e
- MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e
- MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e
- MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e
- MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e
- MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
- >;
- };
-
- pinctrl_fec_sleep: fecsleepgrp {
- fsl,pins = <
- MX93_PAD_ENET2_MDC__GPIO4_IO14 0x51e
- MX93_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
- MX93_PAD_ENET2_RD0__GPIO4_IO24 0x51e
- MX93_PAD_ENET2_RD1__GPIO4_IO25 0x51e
- MX93_PAD_ENET2_RD2__GPIO4_IO26 0x51e
- MX93_PAD_ENET2_RD3__GPIO4_IO27 0x51e
- MX93_PAD_ENET2_RXC__GPIO4_IO23 0x51e
- MX93_PAD_ENET2_RX_CTL__GPIO4_IO22 0x51e
- MX93_PAD_ENET2_TD0__GPIO4_IO19 0x51e
- MX93_PAD_ENET2_TD1__GPIO4_IO18 0x51e
- MX93_PAD_ENET2_TD2__GPIO4_IO17 0x51e
- MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e
- MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e
- MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e
- >;
- };
-
- pinctrl_flexcan2: flexcan2grp {
- fsl,pins = <
- MX93_PAD_GPIO_IO25__CAN2_TX 0x139e
- MX93_PAD_GPIO_IO27__CAN2_RX 0x139e
- >;
- };
-
- pinctrl_flexcan2_sleep: flexcan2sleepgrp {
- fsl,pins = <
- MX93_PAD_GPIO_IO25__GPIO2_IO25 0x31e
- MX93_PAD_GPIO_IO27__GPIO2_IO27 0x31e
- >;
- };
-
- pinctrl_lpi2c1: lpi2c1grp {
- fsl,pins = <
- MX93_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
- MX93_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
- >;
- };
-
- pinctrl_lpi2c2: lpi2c2grp {
- fsl,pins = <
- MX93_PAD_I2C2_SCL__LPI2C2_SCL 0x40000b9e
- MX93_PAD_I2C2_SDA__LPI2C2_SDA 0x40000b9e
- >;
- };
-
- pinctrl_lpi2c3: lpi2c3grp {
- fsl,pins = <
- MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
- MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
- >;
- };
-
pinctrl_mqs1: mqs1grp {
fsl,pins = <
MX93_PAD_PDM_CLK__MQS1_LEFT 0x31e
@@ -610,149 +76,7 @@ MX93_PAD_PDM_BIT_STREAM0__MQS1_RIGHT 0x31e
>;
};
- pinctrl_pcal6524: pcal6524grp {
- fsl,pins = <
- MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
- >;
- };
-
- pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
- fsl,pins = <
- MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x31e
- >;
- };
-
- pinctrl_uart1: uart1grp {
- fsl,pins = <
- MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
- MX93_PAD_UART1_TXD__LPUART1_TX 0x31e
- >;
- };
-
- pinctrl_uart5: uart5grp {
- fsl,pins = <
- MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
- MX93_PAD_DAP_TDI__LPUART5_RX 0x31e
- MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
- MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
- >;
- };
-
- /* need to config the SION for data and cmd pad, refer to ERR052021 */
- pinctrl_usdhc1: usdhc1grp {
- fsl,pins = <
- MX93_PAD_SD1_CLK__USDHC1_CLK 0x1582
- MX93_PAD_SD1_CMD__USDHC1_CMD 0x40001382
- MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x40001382
- MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x40001382
- MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x40001382
- MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x40001382
- MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x40001382
- MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x40001382
- MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x40001382
- MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x40001382
- MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
- >;
- };
-
- /* need to config the SION for data and cmd pad, refer to ERR052021 */
- pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
- fsl,pins = <
- MX93_PAD_SD1_CLK__USDHC1_CLK 0x158e
- MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000138e
- MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000138e
- MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000138e
- MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000138e
- MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000138e
- MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000138e
- MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000138e
- MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000138e
- MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000138e
- MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
- >;
- };
-
- /* need to config the SION for data and cmd pad, refer to ERR052021 */
- pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
- fsl,pins = <
- MX93_PAD_SD1_CLK__USDHC1_CLK 0x15fe
- MX93_PAD_SD1_CMD__USDHC1_CMD 0x400013fe
- MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x400013fe
- MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x400013fe
- MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x400013fe
- MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x400013fe
- MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x400013fe
- MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x400013fe
- MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x400013fe
- MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x400013fe
- MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
- >;
- };
-
- pinctrl_usdhc2_gpio: usdhc2gpiogrp {
- fsl,pins = <
- MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e
- >;
- };
-
- pinctrl_usdhc2_gpio_sleep: usdhc2gpiosleepgrp {
- fsl,pins = <
- MX93_PAD_SD2_CD_B__GPIO3_IO00 0x51e
- >;
- };
-
- /* need to config the SION for data and cmd pad, refer to ERR052021 */
- pinctrl_usdhc2: usdhc2grp {
- fsl,pins = <
- MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582
- MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382
- MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382
- MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382
- MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382
- MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382
- MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
- >;
- };
-
/* need to config the SION for data and cmd pad, refer to ERR052021 */
- pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
- fsl,pins = <
- MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e
- MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e
- MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e
- MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e
- MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e
- MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e
- MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
- >;
- };
-
- /* need to config the SION for data and cmd pad, refer to ERR052021 */
- pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
- fsl,pins = <
- MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe
- MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe
- MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe
- MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe
- MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe
- MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe
- MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
- >;
- };
-
- pinctrl_usdhc2_sleep: usdhc2-sleepgrp {
- fsl,pins = <
- MX93_PAD_SD2_CLK__GPIO3_IO01 0x51e
- MX93_PAD_SD2_CMD__GPIO3_IO02 0x51e
- MX93_PAD_SD2_DATA0__GPIO3_IO03 0x51e
- MX93_PAD_SD2_DATA1__GPIO3_IO04 0x51e
- MX93_PAD_SD2_DATA2__GPIO3_IO05 0x51e
- MX93_PAD_SD2_DATA3__GPIO3_IO06 0x51e
- MX93_PAD_SD2_VSELECT__GPIO3_IO19 0x51e
- >;
- };
-
- /* need to config the SION for data and cmd pad, refer to ERR052021 */
pinctrl_usdhc3: usdhc3grp {
fsl,pins = <
MX93_PAD_SD3_CLK__USDHC3_CLK 0x1582
@@ -798,10 +122,4 @@ MX93_PAD_SD3_DATA2__GPIO3_IO24 0x31e
MX93_PAD_SD3_DATA3__GPIO3_IO25 0x31e
>;
};
-
- pinctrl_wdog: wdoggrp {
- fsl,pins = <
- MX93_PAD_WDOG_ANY__WDOG1_WDOG_ANY 0x31e
- >;
- };
};
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox