* Re: [PATCH 0/4] drm/exynos: Random cleanups
From: Chen-Yu Tsai @ 2026-03-27 5:44 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Alim Akhtar
Cc: David Airlie, Simona Vetter, dri-devel, linux-samsung-soc,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260326094308.1161335-1-wenst@chromium.org>
On Thu, Mar 26, 2026 at 5:43 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> Hi,
>
> Here are some cleanups for the exynos drm driver. This was done as part
> of the conversion of the driver to GEM DMA helpers. These patches have
> no dependency, unlike the actual conversion, so I am sending them
> separately for inclusion now.
>
> Please take a look.
I should add that these patches were only compile tested.
> Thanks
> ChenYu
>
> Chen-Yu Tsai (4):
> drm/exynos: Internalize exynos_drm_gem_free_object()
> drm/exynos: Use DRM core dedicated DMA device tracking facility
> drm/exynos: Drop exynos_drm_gem.size field
> drm/exynos: Drop MAX_FB_BUFFER in favor of DRM_FORMAT_MAX_PLANES
>
> drivers/gpu/drm/exynos/exynos_drm_dma.c | 11 +++---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 9 -----
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +--
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 13 ++++---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 50 +++++++++++--------------
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 8 ----
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +-
> 9 files changed, 41 insertions(+), 63 deletions(-)
>
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-j721e: Fix QSGMII overlay by adding SERDES PHY
From: Vignesh Raghavendra @ 2026-03-27 5:15 UTC (permalink / raw)
To: Chintan Vankar
Cc: Andrew Davis, Siddharth Vadapalli, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, Tero Kristo,
Vignesh Raghavendra, Nishanth Menon, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <20260326072237.1324027-1-c-vankar@ti.com>
On Thu, 26 Mar 2026 12:52:37 +0530, Chintan Vankar <c-vankar@ti.com> wrote:
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso b/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> index 8376fa4b6ee1..d403a3db0265 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> @@ -42,7 +42,8 @@ &cpsw0_port2 {
> phy-handle = <&cpsw9g_phy1>;
> phy-mode = "qsgmii";
> mac-address = [00 00 00 00 00 00];
> - phys = <&cpsw0_phy_gmii_sel 2>;
> + phys = <&cpsw0_phy_gmii_sel 2>, <&serdes0_qsgmii_link>;
> + phy-names = "mac", "serdes";
Dont you need this for all the other ports as well, just like in J784s4
overlay?
--
Vignesh
^ permalink raw reply
* 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 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
* [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: (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
* Re: [PATCH net-next] net: airoha: Grab flow_offload_mutex running airoha_register_gdm_devices()
From: Jakub Kicinski @ 2026-03-27 3:06 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org>
On Tue, 24 Mar 2026 17:54:45 +0100 Lorenzo Bianconi wrote:
> Netfilter flowtable can theoretically try offload flower rules as soon
> as a net-device is registered while not all the other ones are
> registered/initialized, triggering a possible NULL pointer dereferencing
> of qdma pointer in airoha_ppe_set_cpu_port routine. In order to avoid any
> possible race, grab the flow_offload_mutex running
> airoha_register_gdm_devices().
Sashiko says this causes a lock ordering issue:
https://sashiko.dev/#/patchset/20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org
^ permalink raw reply
* Re: [RFC PATCH v2 2/5] arm_mpam: resctrl: Pre-allocate assignable monitors
From: Shaopeng Tan (Fujitsu) @ 2026-03-27 3:00 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com,
fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com,
jonathan.cameron@huawei.com, kobak@nvidia.com,
lcherian@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peternewman@google.com,
punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com,
reinette.chatre@intel.com, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
xhao@linux.alibaba.com, zengheng4@huawei.com
In-Reply-To: <20260319165540.381410-3-ben.horgan@arm.com>
Hello Ben,
> MPAM is able to emulate ABMC, i.e. mbm_event mode, by making memory
> bandwidth monitors assignable. Rather than supporting the 'default'
> mbm_assign_mode always use 'mbm_event'mode even if there are sufficient
> memory bandwidth monitors. The per monitor event configuration is only
> provided by resctrl when in 'mbm_event' mode and so only allowing
> 'mbm_event' mode will make it easier to support per-monitor event
> configuration for MPAM. For the moment, the only event supported is
> mbm_total_event with no bandwidth type configuration. The 'mbm_assign_mode'
> file will still show 'default' when there is no support for memory
> bandwidth monitoring.
>
> The monitors need to be allocated from the driver, and mapped to whichever
> control/monitor group resctrl wants to use them with.
>
> Add a second array to hold the monitor values indexed by resctrl's cntr_id.
>
> When CDP is in use, two monitors are needed so the available number of
> counters halves. Platforms with one monitor will have zero monitors when
> CDP is in use.
>
> Co-developed-by: James Morse <james.morse@arm.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc v1:
> abmc enabled even if enough counters
> Helpers from dropped free running commits
> carry on with zero counters if using cdp
> set config bits
> use kmalloc_objs
> drop tags for rework
> Configure mbm_cntr_configurable, mbm_cntr_assign_fixed
> ---
> drivers/resctrl/mpam_internal.h | 6 +-
> drivers/resctrl/mpam_resctrl.c | 135 +++++++++++++++++++++++++++++++-
> 2 files changed, 137 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
> index dbb99d9b0795..02807531bd1b 100644
> --- a/drivers/resctrl/mpam_internal.h
> +++ b/drivers/resctrl/mpam_internal.h
> @@ -415,7 +415,11 @@ struct mpam_resctrl_res {
> struct mpam_resctrl_mon {
> struct mpam_class *class;
>
> - /* per-class data that resctrl needs will live here */
> + /* Array of allocated MBWU monitors, indexed by (closid, rmid). */
> + int *mbwu_idx_to_mon;
> +
> + /* Array of assigned MBWU monitors, indexed by idx argument. */
> + int *assigned_counters;
> };
>
> static inline int mpam_alloc_csu_mon(struct mpam_class *class)
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index c17577e52f58..74b6ca59ce4a 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -75,6 +75,8 @@ static DECLARE_WAIT_QUEUE_HEAD(wait_cacheinfo_ready);
> */
> static bool resctrl_enabled;
>
> +static unsigned int l3_num_allocated_mbwu = ~0;
> +
> bool resctrl_arch_alloc_capable(void)
> {
> struct mpam_resctrl_res *res;
> @@ -140,7 +142,7 @@ int resctrl_arch_cntr_read(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
>
> bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r)
> {
> - return false;
> + return (r == &mpam_resctrl_controls[RDT_RESOURCE_L3].resctrl_res);
> }
>
> int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable)
> @@ -185,6 +187,22 @@ static void resctrl_reset_task_closids(void)
> read_unlock(&tasklist_lock);
> }
>
> +static void mpam_resctrl_monitor_sync_abmc_vals(struct rdt_resource *l3)
> +{
> + l3->mon.num_mbm_cntrs = l3_num_allocated_mbwu;
> + if (cdp_enabled)
> + l3->mon.num_mbm_cntrs /= 2;
> +
> + /*
> + * Continue as normal even if there are zero counters to avoid giving
> + * resctrl mixed messages.
> + */
> + l3->mon.mbm_cntr_assignable = true;
> + l3->mon.mbm_assign_on_mkdir = true;
> + l3->mon.mbm_cntr_configurable = false;
> + l3->mon.mbm_cntr_assign_fixed = true;
> +}
> +
> int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
> {
> u32 partid_i = RESCTRL_RESERVED_CLOSID, partid_d = RESCTRL_RESERVED_CLOSID;
> @@ -236,6 +254,7 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
> WRITE_ONCE(arm64_mpam_global_default, mpam_get_regval(current));
>
> resctrl_reset_task_closids();
> + mpam_resctrl_monitor_sync_abmc_vals(l3);
Why is ABMC supported by default when CDP is enabled?
> for_each_possible_cpu(cpu)
> mpam_set_cpu_defaults(cpu, partid_d, partid_i, 0, 0);
> @@ -605,6 +624,9 @@ static bool class_has_usable_mbwu(struct mpam_class *class)
> if (!mpam_has_feature(mpam_feat_msmon_mbwu, cprops))
> return false;
>
> + if (!cprops->num_mbwu_mon)
> + return false;
> +
> return true;
> }
>
> @@ -933,6 +955,52 @@ static void mpam_resctrl_pick_mba(void)
> }
> }
>
> +static void __free_mbwu_mon(struct mpam_class *class, int *array,
> + u16 num_mbwu_mon)
> +{
> + for (int i = 0; i < num_mbwu_mon; i++) {
> + if (array[i] < 0)
> + continue;
> +
> + mpam_free_mbwu_mon(class, array[i]);
> + array[i] = ~0;
> + }
> +}
> +
> +static int __alloc_mbwu_mon(struct mpam_class *class, int *array,
> + u16 num_mbwu_mon)
> +{
> + for (int i = 0; i < num_mbwu_mon; i++) {
> + int mbwu_mon = mpam_alloc_mbwu_mon(class);
> +
> + if (mbwu_mon < 0) {
> + __free_mbwu_mon(class, array, num_mbwu_mon);
> + return mbwu_mon;
> + }
> + array[i] = mbwu_mon;
> + }
> +
> + l3_num_allocated_mbwu = min(l3_num_allocated_mbwu, num_mbwu_mon);
> +
> + return 0;
> +}
> +
> +static int *__alloc_mbwu_array(struct mpam_class *class, u16 num_mbwu_mon)
> +{
> + int err;
> + int *array __free(kfree) = kmalloc_objs(*array, num_mbwu_mon);
> +
> + if (!array)
> + return ERR_PTR(-ENOMEM);
> +
> + memset(array, -1, num_mbwu_mon * sizeof(*array));
> +
> + err = __alloc_mbwu_mon(class, array, num_mbwu_mon);
> + if (err)
> + return ERR_PTR(err);
> + return_ptr(array);
> +}
> +
> static void counter_update_class(enum resctrl_event_id evt_id,
> struct mpam_class *class)
> {
> @@ -1087,9 +1155,46 @@ static int mpam_resctrl_pick_domain_id(int cpu, struct mpam_component *comp)
> return comp->comp_id;
> }
>
> +/*
> + * This must run after all event counters have been picked so that any free
> + * running counters have already been allocated.
> + */
> +static int mpam_resctrl_monitor_init_abmc(struct mpam_resctrl_mon *mon)
> +{
> + struct mpam_resctrl_res *res = &mpam_resctrl_controls[RDT_RESOURCE_L3];
> + struct rdt_resource *l3 = &res->resctrl_res;
> + struct mpam_class *class = mon->class;
> + u16 num_mbwu_mon;
> + size_t num_rmid = resctrl_arch_system_num_rmid_idx();
> +
> + if (mon->mbwu_idx_to_mon) {
> + pr_debug("monitors free running\n");
> + return 0;
> + }
ABMC is not supported under this condition.
Why does this condition conclude that there are enough monitors(monitors freee running)?
Best regards,
Shaopeng TAN
> + int *rmid_array __free(kfree) = kmalloc_objs(*rmid_array, num_rmid);
> +
> + if (!rmid_array) {
> + pr_debug("Failed to allocate RMID array\n");
> + return -ENOMEM;
> + }
> + memset(rmid_array, -1, num_rmid * sizeof(*rmid_array));
> +
> + num_mbwu_mon = class->props.num_mbwu_mon;
> + mon->assigned_counters = __alloc_mbwu_array(mon->class, num_mbwu_mon);
> + if (IS_ERR(mon->assigned_counters))
> + return PTR_ERR(mon->assigned_counters);
> + mon->mbwu_idx_to_mon = no_free_ptr(rmid_array);
> +
> + mpam_resctrl_monitor_sync_abmc_vals(l3);
> +
> + return 0;
> +}
> +
> static int mpam_resctrl_monitor_init(struct mpam_resctrl_mon *mon,
> enum resctrl_event_id type)
> {
> + int err = 0;
> struct mpam_resctrl_res *res = &mpam_resctrl_controls[RDT_RESOURCE_L3];
> struct rdt_resource *l3 = &res->resctrl_res;
>
> @@ -1131,8 +1236,19 @@ static int mpam_resctrl_monitor_init(struct mpam_resctrl_mon *mon,
> */
> l3->mon.num_rmid = resctrl_arch_system_num_rmid_idx();
>
> - if (resctrl_enable_mon_event(type, false, 0, NULL))
> - l3->mon_capable = true;
> + if (type == QOS_L3_MBM_TOTAL_EVENT_ID) {
> + err = mpam_resctrl_monitor_init_abmc(mon);
> + if (err)
> + return err;
> +
> + static_assert(MAX_EVT_CONFIG_BITS == 0x7f);
> + l3->mon.mbm_cfg_mask = MAX_EVT_CONFIG_BITS;
> + }
> +
> + if (!resctrl_enable_mon_event(type, false, 0, NULL))
> + return -EINVAL;
> +
> + l3->mon_capable = true;
>
> return 0;
> }
> @@ -1695,6 +1811,17 @@ void mpam_resctrl_exit(void)
> resctrl_exit();
> }
>
> +static void mpam_resctrl_teardown_mon(struct mpam_resctrl_mon *mon, struct mpam_class *class)
> +{
> + u32 num_mbwu_mon = resctrl_arch_system_num_rmid_idx();
> +
> + if (!mon->mbwu_idx_to_mon)
> + return;
> +
> + __free_mbwu_mon(class, mon->mbwu_idx_to_mon, num_mbwu_mon);
> + mon->mbwu_idx_to_mon = NULL;
> +}
> +
> /*
> * The driver is detaching an MSC from this class, if resctrl was using it,
> * pull on resctrl_exit().
> @@ -1717,6 +1844,8 @@ void mpam_resctrl_teardown_class(struct mpam_class *class)
> for_each_mpam_resctrl_mon(mon, eventid) {
> if (mon->class == class) {
> mon->class = NULL;
> +
> + mpam_resctrl_teardown_mon(mon, class);
> break;
> }
> }
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH 05/10] am68k/PCI: Remove unnecessary second application of align
From: Greg Ungerer @ 2026-03-27 2:55 UTC (permalink / raw)
To: Ilpo Järvinen, linux-pci, Bjorn Helgaas, Guenter Roeck,
linux-alpha, linux-arm-kernel, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel
In-Reply-To: <20260324165633.4583-6-ilpo.jarvinen@linux.intel.com>
On 25/3/26 02:56, Ilpo Järvinen wrote:
> Aligning res->start by align inside pcibios_align_resource() is
> unnecessary because caller of pcibios_align_resource() is
> __find_resource_space() that aligns res->start with align before
> calling pcibios_align_resource().
>
> Aligning by align in case of IORESOURCE_IO && start & 0x300 cannot ever
> result in changing start either because 0x300 bits would have not
> survived the earlier alignment if align was large enough to have an
> impact.
>
> Thus, remove the duplicated aligning from pcibios_align_resource().
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
LGTM.
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
> ---
> arch/m68k/kernel/pcibios.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/m68k/kernel/pcibios.c b/arch/m68k/kernel/pcibios.c
> index 1415f6e4e5ce..7e286ee1976b 100644
> --- a/arch/m68k/kernel/pcibios.c
> +++ b/arch/m68k/kernel/pcibios.c
> @@ -36,8 +36,6 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> if ((res->flags & IORESOURCE_IO) && (start & 0x300))
> start = (start + 0x3ff) & ~0x3ff;
>
> - start = (start + align - 1) & ~(align - 1);
> -
> return start;
> }
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] arm_mpam: resctrl: Pick classes for use as mbm counters
From: Shaopeng Tan (Fujitsu) @ 2026-03-27 2:53 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com,
fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com,
jonathan.cameron@huawei.com, kobak@nvidia.com,
lcherian@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peternewman@google.com,
punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com,
reinette.chatre@intel.com, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
xhao@linux.alibaba.com, zengheng4@huawei.com
In-Reply-To: <20260319165540.381410-2-ben.horgan@arm.com>
Hello Ben,
> resctrl has two types of counters, NUMA-local and global. MPAM can only
> count global either using MSC at the L3 cache or in the memory controllers.
> When global and local equate to the same thing continue just to call it
> global.
>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc v1:
> Move finding any_mon_comp into monitor boilerplate patch
> Move mpam_resctrl_get_domain_from_cpu() into monitor boilerplate
> Remove free running check
> Trim commit message
> ---
> drivers/resctrl/mpam_resctrl.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index a7691c66553a..c17577e52f58 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -598,6 +598,16 @@ static bool cache_has_usable_csu(struct mpam_class *class)
> return true;
> }
>
> +static bool class_has_usable_mbwu(struct mpam_class *class)
> +{
> + struct mpam_props *cprops = &class->props;
> +
> + if (!mpam_has_feature(mpam_feat_msmon_mbwu, cprops))
> + return false;
> +
> + return true;
> +}
> +
> /*
> * Calculate the worst-case percentage change from each implemented step
> * in the control.
> @@ -981,6 +991,22 @@ static void mpam_resctrl_pick_counters(void)
> break;
> }
> }
> +
> + if (class_has_usable_mbwu(class) &&
> + topology_matches_l3(class) &&
> + traffic_matches_l3(class)) {
> + pr_debug("class %u has usable MBWU, and matches L3 topology and traffic\n",
> + class->level);
> +
> + /*
> + * We can't distinguish traffic by destination so
> + * we don't know if it's staying on the same NUMA
> + * node. Hence, we can't calculate mbm_local except
> + * when we only have one L3 and it's equivalent to
> + * mbm_total and so always use mbm_total.
> + */
> + counter_update_class(QOS_L3_MBM_TOTAL_EVENT_ID, class);
> + }
> }
> }
>
> --
> 2.43.0
>
>
There are environments with multiple L3 caches within a single NUMA node.
In this case, mbm_total will be the sum of traffic from all caches within that NUAM node.
Is my understanding correct?
Best regards,
Shaopeng TAN
^ 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 v12 2/7] qcom-tgu: Add TGU driver
From: Jie Gan @ 2026-03-27 2:35 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260317032639.2393221-3-songwei.chai@oss.qualcomm.com>
On 3/17/2026 11:26 AM, Songwei Chai wrote:
> Add driver to support device TGU (Trigger Generation Unit).
> TGU is a Data Engine which can be utilized to sense a plurality of
> signals and create a trigger into the CTI or generate interrupts to
> processors. Add probe/enable/disable functions for tgu.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
> drivers/Makefile | 1 +
> drivers/hwtracing/Kconfig | 2 +
> drivers/hwtracing/qcom/Kconfig | 18 ++
> drivers/hwtracing/qcom/Makefile | 3 +
> drivers/hwtracing/qcom/tgu.c | 183 ++++++++++++++++++
> drivers/hwtracing/qcom/tgu.h | 51 +++++
> 7 files changed, 267 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> create mode 100644 drivers/hwtracing/qcom/Kconfig
> create mode 100644 drivers/hwtracing/qcom/Makefile
> create mode 100644 drivers/hwtracing/qcom/tgu.c
> create mode 100644 drivers/hwtracing/qcom/tgu.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> new file mode 100644
> index 000000000000..ead237bb7d89
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -0,0 +1,9 @@
> +What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
> +Date: March 2026
> +KernelVersion 7.1
missed ":" in all patches.
Thanks,
Jie
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (RW) Set/Get the enable/disable status of TGU
> + Accepts only one of the 2 values - 0 or 1.
> + 0 : disable TGU.
> + 1 : enable TGU.
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 53fbd2e0acdd..82b712a12a26 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
> obj-$(CONFIG_USB4) += thunderbolt/
> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
> obj-y += hwtracing/intel_th/
> +obj-y += hwtracing/qcom/
> obj-$(CONFIG_STM) += hwtracing/stm/
> obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
> obj-y += android/
> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
> index 911ee977103c..8a640218eed8 100644
> --- a/drivers/hwtracing/Kconfig
> +++ b/drivers/hwtracing/Kconfig
> @@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>
> source "drivers/hwtracing/ptt/Kconfig"
>
> +source "drivers/hwtracing/qcom/Kconfig"
> +
> endmenu
> diff --git a/drivers/hwtracing/qcom/Kconfig b/drivers/hwtracing/qcom/Kconfig
> new file mode 100644
> index 000000000000..d6f6d4b0f28e
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# QCOM specific hwtracing drivers
> +#
> +menu "Qualcomm specific hwtracing drivers"
> +
> +config QCOM_TGU
> + tristate "QCOM Trigger Generation Unit driver"
> + help
> + This driver provides support for Trigger Generation Unit that is
> + used to detect patterns or sequences on a given set of signals.
> + TGU is used to monitor a particular bus within a given region to
> + detect illegal transaction sequences or slave responses. It is also
> + used to monitor a data stream to detect protocol violations and to
> + provide a trigger point for centering data around a specific event
> + within the trace data buffer.
> +
> +endmenu
> diff --git a/drivers/hwtracing/qcom/Makefile b/drivers/hwtracing/qcom/Makefile
> new file mode 100644
> index 000000000000..5a0a868c1ea0
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_QCOM_TGU) += tgu.o
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> new file mode 100644
> index 000000000000..58c19f12f3d7
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -0,0 +1,183 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/amba/bus.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_runtime.h>
> +
> +#include "tgu.h"
> +
> +static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + /* Enable TGU to program the triggers */
> + writel(1, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +}
> +
> +static int tgu_enable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (drvdata->enabled)
> + return -EBUSY;
> +
> + tgu_write_all_hw_regs(drvdata);
> + drvdata->enabled = true;
> +
> + return 0;
> +}
> +
> +static void tgu_do_disable(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + writel(0, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +
> + drvdata->enabled = false;
> +}
> +
> +static void tgu_disable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (!drvdata->enabled)
> + return;
> +
> + tgu_do_disable(drvdata);
> +}
> +
> +static ssize_t enable_tgu_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + bool enabled;
> +
> + guard(spinlock)(&drvdata->lock);
> + enabled = drvdata->enabled;
> +
> + return sysfs_emit(buf, "%d\n", !!enabled);
> +}
> +
> +/* enable_tgu_store - Configure Trace and Gating Unit (TGU) triggers. */
> +static ssize_t enable_tgu_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + unsigned long val;
> + int ret;
> +
> + ret = kstrtoul(buf, 0, &val);
> + if (ret || val > 1)
> + return -EINVAL;
> +
> + if (val) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
> + ret = tgu_enable(dev);
> + if (ret) {
> + pm_runtime_put(dev);
> + return ret;
> + }
> + } else {
> + tgu_disable(dev);
> + pm_runtime_put(dev);
> + }
> +
> + return size;
> +}
> +static DEVICE_ATTR_RW(enable_tgu);
> +
> +static struct attribute *tgu_common_attrs[] = {
> + &dev_attr_enable_tgu.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group tgu_common_grp = {
> + .attrs = tgu_common_attrs,
> + NULL,
> +};
> +
> +static const struct attribute_group *tgu_attr_groups[] = {
> + &tgu_common_grp,
> + NULL,
> +};
> +
> +static int tgu_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> + struct device *dev = &adev->dev;
> + struct tgu_drvdata *drvdata;
> + int ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + drvdata->dev = &adev->dev;
> + dev_set_drvdata(dev, drvdata);
> +
> + drvdata->base = devm_ioremap_resource(dev, &adev->res);
> + if (IS_ERR(drvdata->base))
> + return PTR_ERR(drvdata->base);
> +
> + spin_lock_init(&drvdata->lock);
> +
> + ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
> + if (ret) {
> + dev_err(dev, "failed to create sysfs groups: %d\n", ret);
> + return ret;
> + }
> +
> + drvdata->enabled = false;
> +
> + pm_runtime_put(&adev->dev);
> +
> + return 0;
> +}
> +
> +static void tgu_remove(struct amba_device *adev)
> +{
> + struct device *dev = &adev->dev;
> +
> + sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
> +
> + tgu_disable(dev);
> +}
> +
> +static const struct amba_id tgu_ids[] = {
> + {
> + .id = 0x000f0e00,
> + .mask = 0x000fffff,
> + },
> + { 0, 0, NULL },
> +};
> +
> +MODULE_DEVICE_TABLE(amba, tgu_ids);
> +
> +static struct amba_driver tgu_driver = {
> + .drv = {
> + .name = "qcom-tgu",
> + .suppress_bind_attrs = true,
> + },
> + .probe = tgu_probe,
> + .remove = tgu_remove,
> + .id_table = tgu_ids,
> +};
> +
> +module_amba_driver(tgu_driver);
> +
> +MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
> +MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
> +MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
> new file mode 100644
> index 000000000000..dd7533b9d735
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _QCOM_TGU_H
> +#define _QCOM_TGU_H
> +
> +/* Register addresses */
> +#define TGU_CONTROL 0x0000
> +#define TGU_LAR 0xfb0
> +#define TGU_UNLOCK_OFFSET 0xc5acce55
> +
> +static inline void TGU_LOCK(void __iomem *addr)
> +{
> + do {
> + /* Wait for things to settle */
> + mb();
> + writel_relaxed(0x0, addr + TGU_LAR);
> + } while (0);
> +}
> +
> +static inline void TGU_UNLOCK(void __iomem *addr)
> +{
> + do {
> + writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
> + /* Make sure everyone has seen this */
> + mb();
> + } while (0);
> +}
> +
> +/**
> + * struct tgu_drvdata - Data structure for a TGU (Trigger Generator Unit)
> + * @base: Memory-mapped base address of the TGU device
> + * @dev: Pointer to the associated device structure
> + * @lock: Spinlock for handling concurrent access to private data
> + * @enabled: Flag indicating whether the TGU device is enabled
> + *
> + * This structure defines the data associated with a TGU device,
> + * including its base address, device pointers, clock, spinlock for
> + * synchronization, trigger data pointers, maximum limits for various
> + * trigger-related parameters, and enable status.
> + */
> +struct tgu_drvdata {
> + void __iomem *base;
> + struct device *dev;
> + spinlock_t lock;
> + bool enabled;
> +};
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v12 7/7] qcom-tgu: Add reset node to initialize
From: Jie Gan @ 2026-03-27 2:26 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260317032639.2393221-8-songwei.chai@oss.qualcomm.com>
On 3/17/2026 11:26 AM, Songwei Chai wrote:
> Add reset node to initialize the value of
> priority/condition_decode/condition_select/timer/counter nodes.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 7 ++
> drivers/hwtracing/qcom/tgu.c | 77 +++++++++++++++++++
> 2 files changed, 84 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> index 5370882333bc..1dcb8fb71cd9 100644
> --- a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -42,3 +42,10 @@ KernelVersion 7.1
> Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> Description:
> (RW) Set/Get the counter value with specific step for TGU.
> +
> +What: /sys/bus/amba/devices/<tgu-name>/reset_tgu
> +Date: March 2026
> +KernelVersion 7.1
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (Write) Write 1 to reset the dataset for TGU.
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> index 4539415571f6..e28e6d27cf56 100644
> --- a/drivers/hwtracing/qcom/tgu.c
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -410,8 +410,85 @@ static ssize_t enable_tgu_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(enable_tgu);
>
> +/* reset_tgu_store - Reset Trace and Gating Unit (TGU) configuration. */
> +static ssize_t reset_tgu_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t size)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + struct value_table *vt = drvdata->value_table;
> + u32 *cond_decode = drvdata->value_table->condition_decode;
> + bool need_pm_put = false;
> + unsigned long value;
> + int i, j, ret;
> +
> + if (kstrtoul(buf, 0, &value) || value != 1)
> + return -EINVAL;
> +
> + spin_lock(&drvdata->lock);
> + if (!drvdata->enabled) {
> + spin_unlock(&drvdata->lock);
> + ret = pm_runtime_resume_and_get(drvdata->dev);
> + if (ret)
> + return ret;
> + need_pm_put = true;
> + spin_lock(&drvdata->lock);
> + }
> +
> + tgu_do_disable(drvdata);
need_pm_put flag is not set when reset a enabled device. I think we also
need do pm_runtime_put after we did tgu_do_disable for an enabled device
because we have pm_runtime_resume_and_get while enabling it.
Thanks,
Jie
> +
> + if (vt->priority) {
> + size_t size = MAX_PRIORITY * drvdata->num_step *
> + drvdata->num_reg * sizeof(unsigned int);
> + memset(vt->priority, 0, size);
> + }
> +
> + if (vt->condition_decode) {
> + size_t size = drvdata->num_condition_decode *
> + drvdata->num_step * sizeof(unsigned int);
> + memset(vt->condition_decode, 0, size);
> + }
> +
> + /* Initialize all condition registers to NOT(value=0x1000000) */
> + for (i = 0; i < drvdata->num_step; i++) {
> + for (j = 0; j < drvdata->num_condition_decode; j++) {
> + cond_decode[calculate_array_location(drvdata, i,
> + TGU_CONDITION_DECODE, j)] = 0x1000000;
> + }
> + }
> +
> + if (vt->condition_select) {
> + size_t size = drvdata->num_condition_select *
> + drvdata->num_step * sizeof(unsigned int);
> + memset(vt->condition_select, 0, size);
> + }
> +
> + if (vt->timer) {
> + size_t size = (drvdata->num_step) * (drvdata->num_timer) *
> + sizeof(unsigned int);
> + memset(vt->timer, 0, size);
> + }
> +
> + if (vt->counter) {
> + size_t size = (drvdata->num_step) * (drvdata->num_counter) *
> + sizeof(unsigned int);
> + memset(vt->counter, 0, size);
> + }
> +
> + spin_unlock(&drvdata->lock);
> +
> + dev_dbg(dev, "Qualcomm-TGU reset complete\n");
> +
> + if (need_pm_put)
> + pm_runtime_put(drvdata->dev);
> +
> + return size;
> +}
> +static DEVICE_ATTR_WO(reset_tgu);
> +
> static struct attribute *tgu_common_attrs[] = {
> &dev_attr_enable_tgu.attr,
> + &dev_attr_reset_tgu.attr,
> NULL,
> };
>
^ 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