All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Ping Li <leeonion.muyu@gmail.com>
Cc: yin.li@oss.qualcomm.com, james.morse@arm.com, ben.horgan@arm.com,
	sdonthineni@nvidia.com, andre.przywara@arm.com,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/6] arm-mpam: Add basic device tree support for resctrl
Date: Fri, 6 Nov 2026 09:08:22 -0600	[thread overview]
Message-ID: <20261106150822.GA3193214-robh@kernel.org> (raw)
In-Reply-To: <20261105055347.947416-1-leeonion.muyu@gmail.com>

On Thu, Nov 05, 2026 at 01:53:47PM +0800, Ping Li wrote:
> Hi Yin,
> 
> Sure. Our memory controller MSC is described as a top-level node.
> The MPAM register window is mapped independently in the SoC (the
> component sits on the DDR egress path rather than being a sub-block
> of a memory-controller DT node), so the node is a direct child of
> the root:
> 
> 	ddr_msc: msc@2238000 {
> 		compatible = "<vendor>,<soc>-ddr-qos",
> 			     "arm,mpam-memory-controller-msc",
> 			     "arm,mpam-msc";
> 		reg = <0x0 0x02238000 0x0 0x1000>;
> 		arm,not-ready-us = <10>;
> 	};
> 
> The first compatible in the list is for our platform glue; I have
> replaced it with a placeholder here since it is not relevant to the
> binding discussion.
> 
> Notes on the properties, in case they matter for the binding:
> 
> - reg: the MPAM register window. Only a subset of the architectural
>   register space is implemented, so the size is the truncated window.
> - single RIS: the component reports HAS_RIS=0, so there are no
>   ris@N child nodes.
> - no interrupts: the component has no MPAM ESR block, so there is
>   no interrupts property.
> - arm,not-ready-us: 10.
> 
> The verified probe path: the node matches via "arm,mpam-msc", and
> patch 6/8 in v3 classifies it as MPAM_CLASS_MEMORY and treats it as
> accessible from all CPUs, which is exactly the behavior we need.
> 
> One question in return: with the node being a direct child of the
> root rather than a child of a memory-controller node, is that a
> form the binding should cover? If the binding expects the MSC to
> always be a sub-node of a memory controller, we would need the
> top-level form to be allowed as well.

This would be why we're not upstreaming the binding without users. We 
need actual h/w to validate the binding works.

Rob

  reply	other threads:[~2026-11-06 15:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 11:45 [PATCH v4 0/6] arm-mpam: Add basic device tree support for resctrl Yin Li
2026-10-28 11:45 ` [PATCH v4 1/6] arm_mpam: Fix the RIS index range check in mpam_ris_create_locked Yin Li
2026-10-30 17:15   ` Srivathsa L Rao
2026-10-28 11:45 ` [PATCH v4 2/6] arm_mpam: Fix MSC MMIO window size off-by-one with resource_size() Yin Li
2026-10-29  8:12   ` Jinjie Ruan
2026-10-29  8:13   ` Jinjie Ruan
2026-10-29 12:02   ` Ilpo Järvinen
2026-10-30 17:18   ` Srivathsa L Rao
2026-10-28 11:45 ` [PATCH v4 3/6] dt-bindings: arm: Add MPAM MSC binding Yin Li
2026-10-28 11:56   ` sashiko-bot
2026-10-28 11:45 ` [PATCH v4 4/6] cacheinfo: Expose the code to generate a cache-id from a device_node Yin Li
2026-10-28 11:45 ` [PATCH v4 5/6] arm_mpam: Add device tree support for MSC probing Yin Li
2026-10-28 12:04   ` sashiko-bot
2026-10-28 11:45 ` [PATCH DNM v4 6/6] arm64: dts: qcom: kaanapali: Add MPAM MSC nodes for the L2 caches Yin Li
2026-10-28 12:05   ` sashiko-bot
2026-11-04  8:13 ` [PATCH v4 0/6] arm-mpam: Add basic device tree support for resctrl Ping Li
2026-11-04  8:46   ` Yin Li
2026-11-05  5:53     ` Ping Li
2026-11-06 15:08       ` Rob Herring [this message]
2026-11-09  2:58         ` Yin Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261106150822.GA3193214-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=ben.horgan@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=james.morse@arm.com \
    --cc=leeonion.muyu@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sdonthineni@nvidia.com \
    --cc=yin.li@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.