* Re: [PATCH rc v3 0/5] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Nicolin Chen @ 2026-04-29 3:55 UTC (permalink / raw)
To: will, robin.murphy, jgg, kevin.tian
Cc: joro, praan, baolu.lu, miko.lenczewski, smostafa,
linux-arm-kernel, iommu, linux-kernel, stable, jamien
In-Reply-To: <cover.1777150307.git.nicolinc@nvidia.com>
On Sat, Apr 25, 2026 at 02:30:45PM -0700, Nicolin Chen wrote:
> This is on Github:
> https://github.com/nicolinc/iommufd/commits/smmuv3_kdump-v3
>
> Changelog
> v3
> * s/OPT_KDUMP/OPT_KDUMP_ADOPT
> * Do not adopt if GERROR_SFM_ERR
> * Retain CR0_ATSCHK beside CR0_SMMUEN
> * Clear latched GERROR bits (e.g. CMDQ_ERR)
> * Assert ARM_SMMU_FEAT_COHERENCY in adopt functions
> * Add STE.Cfg check in arm_smmu_is_attach_deferred()
> * Fix validations on return codes from devm_memremap()
> * Sanitize crashed kernel register values in adopt functions
> * Drop unnecessary l2ptrs guard in arm_smmu_is_attach_deferred()
> * Don't enable PRIQ/EVTQ irqs and guard the irq functions for combined
> irq cases
https://sashiko.dev/#/patchset/cover.1777150307.git.nicolinc%40nvidia.com
Sashiko pointed out a few more comments on v3. Most of them are
interesting to address.
I have made some updates to the series and will send v4 after a
final check.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v6 3/4] clk: keystone: sci-clk: add restore_context() operation
From: Stephen Boyd @ 2026-04-29 3:57 UTC (permalink / raw)
To: Thomas Richard (TI), Michael Turquette, Nishanth Menon,
Santosh Shilimkar, Tero Kristo
Cc: Gregory CLEMENT, richard.genoud, Udit Kumar, Abhash Kumar,
Thomas Petazzoni, linux-arm-kernel, linux-kernel, linux-clk,
Thomas Richard (TI), Dhruva Gole, Kendall Willis
In-Reply-To: <20260427-ti-sci-jacinto-s2r-restore-irq-v6-3-72c6468cb2ab@bootlin.com>
Quoting Thomas Richard (TI) (2026-04-27 05:21:36)
> Implement the restore_context() operation to restore the clock rate and the
> clock parent state. The clock rate is saved in sci_clk struct during
> set_rate() and recalc_rate() operations. The parent index is saved in
> sci_clk struct during set_parent() operation. During clock registration,
> the core retrieves each clock’s parent using get_parent() operation to
> ensure the internal clock tree reflects the actual hardware state,
> including any configurations made by the bootloader. So we also save the
> parent index in get_parent().
>
> Reviewed-by: Dhruva Gole <d-gole@ti.com>
> Reviewed-by: Kendall Willis <k-willis@ti.com>
> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* [PATCH 0/3] drm/bridge: Add Lontium LT8711UXD DP-to-HDMI transparent bridge
From: Dennis Gilmore @ 2026-04-29 4:15 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Alexey Charkov, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Peter Robinson, Jonas Karlman,
Jernej Skrabec, Laurent Pinchart, Dennis Gilmore
The Lontium LT8711UXD supports two modes of operation: autonomous mode,
where it configures itself via strapping resistors, and I2C-controlled
mode. Review of the earlier Orange Pi 5 Pro series raised the question
of how a future board requiring I2C control should be handled, a second
compatible with a driver or we make both work with a single compatible
This patch set covers autonomous mode only. On the Orange Pi 5 Pro,
resistors R9, R17, and R27 are unpopulated, which straps MODE_SEL low
leaving the device invisible on the I2C bus; I2C control is not enabled
on this board.
The earlier review thread is at:
https://lore.kernel.org/linux-devicetree/20260425031011.2529364-4-dennis@ausil.us/
One non-obvious detail in the DTS patch: vcc3v3_dp carries
regulator-always-on because simple-bridge only fires pre_enable once a
modeset starts, but no modeset will start until the connector reports
connected, and the connector won't report connected until HPD asserts,
and HPD won't assert until the bridge is powered. Holding the enable
line high from boot breaks this deadlock.
Tested on Orange Pi 5 Pro with Linux 7.0: HPD asserts, EDID reads,
link trains, and scanout reaches the display.
Please take a look.
Thank you,
Dennis Gilmore
Dennis Gilmore (3):
dt-bindings: display: bridge: simple: document the Lontium LT8711UXD
DP-to-HDMI bridge
drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
arm64: dts: rockchip: orangepi-5-pro: Add LT8711UXD DP-to-HDMI bridge
.../display/bridge/simple-bridge.yaml | 1 +
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 88 ++++++++++++++++++-
drivers/gpu/drm/bridge/simple-bridge.c | 5 ++
3 files changed, 91 insertions(+), 3 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH 2/3] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-29 4:15 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Alexey Charkov, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Peter Robinson, Jonas Karlman,
Jernej Skrabec, Laurent Pinchart, Dennis Gilmore,
Dmitry Baryshkov
In-Reply-To: <20260429041528.558254-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4 to
HDMI2.0 converter, designed to connect a USB Type-C source or a DP1.4
source to an HDMI2.0 sink. The device can be run uncontrolled or it can
be attached over I2C, this supports the uncontrolled mode.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..42c1f3d5ba0c 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
.data = &(const struct simple_bridge_info) {
.connector_type = DRM_MODE_CONNECTOR_HDMIA,
},
+ }, {
+ .compatible = "lontium,lt8711uxd",
+ .data = &(const struct simple_bridge_info) {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
+ },
}, {
.compatible = "parade,ps185hdm",
.data = &(const struct simple_bridge_info) {
--
2.54.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: display: bridge: simple: document the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-29 4:15 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Alexey Charkov, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Peter Robinson, Jonas Karlman,
Jernej Skrabec, Laurent Pinchart, Dennis Gilmore,
Krzysztof Kozlowski
In-Reply-To: <20260429041528.558254-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or a DP1.4
source to an HDMI2.0 sink. The device can be running uncontrolled or it
can be attached over I2C, the bindings describe the uncontrolled mode.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index e6808419f625..752c736c8f85 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -30,6 +30,7 @@ properties:
- algoltek,ag6311
- asl-tek,cs5263
- dumb-vga-dac
+ - lontium,lt8711uxd
- parade,ps185hdm
- radxa,ra620
- realtek,rtd2171
--
2.54.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: rockchip: orangepi-5-pro: Add LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-29 4:15 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Alexey Charkov, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Peter Robinson, Jonas Karlman,
Jernej Skrabec, Laurent Pinchart, Dennis Gilmore
In-Reply-To: <20260429041528.558254-1-dennis@ausil.us>
Wire up the second HDMI port on the Orange Pi 5 Pro. It uses a Lontium
LT8711UXD high performance two lane Type-C/DP1.4 to HDMI2.0 converter,
designed to connect a USB Type-C source or a DP1.4 source to an HDMI2.0
sink. The bridge can be controlled via i2c or run as an autonomous device.
The Orange Pi 5 Pro has i2c wired up to i2c6, however there are 10k
resistors left off of R9 and R17 to enable MODE_SEL, and R27 for
I2C_ADDR resulting in MODE_SEL going to GND and the bridge let in
autonomous mode. As shipped I verified that the bridge does not show up
on the i2c bus.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 88 ++++++++++++++++++-
1 file changed, 85 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
index 895d954a9f23..67363709c4ca 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
@@ -14,6 +14,44 @@ aliases {
mmc2 = &sdio;
};
+ hdmi1-con {
+ compatible = "hdmi-connector";
+ label = "HDMI1 OUT";
+ type = "a";
+
+ port {
+ hdmi1_con_in: endpoint {
+ remote-endpoint = <<8711uxd_out>;
+ };
+ };
+ };
+
+ hdmi-bridge {
+ compatible = "lontium,lt8711uxd";
+ vdd-supply = <&vcc3v3_dp>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lt8711uxd_in: endpoint {
+ remote-endpoint = <&dp0_out_con>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lt8711uxd_out: endpoint {
+ remote-endpoint = <&hdmi1_con_in>;
+ };
+ };
+ };
+ };
+
analog-sound {
compatible = "simple-audio-card";
pinctrl-names = "default";
@@ -72,6 +110,19 @@ fan: pwm-fan {
pwms = <&pwm2 0 20000000 0>;
};
+ vcc3v3_dp: regulator-vcc3v3-dp {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp_bridge_en>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_dp";
+ regulator-always-on;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
vcc3v3_eth: regulator-vcc3v3-eth {
compatible = "regulator-fixed";
enable-active-high;
@@ -116,6 +167,24 @@ typea_con: usb-a-connector {
};
};
+&dp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp0m0_pins>;
+ status = "okay";
+};
+
+&dp0_in {
+ dp0_in_vp1: endpoint {
+ remote-endpoint = <&vp1_out_dp0>;
+ };
+};
+
+&dp0_out {
+ dp0_out_con: endpoint {
+ remote-endpoint = <<8711uxd_in>;
+ };
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1m4_xfer>;
@@ -217,6 +286,12 @@ bt_wake_host_irq: bt-wake-host-irq {
};
};
+ dp {
+ dp_bridge_en: dp-bridge-en {
+ rockchip,pins = <3 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
ethernet {
ethernet_en: ethernet-en {
rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_down>;
@@ -350,9 +425,16 @@ &usb_host0_xhci {
&usbdp_phy0 {
/*
- * The USB3 Type-A host connector is wired to PHY lanes 2/3. Lanes 0/1
- * are connected to the LT8711UXD DP-to-HDMI bridge on the board.
- * dp-lane-mux routes USB3 SuperSpeed to the correct lanes.
+ * USBDP PHY0 is wired to a USB3 Type-A host connector via lanes 2/3.
+ * Additionally lanes 0/1 and the aux channel are wired to the
+ * Lontium LT8711UXD DP-to-HDMI bridge feeding the HDMI1 connector.
*/
rockchip,dp-lane-mux = <0 1>;
};
+
+&vp1 {
+ vp1_out_dp0: endpoint@a {
+ reg = <ROCKCHIP_VOP2_EP_DP0>;
+ remote-endpoint = <&dp0_in_vp1>;
+ };
+};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 5/7] arm64: dts: mediatek: Add #{address,size}-cells to Chromium-based /firmware
From: Chen-Yu Tsai @ 2026-04-29 4:17 UTC (permalink / raw)
To: Brian Norris
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Heiko Stuebner, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Konrad Dybcio,
devicetree, Doug Anderson, linux-arm-kernel, Tzung-Bi Shih,
chrome-platform, linux-rockchip, Julius Werner, Alim Akhtar,
cros-qcom-dts-watchers, linux-arm-msm, linux-tegra,
linux-samsung-soc, linux-kernel
In-Reply-To: <20260428200712.2660635-6-briannorris@chromium.org>
On Wed, Apr 29, 2026 at 1:12 PM Brian Norris <briannorris@chromium.org> wrote:
>
> Chromium/Depthcharge bootloaders may dynamically add a few device nodes
> to a system's DTB under a /firmware node. A typical DT looks something
> like the following:
>
> / {
> firmware {
> ranges;
>
> coreboot {
> compatible = "coreboot";
> reg = <...>;
> ...;
> };
> };
> };
>
> Notably, the /firmware node has an empty 'ranges', but does not have
> address/size-cells.
>
> Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating
> non-translatable addresses") started requiring #address-cells for a
> device's parent if we want to use the reg resource in a device node.
> This leads to errors like the following:
>
> [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
>
> Add appropriate #{address,size}-cells to work around the problem.
>
> Note that Google has also patched the Depthcharge bootloader source to
> add {address,size}-cells [1], but bootloader updates are typically
> delivered only via Google OS updates. Not all users install Google
> software updates, and even if they do, Google may not produce updated
> binaries for all/older devices.
>
> [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/
> https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
> #size-cells for firmware node")
>
> Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
> Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
^ permalink raw reply
* Re: [PATCH 1/7] arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based /firmware
From: Chen-Yu Tsai @ 2026-04-29 4:17 UTC (permalink / raw)
To: Brian Norris
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Heiko Stuebner, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Konrad Dybcio,
devicetree, Doug Anderson, linux-arm-kernel, Tzung-Bi Shih,
chrome-platform, linux-rockchip, Julius Werner, Alim Akhtar,
cros-qcom-dts-watchers, linux-arm-msm, linux-tegra,
linux-samsung-soc, linux-kernel
In-Reply-To: <20260428200712.2660635-2-briannorris@chromium.org>
On Wed, Apr 29, 2026 at 1:12 PM Brian Norris <briannorris@chromium.org> wrote:
>
> Chromium/Depthcharge bootloaders may dynamically add a few device nodes
> to a system's DTB under a /firmware node. A typical DT looks something
> like the following:
>
> ## From a RK3399 Gru/Kevin Chromebook:
> # find /sys/firmware/devicetree/base/firmware
> /sys/firmware/devicetree/base/firmware
> /sys/firmware/devicetree/base/firmware/coreboot
> /sys/firmware/devicetree/base/firmware/coreboot/ram-code
> /sys/firmware/devicetree/base/firmware/coreboot/compatible
> /sys/firmware/devicetree/base/firmware/coreboot/board-id
> /sys/firmware/devicetree/base/firmware/coreboot/reg
> /sys/firmware/devicetree/base/firmware/coreboot/name
> /sys/firmware/devicetree/base/firmware/chromeos
> /sys/firmware/devicetree/base/firmware/chromeos/readonly-firmware-version
> /sys/firmware/devicetree/base/firmware/chromeos/active-ec-firmware
> /sys/firmware/devicetree/base/firmware/chromeos/firmware-version
> /sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-storage
> /sys/firmware/devicetree/base/firmware/chromeos/vboot-shared-data
> /sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-size
> /sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-offset
> /sys/firmware/devicetree/base/firmware/chromeos/hardware-id
> /sys/firmware/devicetree/base/firmware/chromeos/compatible
> /sys/firmware/devicetree/base/firmware/chromeos/firmware-type
> /sys/firmware/devicetree/base/firmware/chromeos/fmap-offset
> /sys/firmware/devicetree/base/firmware/chromeos/name
> /sys/firmware/devicetree/base/firmware/ranges
> /sys/firmware/devicetree/base/firmware/name
>
> The /firmware node has an empty 'ranges', but does not have
> address/size-cells.
>
> Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating
> non-translatable addresses") started requiring #address-cells for a
> device's parent if we want to use the reg resource in a device node.
> This leads to errors like the following:
>
> [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
>
> Add appropriate #{address,size}-cells to work around the problem.
>
> Note that Google has also patched the Depthcharge bootloader source to
> add {address,size}-cells [1], but bootloader updates are typically
> delivered only via Google OS updates. Not all users install Google
> software updates, and even if they do, Google may not produce updated
> binaries for all/older devices.
>
> [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/
> https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
> #size-cells for firmware node")
>
> Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
> Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Joseph Guo (OSS) @ 2026-04-29 4:17 UTC (permalink / raw)
To: Fabio Estevam, Joseph Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, devicetree,
linux-kernel, imx, linux-arm-kernel, xinyu.chen, justin.jiang
In-Reply-To: <CAOMZO5DV4Nnc+7DfAZT-VYDqxniz=ROR4-DnH3x9NbU4E8d9mQ@mail.gmail.com>
On 4/29/2026 9:37 AM, Fabio Estevam wrote:
> On Tue, Apr 28, 2026 at 5:03 AM Joseph Guo <qijian.guo@nxp.com> wrote:
>>
>> NXP i.MX95 19x19 FRDM PRO is cost-effective with extensive
>> expansion capabilities based on the i.MX95 19x19 SoC.
>
> It would be good to explain the difference between the i.MX95 FRDM PRO
> and i.MX95 FRDM.
>
> Also, does it make sense to share common nodes in a dtsi that can be
> used by the two variants?
Hi Fabio,
Yes, I will explain the difference between these two boards in next version.
But actually these two boards have totally different hardware design. So actually only few nodes which
are not related to the hardware (which means the IPs inside the SoC) can be common.
Their SoC is also different package. 95 FRDM PRO is 19x19 and 95 15x15 FRDM is 15x15.
I think it is enough to create a individual dts for this board.
Regards,
Joseph
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: mediatek,mt6351: convert to DT schema
From: Mark Brown @ 2026-04-28 8:01 UTC (permalink / raw)
To: lgirdwood, robh, krzk+dt, conor+dt, Manish Baing
Cc: matthias.bgg, angelogioacchino.delregno, kaichieh.chuang,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260424210302.39972-1-manishbaing2789@gmail.com>
On Fri, 24 Apr 2026 21:03:02 +0000, Manish Baing wrote:
> ASoC: dt-bindings: mediatek,mt6351: convert to DT schema
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] ASoC: dt-bindings: mediatek,mt6351: convert to DT schema
https://git.kernel.org/broonie/asoc/c/0770899ca192
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: mediatek,mt6351: convert to DT schema
From: Mark Brown @ 2026-04-28 23:18 UTC (permalink / raw)
To: lgirdwood, Manish Baing
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
kaichieh.chuang, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Krzysztof Kozlowski
In-Reply-To: <20260428171644.5703-1-manishbaing2789@gmail.com>
On Tue, 28 Apr 2026 17:16:44 +0000, Manish Baing wrote:
> ASoC: dt-bindings: mediatek,mt6351: convert to DT schema
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] ASoC: dt-bindings: mediatek,mt6351: convert to DT schema
https://git.kernel.org/broonie/sound/c/f103e6c27fa2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3] remoteproc: xlnx: check remote core state
From: Beleswar Prasad Padhi @ 2026-04-29 4:28 UTC (permalink / raw)
To: Tanmay Shah, michal.simek, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
In-Reply-To: <20260428221855.313752-1-tanmay.shah@amd.com>
On 29/04/26 03:48, Tanmay Shah wrote:
> The remote state is set to RPROC_DETACHED if the resource table is found
> in the memory. However, this can be wrong if the remote is not started,
> but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
> to the firmware to request the state of the RPU node. If the RPU is
> actually out of reset and running, only then move the remote state to
> RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
>
> Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support")
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Thanks,
Beleswar
[...]
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: remoteproc: add imx-rproc-psci binding
From: Rob Herring (Arm) @ 2026-04-29 4:33 UTC (permalink / raw)
To: Jiafei Pan
Cc: imx, peng.fan, mathieu.poirier, mingkai.hu, devicetree,
linux-kernel, linux-remoteproc, Zhiqiang.Hou, festevam, kernel,
Frank.Li, linux-arm-kernel, andersson, s.hauer
In-Reply-To: <20260429031047.30893-2-Jiafei.Pan@nxp.com>
On Wed, 29 Apr 2026 11:10:43 +0800, Jiafei Pan wrote:
> Add compatible string "fsl,imx-rproc-psci" for i.MX Cortex-A Core's
> remoteproc support.
>
> Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
> ---
> .../remoteproc/fsl,imx-rproc-psci.yaml | 64 +++++++++++++++++++
> 1 file changed, 64 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml: properties:fsl,cpus-bits: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref
from schema $id: http://devicetree.org/meta-schemas/core.yaml
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dts:8.9-16: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dts:5.21-14.7: Warning (avoid_default_addr_size): /reserved-memory: Relying on default #address-cells value
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dts:5.21-14.7: Warning (avoid_default_addr_size): /reserved-memory: Relying on default #size-cells value
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dtb: /: 'compatible' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dtb: /: '#address-cells' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dtb: /: '#size-cells' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.dtb: remoteproc-ca55-1 (fsl,imx-rproc-psci): fsl,cpus-bits: 2 is not of type 'array'
from schema $id: http://devicetree.org/schemas/property-units.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260429031047.30893-2-Jiafei.Pan@nxp.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v1] pmdomain: ti_sci: re-sync TIFS with genpd on resume
From: Vignesh Raghavendra @ 2026-04-29 4:33 UTC (permalink / raw)
To: Vitor Soares, Nishanth Menon, Tero Kristo, Santosh Shilimkar,
Ulf Hansson
Cc: Vitor Soares, linux-arm-kernel, linux-pm, linux-kernel,
Tomi Valkeinen, Kevin Hilman, vishalm, sebin.francis, d-gole,
Devarsh Thakkar, stable
In-Reply-To: <20260427074808.3244226-2-ivitro@gmail.com>
Hi Vitor
On 27/04/26 13:18, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> When a device in a TI SCI power domain is on the wakeup path of a
> wakeup-capable child, the suspend path skips genpd_sync_power_off().
> No put_device is sent to TIFS and the domain's genpd status remains
> ON.
Correction of terminologies: TIFS is Root of trust component and is not
usually involved in power management, that would be DM (Device Manager)
But to be really sure who is doing what, Could you provide an example
and the platform on which you see the issue / external abort?
>
> TIFS powers off the hardware during deep sleep regardless, since it
> was never informed to keep the domain active. On resume, because the
> domain's genpd status is ON, no get_device is issued. The driver
> then accesses registers of a powered-off domain, causing a
> synchronous external abort (AXI bus error, ESR 0x96000010).
Hmm, if something is wakeup source, I would expect even TIFS/DM not to
turn if off, else module wakeup wouldn't work.
>
> Commit 0b5fe1c4ab3c ("pmdomain: ti-sci: Set PD on/off state according
> to the HW state") exposed this. Before, domain status was initialized
> to OFF, so get_device was always issued on resume.
>
> Add a .resume hook that queries the domain's state from TIFS and
> re-syncs TIFS with get_device when genpd has it ON but TIFS has it
> OFF. The hook is only registered when the is_on op is available,
> since detection depends on it.
>
> Move ti_sci_pm_pd_is_on() earlier in the file so it is available to
> the resume hook.
>
> Fixes: 0b5fe1c4ab3c ("pmdomain: ti-sci: Set PD on/off state according to the HW state")
> Cc: stable@vger.kernel.org # 6.18+
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> ---
[...]
--
Regards
Vignesh
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v2] pinctrl: qcom: Make important drivers default
From: Krzysztof Kozlowski @ 2026-04-29 6:16 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Russell King, Bjorn Andersson, Konrad Dybcio, Linus Walleij,
linux-arm-kernel, linux-kernel, linux-arm-msm, linux-gpio,
Konrad Dybcio
In-Reply-To: <lccuj5tcir57c3pzlcvyjmle36alr64zv257si4taqis3novrs@exgphqb3k6tx>
On 28/04/2026 23:13, Dmitry Baryshkov wrote:
> On Tue, Apr 28, 2026 at 06:35:49PM +0200, Krzysztof Kozlowski wrote:
>> The main SoC TLMM (Top-Level Multiplexer) pin controller drivers are
>> essential for booting up SoCs and are not really optional for a given
>> platform. Kernel should not ask users choice of drivers when that
>> choice is obvious and known to the developers that answer should be
>> 'yes' or 'module'.
>>
>> Switch all Qualcomm TLMM pin controller drivers to a default 'yes' for
>> ARCH_QCOM. This has impact:
>>
>> 1. arm64 defconfig: enable PINCTRL_SM7150, PINCTRL_IPQ9650 and
>> PINCTRL_HAWI, which were not selected before but should be, because
>> these platforms need them for proper boot.
>>
>> 2. arm qcom_defconfig: no changes.
>>
>> 3. arm multi_v7 defconfig: enable drivers necessary to boot ARM 32-bit
>> platforms, which are already enabled on qcom_defconfig.
>>
>> 4. COMPILE_TEST builds: enable by default all drivers for arm or arm64
>> builds, whenever ARCH_QCOM is selected. This has impact on build
>> time and feels logical, because if one selects ARCH_QCOM then
>> probably by default wants to build test it entirely. Kernels with
>> COMPILE_TEST are not supposed to be used for booting.
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> Reviewed-by: Linus Walleij <linusw@kernel.org>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
>>
>> I did similar change for clocks and I will be continuing with
>> interconnect and other missing pieces.
>>
>> Changes in v2:
>> 1. Rebase on Linus W. devel branch. This should go with pinctrl, I
>> think.
>> 2. Add tags.
>> 3. Update also PINCTRL_IPQ9650.
>> ---
>> arch/arm/configs/multi_v7_defconfig | 8 ----
>> arch/arm/configs/qcom_defconfig | 15 -------
>> arch/arm64/configs/defconfig | 46 ----------------------
>> drivers/pinctrl/qcom/Kconfig | 1 +
>> drivers/pinctrl/qcom/Kconfig.msm | 61 +++++++++++++++++++++++++++++
>
> I think it would have been better split into 3 patches, but this way is
> also fine.
You mean defconfigs as separate patches? I could do that and I was
thinking about it, but many people do testing with defconfig and such
defconfig would be nonbisectable here.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arch: arm64: fix KERNEL_SEGMENT_COUNT error
From: zhaoyang.huang @ 2026-04-29 6:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Ard Biesheuvel, linux-arm-kernel,
linux-kernel, Zhaoyang Huang, steve.kang
From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
During debug of a kernel panic, we find that the pte_t of the final
part of [data, end] segment got overflow to the next page of
init_pg_end[1] which is the gap page before early_init_stack[2].
This should be introduced by the KERNEL_SEGMENT_COUNT's value is 5
which should be 6 as map_segment are called 6 times for the segments
of (text, stext, rodata, inittext, initdata, data+bss)
[1]
crash_arm64_v9.0.1> vtop ffffffed00601000
VIRTUAL PHYSICAL
ffffffed00601000 83401000
PAGE DIRECTORY: ffffffecffd62000
PGD: ffffffecffd62da0 => 10000000833fb003
PMD: ffffff80033fb018 => 10000000833fe003
PTE: ffffff80033fe008 => 68000083401f03
PAGE: 83401000
PTE PHYSICAL FLAGS
68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffffffec00d0040 83401000 0 0 1 4000 reserved
[2]
ffffffed002c8000 (r) __pi__data
ffffffed0054e000 (d) __pi___bss_start
ffffffed005f5000 (b) __pi_init_pg_dir
ffffffed005fe000 (b) __pi_init_pg_end
ffffffed005ff000 (B) early_init_stack
ffffffed00608000 (b) __pi__end
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
arch/arm64/include/asm/kernel-pgtable.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
index 74a4f738c5f5..14dd1c52552a 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -64,8 +64,8 @@
#define INIT_IDMAP_FDT_PAGES (EARLY_PAGES(INIT_IDMAP_PGTABLE_LEVELS, 0UL, UL(MAX_FDT_SIZE), 1) - 1)
#define INIT_IDMAP_FDT_SIZE ((INIT_IDMAP_FDT_PAGES + EARLY_IDMAP_EXTRA_FDT_PAGES) * PAGE_SIZE)
-/* The number of segments in the kernel image (text, rodata, inittext, initdata, data+bss) */
-#define KERNEL_SEGMENT_COUNT 5
+/* The number of segments in the kernel image (text, stext, rodata, inittext, initdata, data+bss) */
+#define KERNEL_SEGMENT_COUNT 6
#if SWAPPER_BLOCK_SIZE > SEGMENT_ALIGN
#define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 1)
--
2.25.1
^ permalink raw reply related
* [PATCH v2 0/7] arm64: dts: rockchip: Add peripheral support for Khadas Edge 2L
From: Gray Huang @ 2026-04-29 6:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
This patch series adds support for several key peripherals to the
Khadas Edge 2L board, which is based on the Rockchip RK3576 SoC.
These patches build upon the basic board support that was previously
applied to the rockchip tree. This series enables essential
functionalities including power management, RTC, wireless connectivity,
graphics, display output, and USB support.
Summary of changes:
- Enable PMIC (RK806) and configure CPU regulators.
- Enable HYM8563 RTC as the AP6275P Wi-Fi LPO clock source.
- Enable PCIe-based Wi-Fi (AP6275P).
- Enable Mali GPU with proper power supply.
- Enable VOP2 and HDMI display output.
- Enable USB 3.0 Host and USB 2.0 (via internal hub).
- Enable Bluetooth (UART5) for the Ampak module.
Changes in v2:
- Split the former AP6275P wireless patch into separate HYM8563 RTC and
AP6275P Wi-Fi patches.
- Reorder DTS override nodes to follow the requested placement and
alphabetical grouping.
Gray Huang (7):
arm64: dts: rockchip: Add PMIC support for Khadas Edge 2L
arm64: dts: rockchip: Add HYM8563 RTC for Khadas Edge 2L
arm64: dts: rockchip: Add AP6275P wireless support for Khadas Edge 2L
arm64: dts: rockchip: Enable GPU for Khadas Edge 2L
arm64: dts: rockchip: Add HDMI and VOP support for Khadas Edge 2L
arm64: dts: rockchip: Enable USB for Khadas Edge 2L
arm64: dts: rockchip: Add Bluetooth support for Khadas Edge 2L
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 620 ++++++++++++++++++
1 file changed, 620 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v2 1/7] arm64: dts: rockchip: Add PMIC support for Khadas Edge 2L
From: Gray Huang @ 2026-04-29 6:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260429063712.2150938-1-gray.huang@wesion.com>
Add RK806 PMIC support for the Khadas Edge 2L board. Assign the
corresponding PMIC regulators (vdd_cpu_lit_s0 and vdd_cpu_big_s0)
to the little and big CPU clusters to enable proper power
management and CPU frequency scaling.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 413 ++++++++++++++++++
1 file changed, 413 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 68630379af63..5781deae00d9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -17,8 +17,421 @@ aliases {
chosen {
stdout-path = "serial0:1500000n8";
};
+
+ vcc_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_2v0_pldo_s3";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ vin-supply = <&vcc_sys>;
+ };
+
+
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
};
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&i2c1 {
+ status = "okay";
+
+ rk806: pmic@23 {
+ compatible = "rockchip,rk806";
+ reg = <0x23>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+ <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+ system-power-controller;
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc5-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
+ vcc8-supply = <&vcc_sys>;
+ vcc9-supply = <&vcc_sys>;
+ vcc10-supply = <&vcc_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc_sys>;
+ vcc13-supply = <&vcc_1v1_nldo_s3>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc_sys>;
+
+ rk806_dvs1_null: dvs1-null-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs2_null: dvs2-null-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs3_null: dvs3-null-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs1_slp: dvs1-slp-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun1";
+ };
+
+ rk806_dvs1_pwrdn: dvs1-pwrdn-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun2";
+ };
+
+ rk806_dvs1_rst: dvs1-rst-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun3";
+ };
+
+ rk806_dvs2_slp: dvs2-slp-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun1";
+ };
+
+ rk806_dvs2_pwrdn: dvs2-pwrdn-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun2";
+ };
+
+ rk806_dvs2_rst: dvs2-rst-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun3";
+ };
+
+ rk806_dvs2_dvs: dvs2-dvs-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun4";
+ };
+
+ rk806_dvs2_gpio: dvs2-gpio-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun5";
+ };
+
+ rk806_dvs3_slp: dvs3-slp-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun1";
+ };
+
+ rk806_dvs3_pwrdn: dvs3-pwrdn-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun2";
+ };
+
+ rk806_dvs3_rst: dvs3-rst-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun3";
+ };
+
+ rk806_dvs3_dvs: dvs3-dvs-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun4";
+ };
+
+ rk806_dvs3_gpio: dvs3-gpio-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun5";
+ };
+
+ regulators {
+ vdd_cpu_big_s0: dcdc-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_big_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_npu_s0: dcdc-reg2 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_npu_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_lit_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_lit_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vcc_3v3_s3: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd_gpu_s0: dcdc-reg5 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ vddq_ddr_s0: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vddq_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_logic_s0: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <800000>;
+ regulator-name = "vdd_logic_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s3: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_ddr_s0: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdd_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pldo2_s0: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_pldo2_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_1v2_s0: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdda_1v2_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcca_3v3_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_pldo6_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdda_ddr_pll_s0: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdda_ddr_pll_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v75_hdmi_s0: nldo-reg3 {
+ regulator-boot-on;
+ regulator-min-microvolt = <837500>;
+ regulator-max-microvolt = <837500>;
+ regulator-name = "vdda0v75_hdmi_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v85_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdda_0v85_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v75_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdda_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+
&sdhci {
bus-width = <8>;
no-sdio;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/7] arm64: dts: rockchip: Add HYM8563 RTC for Khadas Edge 2L
From: Gray Huang @ 2026-04-29 6:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260429063712.2150938-1-gray.huang@wesion.com>
The Khadas Edge 2L uses an on-board HYM8563 RTC connected to
I2C2. Enable it and expose its 32.768kHz clock output so later
board-level patches can reference it as the LPO clock source for
the AP6275P wireless module.
Mark the RTC as a wakeup source as well.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../boot/dts/rockchip/rk3576-khadas-edge-2l.dts | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 5781deae00d9..c85b219fe409 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -46,8 +46,6 @@ vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
regulator-max-microvolt = <2000000>;
vin-supply = <&vcc_sys>;
};
-
-
};
&cpu_l0 {
@@ -431,6 +429,17 @@ regulator-state-mem {
};
};
+&i2c2 {
+ status = "okay";
+
+ hym8563: hym8563@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ wakeup-source;
+ };
+};
&sdhci {
bus-width = <8>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/7] arm64: dts: rockchip: Enable GPU for Khadas Edge 2L
From: Gray Huang @ 2026-04-29 6:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260429063712.2150938-1-gray.huang@wesion.com>
Enable the Mali GPU node on the Khadas Edge 2L board. Assign the
corresponding regulator to the mali-supply property to ensure
proper power management and dynamic voltage scaling (DVFS).
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 9cabbbbab96f..0bd6b4260427 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -74,6 +74,11 @@ &cpu_l0 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ status = "okay";
+};
+
&i2c1 {
status = "okay";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/7] arm64: dts: rockchip: Add AP6275P wireless support for Khadas Edge 2L
From: Gray Huang @ 2026-04-29 6:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260429063712.2150938-1-gray.huang@wesion.com>
The Khadas Edge 2L uses an Ampak AP6275P (BCM43752) PCIe
Wi-Fi 6 module.
Enable combphy0 and pcie0, add the Wi-Fi regulator and reset
pinctrl, and describe the PCIe Wi-Fi function so it can consume
the 32.768kHz LPO clock provided by the HYM8563 RTC.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 64 ++++++++++++++++++-
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index c85b219fe409..9cabbbbab96f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -46,16 +46,34 @@ vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
regulator-max-microvolt = <2000000>;
vin-supply = <&vcc_sys>;
};
+
+ vcc_wifi_reg_on: regulator-wifi-reg-on {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&wifi_reg_on>;
+ pinctrl-names = "default";
+ regulator-name = "wifi_reg_on";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_1v8_s3>;
+ };
};
-&cpu_l0 {
- cpu-supply = <&vdd_cpu_lit_s0>;
+&combphy0_ps {
+ status = "okay";
};
&cpu_b0 {
cpu-supply = <&vdd_cpu_big_s0>;
};
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
&i2c1 {
status = "okay";
@@ -441,6 +459,48 @@ hym8563: hym8563@51 {
};
};
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_rst>;
+ reset-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
+ status = "okay";
+
+ pcie@0,0 {
+ reg = <0x0 0 0 0 0>;
+ bus-range = <0x0 0xf>;
+ device_type = "pci";
+ ranges;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ wifi: wifi@0,0 {
+ compatible = "pci14e4,449d";
+ reg = <0x10000 0 0 0 0>;
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ };
+ };
+};
+
+&pinctrl {
+ pcie0 {
+ pcie0_rst: pcie0-rst {
+ rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_reg_on: wifi-reg-on {
+ rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ wifi_wake_host: wifi-wake-host {
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+};
+
&sdhci {
bus-width = <8>;
no-sdio;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/7] arm64: dts: rockchip: Add HDMI and VOP support for Khadas Edge 2L
From: Gray Huang @ 2026-04-29 6:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260429063712.2150938-1-gray.huang@wesion.com>
Enable the Video Output Processor (VOP) and the HDMI TX controller
to support HDMI display output on the Khadas Edge 2L. Also, enable
the associated HDMI PHY.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 0bd6b4260427..c85285b3dc6e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -4,6 +4,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
#include "rk3576.dtsi"
/ {
@@ -18,6 +19,17 @@ chosen {
stdout-path = "serial0:1500000n8";
};
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
vcc_sys: regulator-vcc5v0-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
@@ -79,6 +91,30 @@ &gpu {
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_vp0: endpoint {
+ remote-endpoint = <&vp0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&hdptxphy {
+ status = "okay";
+};
+
&i2c1 {
status = "okay";
@@ -519,3 +555,18 @@ &sdhci {
&uart0 {
status = "okay";
};
+
+&vop {
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
+
+&vp0 {
+ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+ reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+ remote-endpoint = <&hdmi_in_vp0>;
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 7/7] arm64: dts: rockchip: Add Bluetooth support for Khadas Edge 2L
From: Gray Huang @ 2026-04-29 6:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260429063712.2150938-1-gray.huang@wesion.com>
Enable Bluetooth support for the Ampak AP6275P module on the
Khadas Edge 2L. This involves enabling the UART5 interface for
HCI communication and defining the required regulators and
power-sequence pins.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 84ac8ffdaa32..222cde0ea44c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -552,6 +552,20 @@ wifi: wifi@0,0 {
};
&pinctrl {
+ bluetooth {
+ bt_reg_on: bt-reg-on {
+ rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ bt_wake_host: bt-wake-host {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ host_wake_bt: host-wake-bt {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
pcie0 {
pcie0_rst: pcie0-rst {
rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
@@ -598,6 +612,27 @@ &uart0 {
status = "okay";
};
+&uart5 {
+ pinctrl-0 = <&uart5m1_xfer &uart5m1_ctsn &uart5m1_rtsn>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB1 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-0 = <&bt_reg_on &bt_wake_host &host_wake_bt>;
+ pinctrl-names = "default";
+ shutdown-gpios = <&gpio4 RK_PB2 GPIO_ACTIVE_HIGH>;
+ vbat-supply = <&vcc_3v3_s3>;
+ vddio-supply = <&vcc_1v8_s3>;
+ };
+};
+
&usb_drd1_dwc3 {
dr_mode = "host";
status = "okay";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/7] arm64: dts: rockchip: Enable USB for Khadas Edge 2L
From: Gray Huang @ 2026-04-29 6:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260429063712.2150938-1-gray.huang@wesion.com>
The Khadas Edge 2L board provides one USB 3.0 Host port and one
USB 2.0 port (connected via an internal hub). Enable the
corresponding DWC3 controllers and PHYs.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index c85285b3dc6e..84ac8ffdaa32 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -30,6 +30,29 @@ hdmi_con_in: endpoint {
};
};
+ vcc5v0_device: regulator-vcc5v0-device {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_device";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc5v0_host: regulator-vcc5v0-host {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_host";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ gpio = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&vcc5v0_device>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_host_pwren>;
+ };
+
vcc_sys: regulator-vcc5v0-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
@@ -78,6 +101,10 @@ &combphy0_ps {
status = "okay";
};
+&combphy1_psu {
+ status = "okay";
+};
+
&cpu_b0 {
cpu-supply = <&vdd_cpu_big_s0>;
};
@@ -531,6 +558,12 @@ pcie0_rst: pcie0-rst {
};
};
+ usb {
+ usb_host_pwren: usb-host-pwren {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
wifi {
wifi_reg_on: wifi-reg-on {
rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
@@ -552,10 +585,24 @@ &sdhci {
status = "okay";
};
+&u2phy1 {
+ status = "okay";
+};
+
+&u2phy1_otg {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
+&usb_drd1_dwc3 {
+ dr_mode = "host";
+ status = "okay";
+};
+
&vop {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3] remoteproc: xlnx: check remote core state
From: Michal Simek @ 2026-04-29 6:41 UTC (permalink / raw)
To: Tanmay Shah, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
In-Reply-To: <20260428221855.313752-1-tanmay.shah@amd.com>
On 4/29/26 00:18, Tanmay Shah wrote:
> The remote state is set to RPROC_DETACHED if the resource table is found
> in the memory. However, this can be wrong if the remote is not started,
> but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
> to the firmware to request the state of the RPU node. If the RPU is
> actually out of reset and running, only then move the remote state to
> RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
>
> Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support")
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
>
> Changes in v3:
> - add fixes tag
>
> Changes in v2:
> - fix subject line: %s/node/core/
> - add comment explaining optional resource table availability in the
>
> drivers/firmware/xilinx/zynqmp.c | 28 +++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 46 +++++++++++++++++++------
> include/linux/firmware/xlnx-zynqmp.h | 21 +++++++++++
> 3 files changed, 85 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index fbe8510f4927..af838b2dc327 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1450,6 +1450,34 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_get_node_status);
>
> +/**
> + * zynqmp_pm_get_rpu_node_status - PM call to request a RPU node's current power state
> + * @node: ID of the RPU component or sub-system in question
> + * @status: Current operating state of the requested RPU node.
> + * @requirements: Current requirements asserted on the RPU node.
> + * @usage: Usage information, used for RPU slave nodes only:
> + * PM_USAGE_NO_MASTER - No master is currently using
> + * the node
> + * PM_USAGE_CURRENT_MASTER - Only requesting master is
> + * currently using the node
> + * PM_USAGE_OTHER_MASTER - Only other masters are
> + * currently using the node
> + * PM_USAGE_BOTH_MASTERS - Both the current and at least
> + * one other master is currently
> + * using the node
> + *
> + * Return: Returns status, either success or error+reason
> + */
> +int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> + u32 *const requirements, u32 *const usage)
> +{
> + if (zynqmp_pm_feature(PM_GET_NODE_STATUS) < PM_API_VERSION_2)
> + return -EOPNOTSUPP;
> +
> + return zynqmp_pm_get_node_status(node, status, requirements, usage);
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_node_status);
> +
> /**
> * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
> * be powered down forcefully
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 50a9974f3202..45a62cb98072 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -948,16 +948,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> goto free_rproc;
> }
>
> - /*
> - * If firmware is already available in the memory then move rproc state
> - * to DETACHED. Firmware can be preloaded via debugger or by any other
> - * agent (processors) in the system.
> - * If firmware isn't available in the memory and resource table isn't
> - * found, then rproc state remains OFFLINE.
> - */
> - if (!zynqmp_r5_get_rsc_table_va(r5_core))
> - r5_rproc->state = RPROC_DETACHED;
> -
> r5_core->rproc = r5_rproc;
> return r5_core;
>
> @@ -1210,6 +1200,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> {
> struct device *dev = cluster->dev;
> struct zynqmp_r5_core *r5_core;
> + u32 req, usage, status;
> int ret = -EINVAL, i;
>
> r5_core = cluster->r5_cores[0];
> @@ -1255,6 +1246,41 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> ret = zynqmp_r5_get_sram_banks(r5_core);
> if (ret)
> return ret;
> +
> + /*
> + * It is possible that firmware is loaded into the memory, but
> + * RPU (remote) is not running. In such case, RPU state will be
> + * moved to RPROC_DETACHED wrongfully. To avoid it first make
> + * sure RPU is power-on and out of reset before parsing for the
> + * resource table.
> + */
> + ret = zynqmp_pm_get_rpu_node_status(r5_core->pm_domain_id,
> + &status, &req, &usage);
> + if (ret) {
> + dev_warn(r5_core->dev,
> + "failed to get rpu node status, err %d\n", ret);
> + continue;
> + }
> +
> + /*
> + * If RPU state is power on and out of reset i.e. running, then
> + * assign RPROC_DETACHED state. If the RPU is not out of reset
> + * then do not attempt to attach to the remote processor.
> + */
> + if (status == PM_NODE_RUNNING) {
> + /*
> + * Not all the firmware that is running on the remote
> + * core is expected to have the resource table. The
> + * firmware might not use RPMsg at all, and in that case
> + * resource table becomes irrelevant. However, we still
> + * need to make sure that running core is not reported
> + * as offline. so do not decide remote core state based
> + * on the resource table availability
> + */
> + if (zynqmp_r5_get_rsc_table_va(r5_core))
> + dev_dbg(r5_core->dev, "rsc tbl not found\n");
> + r5_core->rproc->state = RPROC_DETACHED;
> + }
> }
>
> return 0;
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index d70dcd462b44..7e27b0f7bf7e 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -542,6 +542,18 @@ enum pm_gem_config_type {
> GEM_CONFIG_FIXED = 2,
> };
>
> +/**
> + * enum pm_node_status - Device node status provided by xilpm fw
> + * @PM_NODE_UNUSED: Device is not used
> + * @PM_NODE_RUNNING: Device is power-on and out of reset
> + * @PM_NODE_HALT: Device is power-on but in the reset state
> + */
> +enum pm_node_status {
> + PM_NODE_UNUSED = 0,
> + PM_NODE_RUNNING = 1,
> + PM_NODE_HALT = 12,
> +};
> +
> /**
> * struct zynqmp_pm_query_data - PM query data
> * @qid: query ID
> @@ -630,6 +642,8 @@ int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode);
> int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode);
> int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> +int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> + u32 *const requirements, u32 *const usage);
> int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
> int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
> u32 value);
> @@ -939,6 +953,13 @@ static inline int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> return -ENODEV;
> }
>
> +static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> + u32 *const requirements,
> + u32 *const usage)
> +{
> + return -ENODEV;
> +}
> +
> static inline int zynqmp_pm_set_sd_config(u32 node,
> enum pm_sd_config_type config,
> u32 value)
>
> base-commit: fcdf2df56d34a3f04cab0725c5bc3abdaa73c2be
Acked-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox