RE: [EXT] Re: [PATCH v1 13/14] arm_mpam: Handle resource instances mapped to different controls

[Amit Singh Tomar]

Hi Peter, 

Thanks for having a look.

-----Original Message-----
From: Peter Newman <peternewman@xxxxxxxxxx> 
Sent: Wednesday, January 17, 2024 11:33 PM
To: Amit Singh Tomar <amitsinght@xxxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; fenghua.yu@xxxxxxxxx; reinette.chatre@xxxxxxxxx; james.morse@xxxxxxx; George Cherian <gcherian@xxxxxxxxxxx>; robh@xxxxxxxxxx; dfustini@xxxxxxxxxxxx; jonathan.cameron@xxxxxxxxxx
Subject: [EXT] Re: [PATCH v1 13/14] arm_mpam: Handle resource instances mapped to different controls

External Email

----------------------------------------------------------------------
Hi Amit,

On Wed, Jan 17, 2024 at 6:15 AM Amit Singh Tomar <amitsinght@xxxxxxxxxxx> wrote:

>
> +/* Club different resource properties under a class that resctrl 
> +uses,
> + * for instance, L3 cache that supports both CPOR, and DSPRI need to 
> +have
> + * knowledge of both cpbm_wd and dspri_wd. This is needed when two 
> +controls
> + * are enumerated under differnt RIS Index.
> + */
> +static void mpam_enable_club_class_features(struct mpam_class *class,
> +                                           struct mpam_msc_ris *ris)

It looks like "club" is used as a synonym to "class" here to evade the bigger issue that mpam_classes are not defined correctly as DSPRI resources should not be in the same mpam_class as the L3 CPOR and CSU features.

This hardware makes it clear that the definition of mpam_class as all resources in a (level x {memory,cache}) needs to be revised.

On Marvell platform, DSPRI control register (MPAMCFG_PRI_NS), and Identification Register (MPAMF_PRI_IDR_NS)  are implemented within the LLC MPAM block (the address range contains control and identification registers for CPOR, and DSPRI), and therefore we treat DSPRI as one of the L3 resource. However, suppose we approach it as totally different standalone resource type (PRI) other than Cache storage resource type (CPOR, and CCAP), and define a new MPAM class type for it, there is no standard way to discover this new resource type (PRI) from ACPI tables.

I'm concerned about accessing DSPRI related registers, if we are going to tide it to new MPAM class (as we discover whole L3 MPAM block using firmware tables, and tide it's resources to L3 MPAM class).

Thanks
-Amit