Re: [PATCH v6 08/10] arm_mpam: add MPAM-Fb MSC firmware access support
Jonathan Cameron <[email protected]> Thu, 30 Jul 2026 12:05:16 -0700
| Newsgroups | org.kernel.vger.linux-acpi,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Organization | Qualcomm |
| Message-ID | <[email protected]> |
On Thu, 30 Jul 2026 17:25:37 +0200 Andre Przywara <[email protected]> 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 > (simple) SCMI message generation, for just the fields we need. > > [1] https://developer.arm.com/documentation/den0144/latest > > Signed-off-by: Andre Przywara <[email protected]> On trivial style consistency comment. Otherwise looks fine to me. Reviewed-by: Jonathan Cameron <[email protected]> > diff --git a/drivers/resctrl/mpam_fb.c b/drivers/resctrl/mpam_fb.c > new file mode 100644 > index 000000000000..e2ce28a602aa > --- /dev/null > +++ b/drivers/resctrl/mpam_fb.c ... > +static int mpam_fb_send_request(struct mpam_pcc_chan *pcc_chan, u32 msc_id, > + u16 reg, u32 *result, int mpam_fb_command) > +{ > + unsigned int token = atomic_inc_return(&mpam_fb_token); > + struct acpi_pcct_ext_pcc_shared_memory __iomem *pcc_shmem; > + struct pcc_mbox_chan *chan; > + void __iomem *payload_ofs; > + int mpam_fb_err = 0; > + u32 status; > + int ret; > + > + if (!pcc_chan) > + return -ENODEV; > + > + chan = pcc_chan->pcc_chan; > + > + /* prune token to fit into the 10 bits inside the command register */ > + token = FIELD_GET(MPAM_MSC_TOKEN_MASK, > + FIELD_PREP(MPAM_MSC_TOKEN_MASK, token)); > + > + mutex_lock(&pcc_chan->pcc_chan_lock); > + > + switch (mpam_fb_command) { > + case MPAM_MSC_WRITE_CMD: > + mpam_fb_build_write_message(msc_id, reg, *result, > + token, chan->shmem); > + break; > + case MPAM_MSC_READ_CMD: > + mpam_fb_build_read_message(msc_id, reg, token, chan->shmem); > + break; > + case MPAM_PROTOCOL_VERSION_CMD: > + mpam_fb_build_version_message(token, chan->shmem); > + break; > + default: > + dev_err(pcc_chan->pcc_cl.dev, "unsupported MPAM-Fb command %d\n", > + mpam_fb_command); > + ret = -EINVAL; > + goto out_err; > + } > + > + ret = mbox_send_message(chan->mchan, NULL); > + if (ret < 0) > + goto out_err; > + > + pcc_shmem = chan->shmem; > + payload_ofs = chan->shmem + sizeof(*pcc_shmem); > + status = readl(&pcc_shmem->command); > + if (FIELD_GET(MPAM_MSC_TOKEN_MASK, status) != token) { > + ret = -ETIMEDOUT; > + Slightly odd style. I'd drop blank lines in places like this. They aren't consistent as things stand. > + goto out_err; > + } > + > + mpam_fb_err = readl(payload_ofs + 0x0); > + if (mpam_fb_err < 0) { > + ret = mpam_fb_translate_error_code(mpam_fb_err); > + > + goto out_err; > + } > + > + if (mpam_fb_command != MPAM_MSC_WRITE_CMD) > + *result = readl(payload_ofs + 0x4); > + > + mutex_unlock(&pcc_chan->pcc_chan_lock); > + > + return 0; > + > +out_err: > + mutex_unlock(&pcc_chan->pcc_chan_lock); > + > + mpam_fb_disable_mpam(ret, mpam_fb_err); > + > + return ret; > +}