[PATCH 3/5] arm_mpam: add MPAM-Fb MSC firmware access support

[Niyas Sait]

Hi Andre,

On Wed, Apr 29, 2026 at 04:13:37PM +0200, Andre Przywara wrote:

> +#define SCMI_CHAN_FLAGS_OFS	0x10
> +#define SCMI_CHAN_FLAGS_IRQ		BIT(0)
> +#define SCMI_MSG_LENGTH_OFS	0x14
> +#define SCMI_MSG_HEADER_OFS	0x18
> +#define SCMI_MSG_PAYLOAD_OFS	0x1c

I think this will not work for the ACPI PCC Type 3 MPAM Fb path.

SCMI shared memory transport layout and ACPI Extended PCC subspace
shared memory layout use different offsets for the flags, length, command,
and payload fields.

For Extended PCC subspace, the layout is:

Flags   @ 0x04
Length  @ 0x08
Command @ 0x0c
Payload @ 0x10

SCMI shared memory layout uses:

Flags   @ 0x10
Length  @ 0x14
Command @ 0x18
Payload @ 0x1c

You will need to use the extended PCC subspace layout for the ACPI path.

> +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);
> +}

This also assumes SCMI channel status completion semantics in shared memory.
For PCC Type 3 transport, completion should follow PCC Type 3 completion mechanisms.

Thanks,
Niyas