From: Andre Przywara <andre.przywara@arm•com>
To: Niyas Sait <niyas.sait@arm•com>
Cc: ben.horgan@arm•com, catalin.marinas@arm•com, fenghuay@nvidia•com,
guohanjun@huawei•com, james.morse@arm•com, jic23@kernel•org,
lenb@kernel•org, linux-acpi@vger•kernel.org,
linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org, lpieralisi@kernel•org,
rafael@kernel•org, reinette.chatre@intel•com,
sudeep.holla@kernel•org, will@kernel•org
Subject: Re: [PATCH 3/5] arm_mpam: add MPAM-Fb MSC firmware access support
Date: Thu, 21 May 2026 17:54:38 +0200 [thread overview]
Message-ID: <bd1edbb2-5b0a-4dfa-ba84-4626f79acb7c@arm.com> (raw)
In-Reply-To: <20260518085237.3259344-1-niyas.sait@arm.com>
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
next prev parent reply other threads:[~2026-05-21 15:54 UTC|newest]
Thread overview: 27+ 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-05-21 17:27 ` Srivathsa L Rao
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-05-18 10:31 ` Niyas Sait
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
2026-05-18 8:52 ` Niyas Sait
2026-05-21 15:54 ` Andre Przywara [this message]
2026-05-18 14:11 ` Sudeep Holla
2026-04-29 14:13 ` [PATCH 4/5] arm_mpam: prevent MPAM-Fb accesses inside IRQ handler Andre Przywara
2026-05-18 10:57 ` Niyas Sait
2026-05-21 15:59 ` 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
2026-05-18 11:14 ` Niyas Sait
2026-05-21 16:04 ` Andre Przywara
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=bd1edbb2-5b0a-4dfa-ba84-4626f79acb7c@arm.com \
--to=andre.przywara@arm$(echo .)com \
--cc=ben.horgan@arm$(echo .)com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=fenghuay@nvidia$(echo .)com \
--cc=guohanjun@huawei$(echo .)com \
--cc=james.morse@arm$(echo .)com \
--cc=jic23@kernel$(echo .)org \
--cc=lenb@kernel$(echo .)org \
--cc=linux-acpi@vger$(echo .)kernel.org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=lpieralisi@kernel$(echo .)org \
--cc=niyas.sait@arm$(echo .)com \
--cc=rafael@kernel$(echo .)org \
--cc=reinette.chatre@intel$(echo .)com \
--cc=sudeep.holla@kernel$(echo .)org \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox