Re: [PATCH DNM v3 8/8] arm64: dts: qcom: kaanapali: Add MPAM MSC nodes for the L2 caches
From: Yin Li
Date: Wed Oct 14 2026 - 03:12:08 EST
On 10/13/2026 6:37 PM, Ben Horgan wrote:
Hi Yin,
On 13/10/2026 11:13, Yin Li wrote:
On 10/12/2026 7:27 PM, Ben Horgan wrote:
Hi Yin,
On 12/10/2026 11:48, Yin Li wrote:
On 10/9/2026 5:00 AM, Rob Herring wrote:
On Thu, Oct 08, 2026 at 02:41:17PM +0800, Yin Li wrote:
Add an MPAM MSC device node for each L2 cache. Each MSC is nested
directly under its L2 cache node so that the cache node is the MSC's
parent device and its CPU affinity is derived from that cache.
The L2 cache nodes are placed directly under the root node. The root is
the root of the physical address space, so each cache node only needs an
identity 'ranges' property for its nested MSC's 'reg' to be resolved to
a physical address. The two caches use distinct node names (l2-cache-0
and l2-cache-1) since a cache node has no MMIO unit-address of its own.
The nodes are disabled by default. Production firmware does not expose
MSC register access to the OS, so these nodes can only be enabled on a
local test setup where firmware permits direct MMIO access to the MSCs.
This DTS is therefore only an example for other platform DT authors and
is not intended to be merged.
Co-developed-by: Huang Yiwei <huang.yiwei@xxxxxxxxxxxxxxxx>
Signed-off-by: Huang Yiwei <huang.yiwei@xxxxxxxxxxxxxxxx>
Signed-off-by: Yin Li <yin.li@xxxxxxxxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 50 +++++++++++++++++++++++++--------
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 131fd2a16c54..b1dcb1e9c570 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
[...]
+
+ msc@19870000 {
+ compatible = "arm,mpam-msc";
+ reg = <0x0 0x19870000 0x0 0x10000>;
The MPAM register length is 0x321C.
You are right, the MPAM register space is 0x321c per the specification.
Will update accordingly.
That is the full extent but truncation is allowed by the architecture.
Section B.9 9.2.3 Permitted truncation of an MPAM feature page IQGXFF it mentions
some conditions but these haven't been updated for the introduction of FEAT_MPAM_MSC_DOMAINS.
Does your implementation have domains?
Hi Ben,
Our implementation does not have domains. So 0x321c reflects the full feature page for MSC.
Truncation is allowed when domains aren't implemented. I was just trying to say that that part of
the spec (9.2.3) is out of date and needs to updated as it doesn't take into account the possibility
of domains.
It's only domain specific registers from 0x3000 unless you have some implementation defined
registers (9.1.5). Is that whole region just reserved for MPAM anyway?
Hi Ben, Konrad,
The original 0x10000 reflects the per-MSC register block size as
allocated in the KNP hardware — as Konrad noted, Qualcomm DTs tend to
use "how much register space is allocated for this block" rather than
"what the last used register ends" to avoid holes.
We'd like to update it to 0x321c to give other platform authors a more useful reference, without exposing KNP-internal details such as address holes between blocks. In our case, we don't implement MPAMCFG_MBW_PBM, and — as you noted — the registers from 0x3000 onward are domain-specific; since we have no domains, those aren't used either. So the actual footprint we need is smaller than 0x321c, but showing the full 0x321c gives other authors a complete picture of the allocated register space.
That said, this patch is marked DNM and is intended as a local
verification example only, not for merging.
Thanks,
Yin
Thanks,
Ben
Thanks,
Yin
Thanks,
Ben
Thanks,
Yin
Rob
--
Thx and BRs,
Yin