* Re: [PATCH v2 0/3] Fix MMC pin pull configurations
From: Vignesh Raghavendra @ 2026-03-27 4:56 UTC (permalink / raw)
To: Nishanth Menon, Judith Mendez
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel, Moteen Shah, Andrew Davis
In-Reply-To: <20260223233731.2690472-1-jm@ti.com>
Hi Judith Mendez,
On Mon, 23 Feb 2026 17:37:28 -0600, Judith Mendez wrote:
> This series corrects MMC pin pull-up/pull-down configurations across
> TI AM62L EVM, AM62P SK, & AM62 LP SK boards to properly match their
> hardware design.
>
> Most boards have external pull-ups on MMC pins, but DT configuration
> was also enabling internal pulls. Having both internal and external
> pulls active causes several issues:
> - Unnecessary power consumption due to stronger pull resistance
> - Floating pins violating SPEC recommendations
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/3] arm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pins
commit: 6d4441be969bea89bb9702781f5dfb3a8f2a02a4
[2/3] arm64: dts: ti: k3-am62l-evm: Disable MMC1 internal pulls on data pins
commit: 02532ba56362907b6aca3e8289c4a9247ef83325
[3/3] arm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pins
commit: ee2a9d9c9e6c9643fb7e45febcaedfbc038e483a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant 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.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH v4 0/5] k3-am68-phyboard-izar dsi support
From: Vignesh Raghavendra @ 2026-03-27 4:53 UTC (permalink / raw)
To: Dominik Haller
Cc: Vignesh Raghavendra, linux-kernel, devicetree, linux-arm-kernel,
upstream
In-Reply-To: <20260320212349.420951-1-d.haller@phytec.de>
Hi Dominik Haller,
On Fri, 20 Mar 2026 14:23:41 -0700, Dominik Haller wrote:
> This series adds support for the two dsi based display interfaces of the
> phyboard-izar with the phycore-am68x/tda4x som.
>
> dsi0 gets converted to lvds on the som using a SN65DSI83 bridge in the
> default configuration. The phyboard-izar kit comes with a 10.1" lvds
> display with usb touch as addon.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/5] arm64: dts: ti: k3-am68-phyboard-izar: Assign dss clocks
commit: ae41091c65453b900a9a96294ee7ff007dc671e4
[2/5] arm64: dts: ti: k3-am68-phycore-som: Add DSI->LVDS bridge
commit: 2295927906ce448a25ec7fc6f5da731b364d6b90
[3/5] arm64: dts: ti: k3-am68-phyboard-izar: Add LVDS-Display
commit: 1bdfd6abc1ec5d60474a2f0b96955480b33e0644
[4/5] arm64: dts: ti: k3-j721s2-main: Add DSI1
commit: db0da07c37a2a79b19a07eef2f218dc830275e7d
[5/5] arm64: dts: ti: k3-am68-phyboard-izar: Add PEB-AV-15 overlay
commit: 6e5df7cc5455dfcfac4764f00d121ee6a6796e2c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant 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.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH v5 0/5] arm64: dts: ti: k3-am62: Support Main UART wakeup
From: Vignesh Raghavendra @ 2026-03-27 4:51 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kendall Willis
Cc: vishalm, sebin.francis, khilman, d-gole, msp, a-kaur,
s-kochidanadu, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260212-b4-uart-daisy-chain-dts-v5-0-26c7f534e567@ti.com>
Hi Kendall Willis,
On Thu, 12 Feb 2026 11:27:19 -0600, Kendall Willis wrote:
> arm64: dts: ti: k3-am62: Support Main UART wakeup
>
> This series adds wakeup support for the Main UART in the device tree of
> the TI AM62 family of devices. It defines the specific pins and pinctrl
> states needed to wakeup the system from the Main UART via I/O
> daisy-chaining. The wakeup-source property is configured to describe the
> low power modes the system can wakeup from using the Main UART.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/5] arm64: dts: ti: k3-am62x-sk-common: Enable Main UART wakeup
commit: ab16e17f6f4d216831a0736cf0f8d59b12b1d102
[2/5] arm64: dts: ti: k3-am62a7-sk: Enable Main UART wakeup
commit: 809c32b708c5e085c2c63fb05d2c6260c233a3ba
[3/5] arm64: dts: ti: k3-am62p5-sk: Enable Main UART wakeup
commit: 32ddcdde224a19a8c3cf9e0c9b7d6d9eced8db22
[4/5] arm64: dts: ti: k3-am62l3-evm: Enable Main UART wakeup
commit: abdec802da403a7ba0af5f87e8ab9671b71a00e4
[5/5] arm64: dts: ti: k3-am62d2-evm: Enable Main UART wakeup
commit: dbe21aa940f482fe3bba9d4731b6863ab85e8f55
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant 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.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: (subset) [PATCH v4 0/5] k3-am68-phyboard-izar dsi support
From: Vignesh Raghavendra @ 2026-03-27 4:48 UTC (permalink / raw)
To: Dominik Haller; +Cc: linux-kernel, devicetree, linux-arm-kernel, upstream
In-Reply-To: <20260320212349.420951-1-d.haller@phytec.de>
Hi Dominik Haller,
On Fri, 20 Mar 2026 14:23:41 -0700, Dominik Haller wrote:
> k3-am68-phyboard-izar dsi support
>
> This series adds support for the two dsi based display interfaces of the
> phyboard-izar with the phycore-am68x/tda4x som.
>
> dsi0 gets converted to lvds on the som using a SN65DSI83 bridge in the
> default configuration. The phyboard-izar kit comes with a 10.1" lvds
> display with usb touch as addon.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/5] arm64: dts: ti: k3-am68-phyboard-izar: Assign dss clocks
commit: cda1fef2ec679bfb74580273cb7dd7a1cecd77f7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant 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.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: ti: k3-j7200: Make MAIN domain system control bus a simple-bus
From: Vignesh Raghavendra @ 2026-03-27 4:48 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Davis
Cc: linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260303205224.108217-1-afd@ti.com>
Hi Andrew Davis,
On Tue, 03 Mar 2026 14:52:23 -0600, Andrew Davis wrote:
> arm64: dts: ti: k3-j7200: Make MAIN domain system control bus a simple-bus
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/2] arm64: dts: ti: k3-j7200: Make MAIN domain system control bus a simple-bus
commit: 830e0b0e15ee3d676539346b019f97f9bfae16b5
[2/2] arm64: dts: ti: k3-j721s2: Make MAIN domain system control bus a simple-bus
commit: af704cad18c0e973c758f41c9337411168de3681
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant 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.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-j722s: Add main_i2c4 device node
From: Vignesh Raghavendra @ 2026-03-27 4:43 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Aniket Limaye
Cc: linux-arm-kernel, devicetree, linux-kernel, u-kumar1,
Jared McArthur
In-Reply-To: <20260304-j722s-main-i2c4-dt-v1-1-03f79f0cdf97@ti.com>
Hi Aniket Limaye,
On Wed, 04 Mar 2026 14:41:05 +0530, Aniket Limaye wrote:
> arm64: dts: ti: k3-j722s: Add main_i2c4 device node
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/1] arm64: dts: ti: k3-j722s: Add main_i2c4 device node
commit: 7d793eea2dc171f90ef419a7a3755b2e21403d1e
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant 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.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-j721s2: Use ti,j7200-padconf compatible
From: Vignesh Raghavendra @ 2026-03-27 4:41 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Richard (TI)
Cc: Thomas Petazzoni, Gregory CLEMENT, richard.genoud, Udit Kumar,
Abhash Kumar, Prasanth Mantena, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260313-j721s2-s2r-pinctrl-v1-1-a6f80c641037@bootlin.com>
Hi Thomas Richard (TI),
On Fri, 13 Mar 2026 19:18:54 +0100, Thomas Richard (TI) wrote:
> arm64: dts: ti: k3-j721s2: Use ti,j7200-padconf compatible
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/1] arm64: dts: ti: k3-j721s2: Use ti,j7200-padconf compatible
commit: 5c86ef2055900ebe5e5a195a7d67b14ff665b60e
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant 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.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: ti: am62-verdin: Enable pullup for eMMC data pins
From: Vignesh Raghavendra @ 2026-03-27 4:40 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Francesco Dolcini
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel,
Judith Mendez, stable
In-Reply-To: <20260320073032.10427-1-francesco@dolcini.it>
Hi Francesco Dolcini,
On Fri, 20 Mar 2026 08:30:30 +0100, Francesco Dolcini wrote:
> arm64: dts: ti: am62-verdin: Enable pullup for eMMC data pins
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/1] arm64: dts: ti: am62-verdin: Enable pullup for eMMC data pins
commit: d5325810814ee995debfa0b6c4a22e0391598bef
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant 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.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-03-27 4:14 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Jeffery, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <14870d17-2471-4522-b8b5-03cb9002a4f7@app.fastmail.com>
Hi Arnd,
> - For the HW-mode-only peripherals (memory, LPC), is there any
> driver interaction at all for setting it up, or is this completely
> transparent to Linux running on the BMC?
For LPC-style IO accesses like Post Code Capture (PCC), the accesses are
completely transparent to Linux.
For memory accesses, they are also transparent to Linux on the BMC. It just
requires configuring the translation from the bus address to a reserved
memory region on the BMC during driver probe.
> - For the other devices running in SW mode, is the interface that the
> driver sees abstract in the sense that the same low-level code
> is shared for all of them, or are these still separate functional
> blocks that each need their own register-level interface?
The channels are distinct functional blocks within the eSPI controller, each
using its own channel-specific registers regardless of whether they operate
in HW or SW mode. There is no common message flow or registers for the
software modes. The eSPI controller dispatches eSPI messages to the relevant
channel's hardware function block, which then takes action according to its
mode configuration.
Some low-level framework code may be shareable, for example a unified ISR
entry that checks interrupt status register and routes to channel-specific
handlers, but the corresponding handling will be channel-specific.
Thanks,
Yun Hsuan
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X
From: Val Packett @ 2026-03-27 3:59 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <41476442-648a-46f9-a9e8-f5f4f7cf7bb5@oss.qualcomm.com>
On 3/26/26 7:47 AM, Konrad Dybcio wrote:
> On 3/25/26 11:34 PM, Bjorn Andersson wrote:
>> The Lenovo IdeaCentre Mini X (Snapdragon) Desktop is a Hamoa-based
>> ultracompact desktop PC. It provides HDMI, DisplayPort, USB Type-C
>> display outputs, 5 additional USB ports, Ethernet, dual NVME slots,
>> headphone jack, WiFi, and Bluetooth.
>>
>> Introduce a DeviceTree describing this device.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>> ---
> [...]
>
>> +&pcie3 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pcie3_default>;
>> +
>> + perst-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
>> + wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
> In lieu of the recent changes, these 2 properties need to be moved
> to the root port node under the RCs, for all of them
>
> Konrad
…and without forgetting (as I have for dell-thena until noticing in v4)
that under the port nodes, it's now called "reset" instead of "perst"! :)
~val
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: stmmac: remove unused and unimplemented AXI properties
From: patchwork-bot+netdevbpf @ 2026-03-27 3:50 UTC (permalink / raw)
To: Russell King
Cc: andrew, alexandre.torgue, andrew+netdev, conor+dt, davem,
devicetree, edumazet, peppe.cavallaro, kuba, joabreu, krzk+dt,
linux-arm-kernel, linux-stm32, netdev, pabeni, robh, me
In-Reply-To: <acJh4z3pRKkeaFbR@shell.armlinux.org.uk>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 10:05:23 +0000 you wrote:
> commit afea03656add ("stmmac: rework DMA bus setting and introduce new
> platform AXI structure") added support for parsing all the stmmac AXI
> attributes, and added code to set most of the appropriate register bits
> with three exceptions:
>
> snps,kbbe
> snps,mb
> snps,rb
>
> [...]
Here is the summary with links:
- [net-next,1/2] net: stmmac: remove axi_kbbe, axi_mb and axi_rb members
https://git.kernel.org/netdev/net-next/c/a800398e746f
- [net-next,2/2] dt-bindings: remove unimplemented AXI snps,kbbe snps,mb and snps,rb
https://git.kernel.org/netdev/net-next/c/af0331e1ac51
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] Add support for PIC64-HPSC/HX MDIO controller
From: Jakub Kicinski @ 2026-03-27 3:33 UTC (permalink / raw)
To: Charles Perry
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiner Kallweit,
Russell King, devicetree, linux-kernel
In-Reply-To: <20260323220254.3822444-1-charles.perry@microchip.com>
On Mon, 23 Mar 2026 15:02:52 -0700 Charles Perry wrote:
> .../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++
> drivers/net/mdio/Kconfig | 7 +
> drivers/net/mdio/Makefile | 1 +
> drivers/net/mdio/mdio-pic64hpsc.c | 192 ++++++++++++++++++
Speaking under correction from PHY maintainers but I think we need
a MAINTAINERS entry that will cover Microchip MDIO, or at least the
files you're adding. Important read:
https://docs.kernel.org/next/maintainer/feature-and-driver-maintainers.html
--
pw-bot: cr
^ permalink raw reply
* [PATCH 3/3] arm64: dts: qcom: kaanapali-mtp: Add SoCCP node
From: Jingyi Wang @ 2026-03-27 3:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel, Jingyi Wang,
20260310-knp-soccp-v4-0-0a91575e0e7e
In-Reply-To: <20260326-knp-soccp-dt-v1-0-a60c2ae36e9b@oss.qualcomm.com>
Add SoCCP node on Kaanapali MTP board.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index 07247dc98b70..a603f3056d83 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -1071,6 +1071,11 @@ &remoteproc_cdsp {
status = "okay";
};
+&remoteproc_soccp {
+ firmware-name = "qcom/kaanapali/soccp.mbn",
+ "qcom/kaanapali/soccp_dtb.mbn";
+};
+
&sdhc_2 {
cd-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>;
--
2.25.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: qcom: kaanapali-qrd: Add SoCCP node
From: Jingyi Wang @ 2026-03-27 3:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel, Jingyi Wang,
20260310-knp-soccp-v4-0-0a91575e0e7e
In-Reply-To: <20260326-knp-soccp-dt-v1-0-a60c2ae36e9b@oss.qualcomm.com>
Add SoCCP node on Kaanapali QRD board.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
index da0e8f9091c3..6a7eb7f4050a 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
@@ -781,6 +781,11 @@ &remoteproc_cdsp {
status = "okay";
};
+&remoteproc_soccp {
+ firmware-name = "qcom/kaanapali/soccp.mbn",
+ "qcom/kaanapali/soccp_dtb.mbn";
+};
+
&tlmm {
gpio-reserved-ranges = <36 4>, /* NFC eSE SPI */
<74 1>, /* eSE */
--
2.25.1
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: qcom: kaanapali: Add SoCCP
From: Jingyi Wang @ 2026-03-27 3:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel, Jingyi Wang,
20260310-knp-soccp-v4-0-0a91575e0e7e
Add device tree support for SoCCP on Kaanapali platform. The SoC Control
Processor (SoCCP) is small RISC-V MCU that controls USB Type-C, battery
charging and various other functions on Qualcomm SoCs. On Kaanapali,
SoCCP is brought up by bootloader, so the status is set "okay" in the
dtsi patch.
dependency: https://lore.kernel.org/all/20260310-knp-soccp-v4-0-0a91575e0e7e@oss.qualcomm.com/
This series is not ready for apply as the driver above is in discussion.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
Jingyi Wang (3):
arm64: dts: qcom: kaanapali: Add SoCCP for Kaanapali SoC
arm64: dts: qcom: kaanapali-qrd: Add SoCCP node
arm64: dts: qcom: kaanapali-mtp: Add SoCCP node
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 5 +++
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 5 +++
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 72 ++++++++++++++++++++++++++++++
3 files changed, 82 insertions(+)
---
base-commit: 66ba480978ce390e631e870b740a3406e3eb6b01
change-id: 20260326-knp-soccp-dt-81072d13b6b8
prerequisite-message-id: <20260310-knp-soccp-v4-0-0a91575e0e7e@oss.qualcomm.com>
prerequisite-patch-id: aaeb6c626609d672f3e61ef18b67961df38df48b
prerequisite-patch-id: 2a977d1876fdee9c930ac5f3ff7ff6f421b025e9
prerequisite-patch-id: d81fa4b09d7c2bcb22105fb24a79ab230081c859
prerequisite-patch-id: 0ec17b780f2efde54dabeb3588c6206d5c61fd64
prerequisite-patch-id: c9d6929e04a192ff2197ae531643fd02420c4443
prerequisite-patch-id: b138f14598e1cbc8e0c9a3058ed227283d6c6b26
prerequisite-patch-id: 8459bcae98ac156f6576657fe9233badcd385218
Best regards,
--
Jingyi Wang <jingyi.wang@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/3] arm64: dts: qcom: kaanapali: Add SoCCP for Kaanapali SoC
From: Jingyi Wang @ 2026-03-27 3:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel, Jingyi Wang,
20260310-knp-soccp-v4-0-0a91575e0e7e
In-Reply-To: <20260326-knp-soccp-dt-v1-0-a60c2ae36e9b@oss.qualcomm.com>
Add remoteproc PAS loader for SoCCP with its SMP2P. On Kaanapali, it
is brought up by bootloader, so set the status "okay".
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 72 +++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index ef6add4e5a90..ac6a6c789902 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -504,6 +504,32 @@ smp2p_cdsp_in: slave-kernel {
};
};
+ smp2p-soccp {
+ compatible = "qcom,smp2p";
+
+ interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
+ IPCC_MPROC_SIGNAL_SMP2P
+ IRQ_TYPE_EDGE_RISING>;
+
+ mboxes = <&ipcc IPCC_MPROC_SOCCP
+ IPCC_MPROC_SIGNAL_SMP2P>;
+
+ qcom,smem = <617>, <616>;
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <19>;
+
+ soccp_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ soccp_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
soc: soc@0 {
compatible = "simple-bus";
@@ -1513,6 +1539,52 @@ &clk_virt SLAVE_QUP_CORE_1 QCOM_ICC_TAG_ALWAYS>,
};
};
+ remoteproc_soccp: remoteproc-soccp@d00000 {
+ compatible = "qcom,kaanapali-soccp-pas";
+ reg = <0x0 0x00d00000 0x0 0x200000>;
+
+ interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack",
+ "pong";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ power-domains = <&rpmhpd RPMHPD_CX>,
+ <&rpmhpd RPMHPD_MX>;
+ power-domain-names = "cx",
+ "mx";
+
+ memory-region = <&soccp_mem>,
+ <&soccp_dtb_mem>;
+
+ qcom,smem-states = <&soccp_smp2p_out 0>,
+ <&soccp_smp2p_out 8>;
+ qcom,smem-state-names = "stop",
+ "ping";
+
+ status = "okay";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_MPROC_SOCCP
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+ qcom,remote-pid = <19>;
+ label = "soccp";
+ };
+ };
+
ipcc: mailbox@1106000 {
compatible = "qcom,kaanapali-ipcc", "qcom,ipcc";
reg = <0x0 0x01106000 0x0 0x1000>;
--
2.25.1
^ permalink raw reply related
* [PATCH v3] ASoC: dt-bindings: imx-card: Add dsp_a DAI format
From: Chancel Liu @ 2026-03-27 3:15 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li,
shengjiu.wang, s.hauer, kernel, festevam, linux-sound, devicetree,
imx, linux-arm-kernel, linux-kernel
Existing i.MX audio sound card described by this binding use codecs
that operate in i2s or dsp_b formats. The newly added CS42448 codec
requires dsp_a for its TDM interface. To properly describe such
hardware in DT, the binding needs to allow dsp_a DAI format.
Only i2s, dsp_b and dsp_a are included because these are the formats
actually used by the hardware supported by this binding. Other formats
such as left_j, right_j, ac97 are not used or required by the hardware
currently covered by this binding, so they are intentionally not added.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
Changes in v3:
- Rewrote commit message completely to describe hardware requirements.
Explicitly documented why only dsp_a is added and why other formats
are not included.
- Rebased on latest code base. No functional changes.
Changes in v2:
- Updated commit message to explain current support for i2s and dsp_b
formats and new support for dsp_a. No code changes.
Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
index 5424d4f16f52..75757fbccd89 100644
--- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
+++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
@@ -37,6 +37,7 @@ patternProperties:
items:
enum:
- i2s
+ - dsp_a
- dsp_b
dai-tdm-slot-num: true
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v2 0/7] J722S SGMII support
From: Jakub Kicinski @ 2026-03-27 3:11 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
On Tue, 24 Mar 2026 13:29:36 +0100 Nora Schiffer wrote:
> The J722S CPSW and SERDES are very similar to the variants found on the
> AM64, but they additionally support SGMII. Introduce new compatible
> strings for the J722S to add this support to the drivers.
>
> This is a prerequisite for the Single-Pair Ethernet interface of the
> TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
> submitted separately.
Please repost patch 3+6 as a separate series for net-next.
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-03-27 3:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <900dc1a4-66ab-411f-8a32-4c6cf339e8ec@kernel.org>
On 2026/3/26 下午3:49, Krzysztof Kozlowski wrote:
> On 26/03/2026 08:02, Krzysztof Kozlowski wrote:
>> On 26/03/2026 03:12, Hongliang Wang wrote:
>>> Hi Krzysztof,
>>>
>>> Consider the clock framework relies on the device tree, and can only be
>>> used on
>>> Loongson 2K platform with dts parameter mechanism, It cannot be used on
>>> Loongson
>> Don't top post or request read receipts.
OK
>>> 3A+7A platform with the acpi parameter mechanism.
>> And this patch is for ACPI? Then we finish discussion here, because
>> dt-bindings is not for ACPI.
>>
The initial idea was that this patch could be used for both ACPI and DTS.
>>> The i2c-ls2x driver is compatible with both Loongson 2K and 3A+7A
>>> platform, parse
>>> the same parameters regardless of dts or acpi parameter passing, So
>>> clock-input
>>> and clock-div attributes are defined to describe input clock of i2c
>>> controller and
>>> divisor of input clock. It can be used on both 2K and 3A+7A platform.
>> And you cannot use them in DTS.
OK
> I need to keep guessing what you want to achieve, because neither your
> message nor commit text was explicit
What I want to achieve is to describe the input clock and divisor of I2C
controller
through parameters passing, and the parameters can be used in both ACPI
and DTS.
because clock framework cannot be used for ACPI, So I defined two new
properties.
> - if you need properties for ACPI
> and you want to be sure that DTS does not have them, then you could
> define them as "foo:false" with a comment why (you always explain WHY
> you are doing things). We don't have such convention so far, but I think
> it will be useful when Rob finishes the ABI checker.
>
> *Otherwise* minimum would be a comment in the driver that these are not
> allowed in DTS.
>
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* RE: (subset) [PATCH v10 0/5] Add MIPI CSI-2 support for i.MX8ULP
From: G.N. Zhou (OSS) @ 2026-03-27 3:07 UTC (permalink / raw)
To: Frank Li, Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel,
G.N. Zhou (OSS)
Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Conor Dooley
In-Reply-To: <acVXhxohG8RS67_U@lizhi-Precision-Tower-5810>
Hi Frank,
> -----Original Message-----
> From: Frank Li <frank.li@nxp.com>
> Sent: Thursday, March 26, 2026 11:58 PM
> To: Rui Miguel Silva <rmfrfs@gmail.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Martin Kepplinger
> <martink@posteo.de>; Purism Kernel Team <kernel@puri.sm>; Mauro
> Carvalho Chehab <mchehab@kernel.org>; Rob Herring <robh@kernel.org>;
> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Philipp
> Zabel <p.zabel@pengutronix.de>; G.N. Zhou (OSS)
> <guoniu.zhou@oss.nxp.com>
> Cc: linux-media@vger.kernel.org; devicetree@vger.kernel.org;
> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Conor Dooley <conor.dooley@microchip.com>
> Subject: Re: (subset) [PATCH v10 0/5] Add MIPI CSI-2 support for i.MX8ULP
>
> On Thu, Mar 26, 2026 at 11:20:54AM -0400, Frank Li wrote:
> >
> > On Fri, 05 Dec 2025 17:07:42 +0800, Guoniu Zhou wrote:
> > > The serial adds MIPI CSI-2 support for i.MX8ULP.
> > >
> > >
> >
> > Applied, thanks!
> >
> > [5/5] arm64: dts: imx8ulp: Add CSI and ISI Nodes
> > commit: 73f3ca0f85285b2fc4ea05affb9a44bf899cd595
> >
> > Add extra empty line between reg and child node.
>
> Guoniu Zhou:
>
> I have to drop this one because miss <dt-bindings/reset/imx8ulp-pcc-reset.h>
>
> Do you miss some dependence?
Thanks for reporting this issue. You're right that this patch was based on a
tree that still contained include/dt-bindings/reset/imx8ulp-pcc-reset.h.
However, Rob's recent series [1] removed this header file as part of the
dt-bindings cleanup work. I'll send a new version that addresses this change.
[1] https://lore.kernel.org/all/20251212231203.727227-1-robh@kernel.org/
>
> Frank
> >
> > Best regards,
> > --
> > Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v2 3/3] remoteproc: imx_rproc: Add support for i.MX94
From: Peng Fan (OSS) @ 2026-03-27 2:42 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-0-a547a3588730@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add basic remoteproc support for the i.MX94 M-core processors, including
address translation tables(dev addr is from view of remote processor,
sys addr is from view of main processor) and device configuration data for
the CM70, CM71, and CM33S cores.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 71 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index d8ead42640881bd523d605fa7002935ef6e98077..525a92e03e8ab540697a3ef1f593b079f55e10ee 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -145,6 +145,47 @@ static const struct imx_rproc_att imx_rproc_att_imx95_m7[] = {
{ 0x80000000, 0x80000000, 0x50000000, 0 },
};
+static const struct imx_rproc_att imx_rproc_att_imx94_m70[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x00000000, 0x203C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS NON-SECURE*/
+ { 0x20000000, 0x20400000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m71[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x00000000, 0x202C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS NON-SECURE*/
+ { 0x20000000, 0x20300000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m33s[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x0FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM CODE SECURE */
+ { 0x1FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* TCM SYS NON-SECURE */
+ { 0x20000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS SECURE */
+ { 0x30000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* M33S OCRAM */
+ { 0x20800000, 0x20800000, 0x180000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
static const struct imx_rproc_att imx_rproc_att_imx93[] = {
/* dev addr , sys addr , size , flags */
/* TCM CODE NON-SECURE */
@@ -1466,6 +1507,33 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx93 = {
.flags = IMX_RPROC_NEED_CLKS,
};
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m70 = {
+ .att = imx_rproc_att_imx94_m70,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m70),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 1,
+ .lmid = 2,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m71 = {
+ .att = imx_rproc_att_imx94_m71,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m71),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 7,
+ .lmid = 3,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m33s = {
+ .att = imx_rproc_att_imx94_m33s,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m33s),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 8,
+ .lmid = 1,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
.att = imx_rproc_att_imx95_m7,
.att_size = ARRAY_SIZE(imx_rproc_att_imx95_m7),
@@ -1489,6 +1557,9 @@ static const struct of_device_id imx_rproc_of_match[] = {
{ .compatible = "fsl,imx8qm-cm4", .data = &imx_rproc_cfg_imx8qm },
{ .compatible = "fsl,imx8ulp-cm33", .data = &imx_rproc_cfg_imx8ulp },
{ .compatible = "fsl,imx93-cm33", .data = &imx_rproc_cfg_imx93 },
+ { .compatible = "fsl,imx94-cm70", .data = &imx_rproc_cfg_imx94_m70 },
+ { .compatible = "fsl,imx94-cm71", .data = &imx_rproc_cfg_imx94_m71 },
+ { .compatible = "fsl,imx94-cm33s", .data = &imx_rproc_cfg_imx94_m33s },
{ .compatible = "fsl,imx95-cm7", .data = &imx_rproc_cfg_imx95_m7 },
{},
};
--
2.37.1
^ permalink raw reply related
* [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Peng Fan (OSS) @ 2026-03-27 2:42 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-0-a547a3588730@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Cortex-M[7,33] processors use a fixed reset vector table format:
0x00 Initial SP value
0x04 Reset vector
0x08 NMI
0x0C ...
...
IRQ[n]
In ELF images, the corresponding layout is:
reset_vectors: --> hardware reset address
.word __stack_end__
.word Reset_Handler
.word NMI_Handler
.word HardFault_Handler
...
.word UART_IRQHandler
.word SPI_IRQHandler
...
Reset_Handler: --> ELF entry point address
...
The hardware fetches the first two words from reset_vectors and populates
SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
Reset_Handler.
However, the ELF entry point does not always match the hardware reset
address. For example, on i.MX94 CM33S:
ELF entry point: 0x0ffc211d
hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
To derive the correct hardware reset address, the unused lower bits must
be masked off. The boot code should apply a SoC-specific mask before
programming the reset address registers, e.g.:
reset_address = entry & reset_vector_mask
Current driver always programs the reset vector as 0. But i.MX94 CM33S's
default reset base is 0x0ffc0000, so the correct reset vector must be
passed to the SM API; otherwise the M33 Sync core cannot boot successfully.
rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
hardware reset vector address. To derive the proper reset vector, this
patch introduces imx_rproc_get_boot_addr(), which masks the ELF entry
point using the SoC‑specific 'reset_vector_mask'. The resulting reset
vector address is then passed to the SM CPU/LMM reset vector API calls.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 17 ++++++++++++++---
drivers/remoteproc/imx_rproc.h | 2 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 0dd80e688b0ea3df4c66e5726884dc86c8a5a881..d8ead42640881bd523d605fa7002935ef6e98077 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -345,7 +345,7 @@ static int imx_rproc_sm_cpu_start(struct rproc *rproc)
const struct imx_rproc_dcfg *dcfg = priv->dcfg;
int ret;
- ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, 0, true, false, false);
+ ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, rproc->bootaddr, true, false, false);
if (ret) {
dev_err(priv->dev, "Failed to set reset vector cpuid(%u): %d\n", dcfg->cpuid, ret);
return ret;
@@ -365,7 +365,7 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
* If the remoteproc core can't start the M7, it will already be
* handled in imx_rproc_sm_lmm_prepare().
*/
- ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, 0);
+ ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, rproc->bootaddr);
if (ret) {
dev_err(dev, "Failed to set reset vector lmid(%u), cpuid(%u): %d\n",
dcfg->lmid, dcfg->cpuid, ret);
@@ -739,6 +739,17 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
return rproc_elf_find_loaded_rsc_table(rproc, fw);
}
+static u64 imx_rproc_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
+{
+ struct imx_rproc *priv = rproc->priv;
+ u32 reset_vector_mask = GENMASK_U32(31, 0);
+
+ if (priv->dcfg->reset_vector_mask)
+ reset_vector_mask = priv->dcfg->reset_vector_mask;
+
+ return rproc_elf_get_boot_addr(rproc, fw) & reset_vector_mask;
+}
+
static const struct rproc_ops imx_rproc_ops = {
.prepare = imx_rproc_prepare,
.attach = imx_rproc_attach,
@@ -752,7 +763,7 @@ static const struct rproc_ops imx_rproc_ops = {
.find_loaded_rsc_table = imx_rproc_elf_find_loaded_rsc_table,
.get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
- .get_boot_addr = rproc_elf_get_boot_addr,
+ .get_boot_addr = imx_rproc_get_boot_addr,
};
static int imx_rproc_addr_init(struct imx_rproc *priv,
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index d37e6f90548cec727b4aeb874680b42af85bdbb4..0d7d48352a1091ad24e8e083172ce6da6d26ae10 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -41,6 +41,8 @@ struct imx_rproc_dcfg {
/* For System Manager(SM) based SoCs */
u32 cpuid; /* ID of the remote core */
u32 lmid; /* ID of the Logcial Machine */
+ /* reset_vector = elf_entry_addr & reset_vector_mask */
+ u32 reset_vector_mask;
};
#endif /* _IMX_RPROC_H */
--
2.37.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: remoteproc: imx-rproc: Support i.MX94
From: Peng Fan (OSS) @ 2026-03-27 2:42 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-0-a547a3588730@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add compatible string for:
Cortex-M7 core[0,1] in i.MX94
Cortex-M33 Sync core in i.MX94
To i.MX94, Cortex-M7 core0 and core1 have different memory view from
Cortex-A55 core, so different compatible string is used.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index ce8ec0119469c8fc0979a192b6e3d3a03108d7d2..c18f71b648890da9c25a2f3309d8dbec5bb8d226 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -28,6 +28,9 @@ properties:
- fsl,imx8qxp-cm4
- fsl,imx8ulp-cm33
- fsl,imx93-cm33
+ - fsl,imx94-cm33s
+ - fsl,imx94-cm70
+ - fsl,imx94-cm71
- fsl,imx95-cm7
clocks:
--
2.37.1
^ permalink raw reply related
* [PATCH v2 0/3] Add i.MX94 remoteproc support and reset vector handling improvements
From: Peng Fan (OSS) @ 2026-03-27 2:42 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
This series adds remoteproc support for the i.MX94 family, including the
CM70, CM71, and CM33S cores, and derive the hardware reset vector for
Cortex‑M processors whose ELF entry point does not directly correspond to
the actual reset address.
Background:
Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
table. While ELF images embed the entry point (e_entry), this value is
not always aligned to the hardware reset address. On platforms such as
i.MX94 CM33S, masking is required to compute the correct reset vector
address before programming the SoC reset registers.
Similarly, on i.MX95, the existing implementation always programs a reset
vector of 0x0, which only works when executing entirely from TCM. When
firmware is loaded into DDR, the driver must pass the correct reset vector
to the SM CPU/LMM interfaces.
Summary of patches:
[1]dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
Adds a new DT property allowing SoCs to specify a mask for deriving the
hardware reset vector from the ELF entry point.
[2]remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
Ensures the correct reset vector is passed to SM APIs by introducing a
driver‑level helper (imx_rproc_get_boot_addr()) that applies the
reset‑vector mask.
[3]remoteproc: imx_rproc: Add support for i.MX94 remoteproc
Adds address translation tables and configuration data for CM70, CM71,
and CM33S, enabling full remoteproc operation on i.MX94.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v2:
- Drop fsl,reset-vector-mask by using fixed value in driver for per device
- Add R-b for i.MX94 dt-binding
- Update commit log to include dev addr and sys addr
- Link to v1: https://lore.kernel.org/r/20260312-imx943-rproc-v1-0-3e66596592a8@nxp.com
---
Peng Fan (3):
dt-bindings: remoteproc: imx-rproc: Support i.MX94
remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
remoteproc: imx_rproc: Add support for i.MX94
.../bindings/remoteproc/fsl,imx-rproc.yaml | 3 +
drivers/remoteproc/imx_rproc.c | 88 +++++++++++++++++++++-
drivers/remoteproc/imx_rproc.h | 2 +
3 files changed, 90 insertions(+), 3 deletions(-)
---
base-commit: a2f31c83962f7f298b2975ab004810f3ac4875dc
change-id: 20260311-imx943-rproc-2050e00b65f7
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH 2/2] dts: riscv: spacemit: k3: Add i2c nodes
From: Yixun Lan @ 2026-03-27 2:39 UTC (permalink / raw)
To: Andi Shyti
Cc: Troy Mitchell, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
linux-i2c, devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <acWxqkR8Z0rwe4hI@zenone.zhora.eu>
Hi Andi,
On 23:23 Thu 26 Mar , Andi Shyti wrote:
> Hi Yixun,
>
> > > + i2c2: i2c@d4012000 {
> > > + compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
> > > + reg = <0x0 0xd4012000 0x0 0x38>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&syscon_apbc CLK_APBC_TWSI2>,
> > > + <&syscon_apbc CLK_APBC_TWSI2_BUS>;
> > > + clock-names = "func", "bus";
> > > + clock-frequency = <400000>;
> > > + resets = <&syscon_apbc RESET_APBC_TWSI2>;
> > > + status = "disabled";
> > > + };
> > I think we should add a comment here to explain why there isn't i2c3.
> > Otherwise, LGTM.
>
> are you going to add a comment here?
>
I will explain and re-spin a v2, and add a short comment for this:
- i2c3 is reserved for secure domain which not available from linux
- i2c7 simply does not exist from hardware perspective, K3 SoC want to
keep align with K1 to use same index of I2C controller for the pmic
> > Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>
--
Yixun Lan (dlan)
^ 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