On Wed, 10 Sep 2025 20:43:05 +0000
James Morse <james.morse@xxxxxxx> wrote:
> From: Rohit Mathew <rohit.mathew@xxxxxxx>
>
> mpam v0.1 and versions above v1.0 support optional long counter for
> memory bandwidth monitoring. The MPAMF_MBWUMON_IDR register have fields
> indicating support for long counters. As of now, a 44 bit counter
> represented by HAS_LONG field (bit 30) and a 63 bit counter represented
> by LWD (bit 29) can be optionally integrated. Probe for these counters
> and set corresponding feature bits if any of these counters are present.
>
> Signed-off-by: Rohit Mathew <rohit.mathew@xxxxxxx>
> Signed-off-by: James Morse <james.morse@xxxxxxx>
> Reviewed-by: Ben Horgan <ben.horgan@xxxxxxx>
Hi Rohit, James.
I'd like a little more justification of the 'front facing' use for the first
feature bit. To me that seems confusing but I may well be missing why
we can't have 3 exclusive features.
Jonathan
> ---
> drivers/resctrl/mpam_devices.c | 23 ++++++++++++++++++++++-
> drivers/resctrl/mpam_internal.h | 9 +++++++++
> 2 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index eeb62ed94520..bae9fa9441dc 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -795,7 +795,7 @@ static void mpam_ris_hw_probe(struct mpam_msc_ris *ris)
> dev_err_once(dev, "Counters are not usable because not-ready timeout was not provided by firmware.");
> }
> if (FIELD_GET(MPAMF_MSMON_IDR_MSMON_MBWU, msmon_features)) {
> - bool hw_managed;
> + bool has_long, hw_managed;
> u32 mbwumon_idr = mpam_read_partsel_reg(msc, MBWUMON_IDR);
>
> props->num_mbwu_mon = FIELD_GET(MPAMF_MBWUMON_IDR_NUM_MON, mbwumon_idr);
> @@ -805,6 +805,27 @@ static void mpam_ris_hw_probe(struct mpam_msc_ris *ris)
> if (FIELD_GET(MPAMF_MBWUMON_IDR_HAS_RWBW, mbwumon_idr))
> mpam_set_feature(mpam_feat_msmon_mbwu_rwbw, props);
>
> + /*
> + * Treat long counter and its extension, lwd as mutually
> + * exclusive feature bits. Though these are dependent
> + * fields at the implementation level, there would never
> + * be a need for mpam_feat_msmon_mbwu_44counter (long
> + * counter) and mpam_feat_msmon_mbwu_63counter (lwd)
> + * bits to be set together.
> + *
> + * mpam_feat_msmon_mbwu isn't treated as an exclusive
> + * bit as this feature bit would be used as the "front
> + * facing feature bit" for any checks related to mbwu
> + * monitors.
Why do we need such a 'front facing' bit? Why isn't it sufficient just to
add a little helper or macro to find out if mbwu is turned on?
> + */
> + has_long = FIELD_GET(MPAMF_MBWUMON_IDR_HAS_LONG, mbwumon_idr);
> + if (props->num_mbwu_mon && has_long) {
> + if (FIELD_GET(MPAMF_MBWUMON_IDR_LWD, mbwumon_idr))
> + mpam_set_feature(mpam_feat_msmon_mbwu_63counter, props);
> + else
> + mpam_set_feature(mpam_feat_msmon_mbwu_44counter, props);
> + }
> +
> /* Is NRDY hardware managed? */
> hw_managed = mpam_ris_hw_probe_hw_nrdy(ris, MBWU);
> if (hw_managed)
> diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
> index 725c2aefa8a2..c190826dfbda 100644
> --- a/drivers/resctrl/mpam_internal.h
> +++ b/drivers/resctrl/mpam_internal.h
> @@ -158,7 +158,16 @@ enum mpam_device_features {
> mpam_feat_msmon_csu_capture,
> mpam_feat_msmon_csu_xcl,
> mpam_feat_msmon_csu_hw_nrdy,
> +
> + /*
> + * Having mpam_feat_msmon_mbwu set doesn't mean the regular 31 bit MBWU
> + * counter would be used. The exact counter used is decided based on the
> + * status of mpam_feat_msmon_mbwu_44counter/mpam_feat_msmon_mbwu_63counter
> + * as well.
> + */
> mpam_feat_msmon_mbwu,
> + mpam_feat_msmon_mbwu_44counter,
> + mpam_feat_msmon_mbwu_63counter,
> mpam_feat_msmon_mbwu_capture,
> mpam_feat_msmon_mbwu_rwbw,
> mpam_feat_msmon_mbwu_hw_nrdy,
