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

[Andre Przywara]

Hi Niyas,

many thanks for replying on the list!

On 5/18/26 10:52, Niyas Sait wrote:
> 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.

Ah yes, I was confused about the offsets, and since I also provided the 
firmware side in my very crude test setup, this matches, courtesy of me 
making the same mistake on both sides ;-)

> 
> 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.

Ah yes, I now see that I actually used a PCC subspace type 2 layout, 
which explains some parts of my confusion, I guess.

So I changed that now: as you show above, there is just an offset, but 
the relevant fields magically match otherwise. Since there is no SCMI 
support in the code base at the moment, I can just change the offsets, 
and deal with SCMI later.

> 
>> +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.

Ah, this is a very good point. As mention, I was staring at type 2 in 
the ACPI spec. The PCC type 3 semantics is effectively very similar, or 
at least can made to be, by just putting the right bits into the PCCT 
table. The nice thing is that the Linux PCC code already handles the 
channel negotiation, as part of the mailbox abstraction, so by just 
populating the right fields in the PCCT table, I get the same semantics 
on the device side, and can drop the whole channel ownership negotiation 
from the MPAM code.

I now did one trick to simplify this: I kept the shared memory area 
using the SCMI layout, so with the payload starting at offset 0x1c. In 
the PCCT table I add 0xc to the beginning of the SRAM area, and give 
that as the base address. This makes the SCP side always see the same 
layout, at least for the relevant bits. Then I tell PCCT that the 
command update register is at offset 0x4 of SRAM (so *before* the PCCT 
shared mem area), which is exactly the location of the SCMI channel 
ownership bit. To me that looks like it should work with SCMI and PCC 
alike, maybe with some little tweaks on the SCP side.

With those changes it works for me now using type 3. I will send a v2 in 
due time, once I address all the other outstanding issues.

Many thanks for the heads up on this one!

Cheers,
Andre