mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yin Li <yin.li@oss.qualcomm.com>
To: Rob Herring <robh@kernel.org>
Cc: "James Morse" <james.morse@arm.com>,
	"Shanker Donthineni" <sdonthineni@nvidia.com>,
	"Ben Horgan" <ben.horgan@arm.com>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Reinette Chatre" <reinette.chatre@intel.com>,
	"Fenghua Yu" <fenghuay@nvidia.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konradybcio@kernel.org>,
	"Gavin Shan" <gshan@redhat.com>,
	"Andre Przywara" <andre.przywara@arm.com>,
	"Drew Fustini" <fustini@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Shaopeng Tan" <tan.shaopeng@jp.fujitsu.com>,
	trilok.soni@oss.qualcomm.com, aiqun.yu@oss.qualcomm.com,
	ganapatrao.kulkarni@oss.qualcomm.com,
	"Srivathsa L Rao" <srivathsa.rao@oss.qualcomm.com>,
	"Huang Yiwei" <huang.yiwei@oss.qualcomm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	driver-core@lists.linux.dev, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 3/8] dt-bindings: arm: Add MPAM MSC binding
Date: Mon, 12 Oct 2026 15:05:31 +0800	[thread overview]
Message-ID: <2eddfb6d-c622-4d72-827e-aed685e72b9c@oss.qualcomm.com> (raw)
In-Reply-To: <20261008212736.GB1318789-robh@kernel.org>



On 10/9/2026 5:27 AM, Rob Herring wrote:
> On Thu, Oct 08, 2026 at 02:41:12PM +0800, Yin Li wrote:
>> From: Rob Herring <robh@kernel.org>
>>
>> The binding is designed around the assumption that an MSC will be a
>> sub-block of something else such as a memory controller, cache controller,
>> or IOMMU. However, it's certainly possible a design does not have that
>> association or has a mixture of both, so the binding illustrates how we can
>> support that with RIS child nodes.
>>
>> A key part of MPAM is we need to know about all of the MSCs in the system
>> before it can be enabled. This drives the need for the genericish
>> 'arm,mpam-msc' compatible. Though we can't assume an MSC is accessible
>> until a h/w specific driver potentially enables the h/w.
>>
>> Cc: James Morse <james.morse@arm.com>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: James Morse <james.morse@arm.com>
>> [ Yin Li and Huang Yiwei: use oneOf for the compatible to allow both
>>    standalone arm,mpam-msc and the two-item combination; fix schema field
>>    order, type constraints and yamllint spacing; fix example reg addresses,
>>    add arm,mpam-device phandle and remove TODO comment ]
>> Co-developed-by: Huang Yiwei <huang.yiwei@oss.qualcomm.com>
>> Signed-off-by: Huang Yiwei <huang.yiwei@oss.qualcomm.com>
>> Signed-off-by: Yin Li <yin.li@oss.qualcomm.com>
>> ---
>>   .../devicetree/bindings/arm/arm,mpam-msc.yaml      | 202 +++++++++++++++++++++
>>   1 file changed, 202 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,mpam-msc.yaml b/Documentation/devicetree/bindings/arm/arm,mpam-msc.yaml
>> new file mode 100644
>> index 000000000000..3c7b13a23ff2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/arm,mpam-msc.yaml
>> @@ -0,0 +1,202 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/arm,mpam-msc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Arm Memory System Resource Partitioning and Monitoring (MPAM)
>> +
>> +maintainers:
>> +  - Rob Herring <robh@kernel.org>
>> +
>> +description: |
>> +  The Arm MPAM specification can be found here:
>> +
>> +  https://developer.arm.com/documentation/ddi0598/latest
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - const: arm,mpam-msc                   # Further details are discoverable
>> +      - items:
>> +          - const: arm,mpam-memory-controller-msc
> 
> Why do we need this?
> 

Hi Rob,

Thanks for the review.

The 'arm,mpam-memory-controller-msc' compatible is needed because,
unlike cache MSCs, memory controller MSCs cannot rely on the parent node
to identify the resource type.

Cache controllers universally carry a 'cache' compatible, so the driver
can recognise any cache parent and derive the cache ID from standard
properties. No equivalent convention exists for memory controllers, and
the component ID comes from the MSC's own 'numa-node-id' rather than the
parent, so there is no parent attribute to rely on.

'arm,mpam-memory-controller-msc' provides the explicit declaration that
this MSC controls memory. It is used in "arm_mpam: Add support for
memory controller MSC on DT platforms".

