From: Ben Horgan <ben.horgan@arm.com>
To: Andre Przywara <andre.przywara@arm.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Hanjun Guo <guohanjun@huawei.com>,
Sudeep Holla <sudeep.holla@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, James Morse <james.morse@arm.com>,
Reinette Chatre <reinette.chatre@intel.com>,
Fenghua Yu <fenghuay@nvidia.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] arm_mpam: add MPAM-Fb MSC firmware access support
Date: Thu, 14 May 2026 10:30:35 +0100 [thread overview]
Message-ID: <b73bc4e8-ac7a-45ee-9eaa-557fb41d5ad2@arm.com> (raw)
In-Reply-To: <20260429141339.3171205-4-andre.przywara@arm.com>
Hi Andre,
I'm just having another look to try and understand this a bit better.
On 4/29/26 15:13, Andre Przywara wrote:
> The Arm MPAM Firmware-backed (Fb) Profile document[1] describes an
> alternative way of accessing the "Memory System Components" (MSC) in an
> MPAM enabled system.
> Normally the MSCs are MMIO mapped, but in some implementations this
> might not be possible (MSC located outside of the local socket, MSC
> mapped secure-only) or desirable (direct MMIO access too slow or needs
> to be mediated through a control processor). MPAM-fb standardises a
> protocol to abstract MSC accesses, building on the SCMI protocol.
>
> Add functions that do an MSC read or write access by redirecting the
> request through a firmware interface. For now this done via an ACPI
> PCC shared memory and mailbox combination.
>
> Since the protocol used is only a small subset of the full SCMI spec,
> and the SCMI protocol has no full ACPI support anyway, open-code the
> SCMI message generation and handshake, for just the fields we need.
>
> [1] https://developer.arm.com/documentation/den0144/latest
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> drivers/resctrl/Makefile | 2 +-
> drivers/resctrl/mpam_devices.c | 16 +++-
> drivers/resctrl/mpam_fb.c | 158 ++++++++++++++++++++++++++++++++
> drivers/resctrl/mpam_fb.h | 17 ++++
> drivers/resctrl/mpam_internal.h | 5 +
> include/linux/arm_mpam.h | 2 +-
> 6 files changed, 196 insertions(+), 4 deletions(-)
> create mode 100644 drivers/resctrl/mpam_fb.c
> create mode 100644 drivers/resctrl/mpam_fb.h
[...]
> static inline void _mpam_write_partsel_reg(struct mpam_msc *msc, u16 reg, u32 val)
> diff --git a/drivers/resctrl/mpam_fb.c b/drivers/resctrl/mpam_fb.c
> new file mode 100644
> index 000000000000..bfb5798c74b0
> --- /dev/null
> +++ b/drivers/resctrl/mpam_fb.c
[...]
> +
> +#define SCMI_CHANNEL_FREE true
> +#define SCMI_CHANNEL_BUSY false
> +static int mpam_fb_wait_for_channel(struct pcc_mbox_chan *chan,
> + bool free)
> +{
> + u32 status = free ? SCMI_CHAN_STATUS_FREE_BIT : 0;
> + u32 val;
> +
> + /*
> + * The channel should really be free always at this point, as we take
> + * a lock for every read or write request. Check the free bit anyway,
> + * for good measure and to catch corner cases.
> + */
> + return readl_poll_timeout(chan->shmem + SCMI_CHAN_STATUS_OFS, val,
> + (val & SCMI_CHAN_STATUS_FREE_BIT) == status,
> + 1, 10000);
> +}
What would be the reason to call mpam_fb_wait_for_channel() with
free=SCMI_CHANNEL_BUSY? I see that in this patch you always call it with
free=SCMI_CHANNEL_FREE.
Thanks,
Ben
> +
> +static int mpam_fb_send_request(struct mpam_msc *msc, u16 reg, u32 *result,
> + bool is_write)
> +{
> + unsigned int token = atomic_inc_return(&mpam_fb_token);
> + struct pcc_mbox_chan *chan = msc->pcc_chan;
> + u32 status;
> + int ret;
> +
> + guard(mutex)(&msc->pcc_chan_lock);
> + ret = mpam_fb_wait_for_channel(chan, SCMI_CHANNEL_FREE);
> + if (ret < 0)
> + return ret;
> +
> + /* Clear error bit and mark the channel as belonging to the callee */
> + writel(0, chan->shmem + SCMI_CHAN_STATUS_OFS);
> +
> + if (is_write)
> + ret = mpam_fb_build_write_message(msc->mpam_fb_msc_id, reg,
> + *result, token, chan->shmem);
> + else
> + ret = mpam_fb_build_read_message(msc->mpam_fb_msc_id, reg,
> + token, chan->shmem);
> + if (ret < 0)
> + return ret;
> +
> + ret = mbox_send_message(chan->mchan, NULL);
> + if (ret < 0)
> + return ret;
> +
> + ret = mpam_fb_wait_for_channel(chan, SCMI_CHANNEL_FREE);
> + if (ret)
> + return ret;
> +
> + status = readl(chan->shmem + SCMI_MSG_HEADER_OFS);
> + if (FIELD_GET(MPAM_MSC_TOKEN_MASK, status) != token)
> + return -ETIMEDOUT;
> +
> + ret = readl(chan->shmem + SCMI_MSG_PAYLOAD_OFS + 0x0);
> + if (ret < 0)
> + return ret;
> +
> + if (!is_write)
> + *result = readl(chan->shmem + SCMI_MSG_PAYLOAD_OFS + 0x4);
> +
> + return 0;
> +}
> +
> +int mpam_fb_send_read_request(struct mpam_msc *msc, u16 reg, u32 *result)
> +{
> + return mpam_fb_send_request(msc, reg, result, false);
> +}
> +
> +int mpam_fb_send_write_request(struct mpam_msc *msc, u16 reg, u32 value)
> +{
> + return mpam_fb_send_request(msc, reg, &value, true);
> +}
next prev parent reply other threads:[~2026-05-14 9:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 14:13 [PATCH 0/5] arm_mpam: Add MPAM-Fb firmware support Andre Przywara
2026-04-29 14:13 ` [PATCH 1/5] arm_mpam: Parse the rest of the ACPI table Andre Przywara
2026-05-08 10:21 ` Ben Horgan
2026-05-12 16:13 ` Andre Przywara
2026-04-29 14:13 ` [PATCH 2/5] arm_mpam: Split the locking around the mon_sel registers Andre Przywara
2026-05-08 10:23 ` Ben Horgan
2026-04-29 14:13 ` [PATCH 3/5] arm_mpam: add MPAM-Fb MSC firmware access support Andre Przywara
2026-05-08 10:33 ` Ben Horgan
2026-05-15 16:04 ` Andre Przywara
2026-05-14 9:30 ` Ben Horgan [this message]
2026-04-29 14:13 ` [PATCH 4/5] arm_mpam: prevent MPAM-Fb accesses inside IRQ handler Andre Przywara
2026-04-29 14:13 ` [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support Andre Przywara
2026-04-30 8:35 ` Sudeep Holla
2026-04-30 9:20 ` Andre Przywara
2026-04-30 10:25 ` Sudeep Holla
2026-05-08 10:48 ` Ben Horgan
2026-05-13 14:51 ` Andre Przywara
2026-05-14 9:10 ` 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=b73bc4e8-ac7a-45ee-9eaa-557fb41d5ad2@arm.com \
--to=ben.horgan@arm.com \
--cc=andre.przywara@arm.com \
--cc=catalin.marinas@arm.com \
--cc=fenghuay@nvidia.com \
--cc=guohanjun@huawei.com \
--cc=james.morse@arm.com \
--cc=jic23@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=rafael@kernel.org \
--cc=reinette.chatre@intel.com \
--cc=sudeep.holla@kernel.org \
--cc=will@kernel.org \
/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.