On 'oneOf': the original 'items' form requires both strings to be
present, which is not appropriate for cache MSCs. Andre also noted this 
in RFC v2, so we changed it to 'oneOf'.

>> +          - const: arm,mpam-msc
>> +
>> +  reg:
>> +    maxItems: 1
>> +    description: A memory region containing registers as defined in the MPAM
>> +      specification.
>> +
>> +  interrupts:
>> +    minItems: 1
>> +    items:
>> +      - description: error (optional)
>> +      - description: overflow (optional, only for monitoring)
>> +
>> +  interrupt-names:
>> +    oneOf:
>> +      - items:
>> +          - enum: [error, overflow]
>> +      - items:
>> +          - const: error
>> +          - const: overflow
> 
> This can be expressed as:
> 
>        minItems: 1
>        items:
>          - enum: [error, overflow]
>          - const: overflow
> 

Agreed, will update.

>> +
>> +  arm,not-ready-us:
>> +    description: The maximum time in microseconds for monitoring data to be
>> +      accurate after a settings change. For more information, see the
>> +      Not-Ready (NRDY) bit description in the MPAM specification.
>> +
>> +  numa-node-id:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description: NUMA node identifier for the memory resource this MSC controls.
>> +
>> +  '#address-cells':
>> +    const: 1
>> +
>> +  '#size-cells':
>> +    const: 0
>> +
>> +patternProperties:
>> +  '^ris@[0-9a-f]+$':
> 
> Based on the 'reg' constraints, drop the '+'.

Agreed, will update.

> 
>> +    type: object
>> +    additionalProperties: false
>> +    description:
>> +      RIS nodes for each resource instance in an MSC. These nodes are required
>> +      for each resource instance implementing known MPAM controls
>> +
>> +    properties:
>> +      compatible:
>> +        enum:
>> +          - arm,mpam-cache
>> +          # Memory bandwidth
>> +          - arm,mpam-memory
>> +
>> +      reg:
>> +        minimum: 0
>> +        maximum: 0xf
>> +
>> +      cpus:
>> +        $ref: /schemas/types.yaml#/definitions/phandle-array
> 
> Drop. 'cpus' has a type already.
> 

Agreed, will update.

>> +        description:
>> +          Phandle(s) to the CPU node(s) this RIS belongs to. By default, the
>> +          parent device's affinity is used.
>> +
>> +      arm,mpam-device:
>> +        $ref: /schemas/types.yaml#/definitions/phandle
>> +        description:
>> +          By default, the MPAM enabled device associated with a RIS is the MSC's
>> +          parent node. It is possible for each RIS to be associated with
>> +          different devices in which case 'arm,mpam-device' should be used.
> 
> We should drop this until there's a use for it.
> 

On 'arm,mpam-device': we believe this property is structurally
necessary. The MPAM specification (IHI0099B) states:
     "Resource instance selection (RIS) allows an MPAM MSC to support
     multiple resources, including multiple resources using the same
     resource type or partitioning control. When RIS is implemented, an
     MPAM MSC must implement independent resource controls and two or
     more resources of the same type."

Once an MSC implements RIS, it must support ≥ 2 resources of the same
type (a spec requirement). An MSC node has only one parent, so the
association between each RIS and its corresponding device cannot be
expressed through a shared parent alone. A per-RIS explicit association
mechanism is therefore needed, and 'arm,mpam-device' is designed for
exactly this purpose.

The property is used in the immediately following patch "arm_mpam: Add
device tree support for MSC probing". If you have a different view on
this design, we are happy to discuss further.


>> +
>> +    required:
>> +      - compatible
>> +      - reg
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +dependencies:
>> +  interrupts: [interrupt-names]
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    L3: cache-controller@30000000 {
>> +        compatible = "foo,a-l3-cache", "cache";
>> +        cache-level = <3>;
>> +        cache-unified;
>> +
>> +        ranges = <0x0 0x30000000 0x800000>;
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +
>> +        msc@10000 {
>> +            compatible = "arm,mpam-msc";
>> +            reg = <0x10000 0x2000>;
>> +            interrupts = <1>, <2>;
>> +            interrupt-names = "error", "overflow";
>> +            arm,not-ready-us = <1>;
>> +            /* CPU affinity implied by parent cache node  */
>> +        };
>> +    };
>> +
>> +    mem: memory-controller@20000 {
>> +        compatible = "foo,a-memory-controller";
>> +        reg = <0x20000 0x1000>;
>> +
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        ranges;
>> +
>> +        msc@21000 {
>> +            compatible = "arm,mpam-memory-controller-msc", "arm,mpam-msc";
>> +            reg = <0x21000 0x1000>;
>> +            interrupts = <3>;
>> +            interrupt-names = "error";
>> +            arm,not-ready-us = <1>;
>> +            numa-node-id = <1>;
>> +        };
>> +    };
>> +
>> +    iommu@40000 {
>> +        reg = <0x40000 0x1000>;
>> +
>> +        ranges;
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +
>> +        msc@41000 {
>> +            compatible = "arm,mpam-msc";
>> +            reg = <0x41000 0x1000>;
>> +            interrupts = <5>, <6>;
>> +            interrupt-names = "error", "overflow";
>> +            arm,not-ready-us = <1>;
>> +
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +
>> +            ris@2 {
>> +                compatible = "arm,mpam-cache";
>> +                reg = <2>;
>> +                arm,mpam-device = <&L3>;
>> +            };
>> +        };
>> +    };
>> +
>> +    msc@80000 {
>> +        compatible = "foo,a-standalone-msc";
>> +        reg = <0x80000 0x1000>;
>> +
>> +        clocks = <&clks 123>;
>> +
>> +        ranges;
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +
>> +        msc@10000 {
>> +            compatible = "arm,mpam-msc";
>> +            reg = <0x10000 0x2000>;
>> +            interrupts = <7>;
>> +            interrupt-names = "overflow";
>> +            arm,not-ready-us = <1>;
>> +
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +
>> +            ris@0 {
>> +                compatible = "arm,mpam-cache";
>> +                reg = <0>;
>> +                arm,mpam-device = <&L2_0>;
>> +            };
>> +
>> +            ris@1 {
>> +                compatible = "arm,mpam-memory";
>> +                reg = <1>;
>> +                arm,mpam-device = <&mem>;
>> +            };
>> +        };
>> +    };
>> +
>> +...
>>
>> -- 
>> 2.34.1
>>

-- 
Thx and BRs,
Yin


  reply	other threads:[~2026-10-12  7:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08  6:41 [PATCH v3 0/8] arm-mpam: Add basic device tree support for resctrl Yin Li
2026-10-08  6:41 ` [PATCH v3 1/8] arm_mpam: Fix the RIS index range check in mpam_ris_create_locked Yin Li
2026-10-08  6:41 ` [PATCH v3 2/8] arm_mpam: Fix MSC MMIO window size off-by-one with resource_size() Yin Li
2026-10-08  6:41 ` [PATCH v3 3/8] dt-bindings: arm: Add MPAM MSC binding Yin Li
2026-10-08 21:27   ` Rob Herring
2026-10-12  7:05     ` Yin Li [this message]
2026-10-12 10:24       ` Yin Li
2026-10-08  6:41 ` [PATCH v3 4/8] cacheinfo: Expose the code to generate a cache-id from a device_node Yin Li
2026-10-08  6:41 ` [PATCH v3 5/8] arm_mpam: Add device tree support for MSC probing Yin Li
2026-10-08  6:41 ` [PATCH v3 6/8] arm_mpam: Add support for memory controller MSC on DT platforms Yin Li
2026-10-08 21:29   ` Rob Herring
2026-10-12 10:11     ` Yin Li
2026-10-08  6:41 ` [PATCH v3 7/8] arm_mpam: Support MSC accessibility derivation from RIS nodes Yin Li
2026-10-08  6:41 ` [PATCH DNM v3 8/8] arm64: dts: qcom: kaanapali: Add MPAM MSC nodes for the L2 caches Yin Li
2026-10-08 21:00   ` Rob Herring
2026-10-12 10:48     ` Yin Li
2026-10-12 11:27       ` Ben Horgan

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=2eddfb6d-c622-4d72-827e-aed685e72b9c@oss.qualcomm.com \
    --to=yin.li@oss.qualcomm.com \
    --cc=aiqun.yu@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=ben.horgan@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=fenghuay@nvidia.com \
    --cc=fustini@kernel.org \
    --cc=ganapatrao.kulkarni@oss.qualcomm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gshan@redhat.com \
    --cc=huang.yiwei@oss.qualcomm.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=james.morse@arm.com \
    --cc=jic23@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=robh@kernel.org \
    --cc=sdonthineni@nvidia.com \
    --cc=srivathsa.rao@oss.qualcomm.com \
    --cc=tan.shaopeng@jp.fujitsu.com \
    --cc=trilok.soni@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®