drivers/mailbox/pcc.c | 118 ++++++++++---------------------------------------- include/acpi/pcc.h | 29 ------------- 2 files changed, 23 insertions(+), 124 deletions(-)
This series refines and stabilizes the PCC mailbox driver to improve
initialisation order, interrupt handling, and completion signaling.
It begins by reverting a previous patch that introduced redundant shared
buffer management, simplifying the driver and restoring consistency with the
mailbox core framework. It is essential to have a proper baseline for the
main changes in the series.
Subsequent patches add proper completion reporting, clarify completion mode
selection, and fix subtle sequencing and interrupt issues to ensure
predictable, robust operation across ACPI-based PCC implementations.
Specifically, the series:
1. Removes redundant shared buffer logic, reverting an earlier change that
duplicated existing mailbox core features and caused maintenance overhead.
2. Adds ->last_tx_done() support to allow polling clients to verify
transmission completion without relying on interrupts.
3. Explicitly configures completion modes (txdone_irq or txdone_poll) based
on ACPI PCCT doorbell capability flag, ensuring the correct completion
mechanism is chosen for each platform.
4. Marks transmit completion in the IRQ handler by invoking mbox_chan_txdone(),
preventing timeouts and ensuring proper synchronization for interrupt-driven
transfers.
5. Initializes the shared memory region (SHMEM) before binding clients,
preventing race conditions where clients could access uninitialized memory.
6. Clears any pending responder interrupts before enabling IRQs, avoiding
spurious or false interrupts during startup.
Together, these updates make the PCC mailbox driver cleaner, more reliable,
and fully aligned with the mailbox framework's expectations, improving
determinism and robustness across different hardware platforms.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
Sudeep Holla (6):
Revert "mailbox/pcc: support mailbox management of the shared buffer"
mailbox: pcc: Wire up ->last_tx_done() for PCC channels
mailbox: pcc: Set txdone_irq/txdone_poll based on PCCT flags
mailbox: pcc: Mark Tx as complete in PCC IRQ handler
mailbox: pcc: Initialize SHMEM before binding the channel with the client
mailbox: pcc: Clear any pending responder interrupts before enabling it
drivers/mailbox/pcc.c | 118 ++++++++++----------------------------------------
include/acpi/pcc.h | 29 -------------
2 files changed, 23 insertions(+), 124 deletions(-)
---
base-commit: 7ea30958b3054f5e488fa0b33c352723f7ab3a2a
change-id: 20251016-pcc_mb_updates-d9d428985400
--
Regards,
Sudeep
Tested-by: Adam Young <admiyo@os.amperecompuitng.com> On 10/16/25 15:08, Sudeep Holla wrote: > This series refines and stabilizes the PCC mailbox driver to improve > initialisation order, interrupt handling, and completion signaling. > > It begins by reverting a previous patch that introduced redundant shared > buffer management, simplifying the driver and restoring consistency with the > mailbox core framework. It is essential to have a proper baseline for the > main changes in the series. > > Subsequent patches add proper completion reporting, clarify completion mode > selection, and fix subtle sequencing and interrupt issues to ensure > predictable, robust operation across ACPI-based PCC implementations. > > Specifically, the series: > > 1. Removes redundant shared buffer logic, reverting an earlier change that > duplicated existing mailbox core features and caused maintenance overhead. > > 2. Adds ->last_tx_done() support to allow polling clients to verify > transmission completion without relying on interrupts. > > 3. Explicitly configures completion modes (txdone_irq or txdone_poll) based > on ACPI PCCT doorbell capability flag, ensuring the correct completion > mechanism is chosen for each platform. > > 4. Marks transmit completion in the IRQ handler by invoking mbox_chan_txdone(), > preventing timeouts and ensuring proper synchronization for interrupt-driven > transfers. > > 5. Initializes the shared memory region (SHMEM) before binding clients, > preventing race conditions where clients could access uninitialized memory. > > 6. Clears any pending responder interrupts before enabling IRQs, avoiding > spurious or false interrupts during startup. > > Together, these updates make the PCC mailbox driver cleaner, more reliable, > and fully aligned with the mailbox framework's expectations, improving > determinism and robustness across different hardware platforms. > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > Sudeep Holla (6): > Revert "mailbox/pcc: support mailbox management of the shared buffer" > mailbox: pcc: Wire up ->last_tx_done() for PCC channels > mailbox: pcc: Set txdone_irq/txdone_poll based on PCCT flags > mailbox: pcc: Mark Tx as complete in PCC IRQ handler > mailbox: pcc: Initialize SHMEM before binding the channel with the client > mailbox: pcc: Clear any pending responder interrupts before enabling it > > drivers/mailbox/pcc.c | 118 ++++++++++---------------------------------------- > include/acpi/pcc.h | 29 ------------- > 2 files changed, 23 insertions(+), 124 deletions(-) > --- > base-commit: 7ea30958b3054f5e488fa0b33c352723f7ab3a2a > change-id: 20251016-pcc_mb_updates-d9d428985400 > >
Hi Jassi, On Thu, Oct 16, 2025 at 08:08:14PM +0100, Sudeep Holla wrote: > This series refines and stabilizes the PCC mailbox driver to improve > initialisation order, interrupt handling, and completion signaling. > Are you happy to pull these patches directly from the list or do you prefer me to send you pull request or do you want me to direct this via ACPI/Rafael's tree. Please advice. > It begins by reverting a previous patch that introduced redundant shared > buffer management, simplifying the driver and restoring consistency with the > mailbox core framework. It is essential to have a proper baseline for the > main changes in the series. > > Subsequent patches add proper completion reporting, clarify completion mode > selection, and fix subtle sequencing and interrupt issues to ensure > predictable, robust operation across ACPI-based PCC implementations. > > Specifically, the series: > > 1. Removes redundant shared buffer logic, reverting an earlier change that > duplicated existing mailbox core features and caused maintenance overhead. > > 2. Adds ->last_tx_done() support to allow polling clients to verify > transmission completion without relying on interrupts. > > 3. Explicitly configures completion modes (txdone_irq or txdone_poll) based > on ACPI PCCT doorbell capability flag, ensuring the correct completion > mechanism is chosen for each platform. > > 4. Marks transmit completion in the IRQ handler by invoking mbox_chan_txdone(), > preventing timeouts and ensuring proper synchronization for interrupt-driven > transfers. > > 5. Initializes the shared memory region (SHMEM) before binding clients, > preventing race conditions where clients could access uninitialized memory. > > 6. Clears any pending responder interrupts before enabling IRQs, avoiding > spurious or false interrupts during startup. > > Together, these updates make the PCC mailbox driver cleaner, more reliable, > and fully aligned with the mailbox framework's expectations, improving > determinism and robustness across different hardware platforms. > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > Sudeep Holla (6): > Revert "mailbox/pcc: support mailbox management of the shared buffer" > mailbox: pcc: Wire up ->last_tx_done() for PCC channels > mailbox: pcc: Set txdone_irq/txdone_poll based on PCCT flags > mailbox: pcc: Mark Tx as complete in PCC IRQ handler > mailbox: pcc: Initialize SHMEM before binding the channel with the client > mailbox: pcc: Clear any pending responder interrupts before enabling it > > drivers/mailbox/pcc.c | 118 ++++++++++---------------------------------------- > include/acpi/pcc.h | 29 ------------- > 2 files changed, 23 insertions(+), 124 deletions(-) > --- > base-commit: 7ea30958b3054f5e488fa0b33c352723f7ab3a2a > change-id: 20251016-pcc_mb_updates-d9d428985400 > > > -- > Regards, > Sudeep > -- Regards, Sudeep
On Thu, Nov 27, 2025 at 02:40:56PM +0000, Sudeep Holla wrote: > Hi Jassi, > > On Thu, Oct 16, 2025 at 08:08:14PM +0100, Sudeep Holla wrote: > > This series refines and stabilizes the PCC mailbox driver to improve > > initialisation order, interrupt handling, and completion signaling. > > > Are you happy to pull these patches directly from the list or do you > prefer me to send you pull request or do you want me to direct this via > ACPI/Rafael's tree. Please advice. > Hi Jassi, Sorry for the nag. I did see these patches in -next as well as your v6.19 merge window pull request which didn't make it to Linus tree. However I don't see it -next any longer. Please advice if you want anything from my side so that this can be merged for v6.20/v7.0 -- Regards, Sudeep
On 1/12/26 11:55, Sudeep Holla wrote: > On Thu, Nov 27, 2025 at 02:40:56PM +0000, Sudeep Holla wrote: >> Hi Jassi, >> >> On Thu, Oct 16, 2025 at 08:08:14PM +0100, Sudeep Holla wrote: >>> This series refines and stabilizes the PCC mailbox driver to improve >>> initialisation order, interrupt handling, and completion signaling. >>> >> Are you happy to pull these patches directly from the list or do you >> prefer me to send you pull request or do you want me to direct this via >> ACPI/Rafael's tree. Please advice. >> > Hi Jassi, > > Sorry for the nag. I did see these patches in -next as well as your > v6.19 merge window pull request which didn't make it to Linus tree. > However I don't see it -next any longer. Please advice if you want > anything from my side so that this can be merged for v6.20/v7.0 > I thought you had an approach you wanted to implement for the functions that provided access to the Mailbox internals: you wanted to do them inline but hadn't gotten to them yet. Is that still the case? I will resubmit mine as is with -next if that is acceptable.
On Mon, Jan 26, 2026 at 12:07:26PM -0500, Adam Young wrote: > > > On 1/12/26 11:55, Sudeep Holla wrote: > > On Thu, Nov 27, 2025 at 02:40:56PM +0000, Sudeep Holla wrote: > > > Hi Jassi, > > > > > > On Thu, Oct 16, 2025 at 08:08:14PM +0100, Sudeep Holla wrote: > > > > This series refines and stabilizes the PCC mailbox driver to improve > > > > initialisation order, interrupt handling, and completion signaling. > > > > > > > Are you happy to pull these patches directly from the list or do you > > > prefer me to send you pull request or do you want me to direct this via > > > ACPI/Rafael's tree. Please advice. > > > > > Hi Jassi, > > > > Sorry for the nag. I did see these patches in -next as well as your > > v6.19 merge window pull request which didn't make it to Linus tree. > > However I don't see it -next any longer. Please advice if you want > > anything from my side so that this can be merged for v6.20/v7.0 > > > > I thought you had an approach you wanted to implement for the functions that > provided access to the Mailbox internals: you wanted to do them inline but > hadn't gotten to them yet. Is that still the case? I will resubmit mine as > is with -next if that is acceptable. > Honestly, it has been a while and I have lost the context. Please post what you have or thinking of on top of linux-next or jassi's -next and we can start the discussion fresh. -- Regards, Sudeep
I was just looking at it. I think reposting might cause too much churn,
when the crux of the matter is what to do with these three functions I
added:
extern struct pcc_mbox_chan *
pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id);
extern void pcc_mbox_free_channel(struct pcc_mbox_chan *chan);
extern
int pcc_mbox_write_to_buffer(struct pcc_mbox_chan *pchan, int len, void
*data);
extern
int pcc_mbox_query_bytes_available(struct pcc_mbox_chan *pchan);
extern
int pcc_mbox_read_from_buffer(struct pcc_mbox_chan *pchan, int len,
void *data);
In my last patch I added them as EXPORT_SYMBOL_GPL. You mentioned you
wanted them as inline.
We can do that, but it does mean further exposing the ACPI header file.
THe simplest is pcc_mbox_query_bytes_available which I have posted
below. As you can see, it needs the struct
acpi_pcct_ext_pcc_shared_memory which comes from
include/acpi/actbl2.h. If you are OK with adding that to
include/acpi/pcc.h We can inline the functions in there.
These three functions are requied as a result of the direct access to
the shared memory buffer.
int pcc_mbox_query_bytes_available(struct pcc_mbox_chan *pchan)
{
struct acpi_pcct_ext_pcc_shared_memory pcc_header;
struct pcc_chan_info *pinfo = pchan->mchan->con_priv;
int data_len;
u64 val;
pcc_chan_reg_read(&pinfo->cmd_complete, &val);
if (val) {
pr_info("%s Buffer not enabled for reading", __func__);
return -1;
}
memcpy_fromio(&pcc_header, pchan->shmem,
sizeof(pcc_header));
data_len = pcc_header.length - sizeof(u32) + sizeof(pcc_header);
return data_len;
}
On 1/27/26 04:29, Sudeep Holla wrote:
> On Mon, Jan 26, 2026 at 12:07:26PM -0500, Adam Young wrote:
>>
>> On 1/12/26 11:55, Sudeep Holla wrote:
>>> On Thu, Nov 27, 2025 at 02:40:56PM +0000, Sudeep Holla wrote:
>>>> Hi Jassi,
>>>>
>>>> On Thu, Oct 16, 2025 at 08:08:14PM +0100, Sudeep Holla wrote:
>>>>> This series refines and stabilizes the PCC mailbox driver to improve
>>>>> initialisation order, interrupt handling, and completion signaling.
>>>>>
>>>> Are you happy to pull these patches directly from the list or do you
>>>> prefer me to send you pull request or do you want me to direct this via
>>>> ACPI/Rafael's tree. Please advice.
>>>>
>>> Hi Jassi,
>>>
>>> Sorry for the nag. I did see these patches in -next as well as your
>>> v6.19 merge window pull request which didn't make it to Linus tree.
>>> However I don't see it -next any longer. Please advice if you want
>>> anything from my side so that this can be merged for v6.20/v7.0
>>>
>> I thought you had an approach you wanted to implement for the functions that
>> provided access to the Mailbox internals: you wanted to do them inline but
>> hadn't gotten to them yet. Is that still the case? I will resubmit mine as
>> is with -next if that is acceptable.
>>
> Honestly, it has been a while and I have lost the context. Please post what
> you have or thinking of on top of linux-next or jassi's -next and we can start
> the discussion fresh.
>
On 2/4/26 16:40, Adam Young wrote:
> I was just looking at it. I think reposting might cause too much
> churn, when the crux of the matter is what to do with these three
> functions I added:
>
> extern struct pcc_mbox_chan *
> pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id);
> extern void pcc_mbox_free_channel(struct pcc_mbox_chan *chan);
> extern
> int pcc_mbox_write_to_buffer(struct pcc_mbox_chan *pchan, int len,
> void *data);
> extern
> int pcc_mbox_query_bytes_available(struct pcc_mbox_chan *pchan);
> extern
> int pcc_mbox_read_from_buffer(struct pcc_mbox_chan *pchan, int len,
> void *data);
>
> In my last patch I added them as EXPORT_SYMBOL_GPL. You mentioned you
> wanted them as inline.
>
> We can do that, but it does mean further exposing the ACPI header
> file. THe simplest is pcc_mbox_query_bytes_available which I have
> posted below. As you can see, it needs the struct
> acpi_pcct_ext_pcc_shared_memory which comes from
> include/acpi/actbl2.h. If you are OK with adding that to
> include/acpi/pcc.h We can inline the functions in there.
Actually, I just looked, and the more significant issue is that they
need access to struct pcc_chan_info, which is inside of mailbox/pcc.c,
and thus not available to client code. While we could move this
structure to the header, I think the better approach is what I
originally posted, with the 3 additional functions exported as symbols.
I can resubmit it this way, if you agree.
>
> These three functions are requied as a result of the direct access to
> the shared memory buffer.
>
>
> int pcc_mbox_query_bytes_available(struct pcc_mbox_chan *pchan)
> {
> struct acpi_pcct_ext_pcc_shared_memory pcc_header;
> struct pcc_chan_info *pinfo = pchan->mchan->con_priv;
> int data_len;
> u64 val;
>
> pcc_chan_reg_read(&pinfo->cmd_complete, &val);
> if (val) {
> pr_info("%s Buffer not enabled for reading", __func__);
> return -1;
> }
> memcpy_fromio(&pcc_header, pchan->shmem,
> sizeof(pcc_header));
> data_len = pcc_header.length - sizeof(u32) + sizeof(pcc_header);
> return data_len;
> }
>
>
>
>
> On 1/27/26 04:29, Sudeep Holla wrote:
>> On Mon, Jan 26, 2026 at 12:07:26PM -0500, Adam Young wrote:
>>>
>>> On 1/12/26 11:55, Sudeep Holla wrote:
>>>> On Thu, Nov 27, 2025 at 02:40:56PM +0000, Sudeep Holla wrote:
>>>>> Hi Jassi,
>>>>>
>>>>> On Thu, Oct 16, 2025 at 08:08:14PM +0100, Sudeep Holla wrote:
>>>>>> This series refines and stabilizes the PCC mailbox driver to improve
>>>>>> initialisation order, interrupt handling, and completion signaling.
>>>>>>
>>>>> Are you happy to pull these patches directly from the list or do you
>>>>> prefer me to send you pull request or do you want me to direct
>>>>> this via
>>>>> ACPI/Rafael's tree. Please advice.
>>>>>
>>>> Hi Jassi,
>>>>
>>>> Sorry for the nag. I did see these patches in -next as well as your
>>>> v6.19 merge window pull request which didn't make it to Linus tree.
>>>> However I don't see it -next any longer. Please advice if you want
>>>> anything from my side so that this can be merged for v6.20/v7.0
>>>>
>>> I thought you had an approach you wanted to implement for the
>>> functions that
>>> provided access to the Mailbox internals: you wanted to do them
>>> inline but
>>> hadn't gotten to them yet. Is that still the case? I will resubmit
>>> mine as
>>> is with -next if that is acceptable.
>>>
>> Honestly, it has been a while and I have lost the context. Please
>> post what
>> you have or thinking of on top of linux-next or jassi's -next and we
>> can start
>> the discussion fresh.
>>
On 1/26/26 12:07, Adam Young wrote: > > > On 1/12/26 11:55, Sudeep Holla wrote: >> On Thu, Nov 27, 2025 at 02:40:56PM +0000, Sudeep Holla wrote: >>> Hi Jassi, >>> >>> On Thu, Oct 16, 2025 at 08:08:14PM +0100, Sudeep Holla wrote: >>>> This series refines and stabilizes the PCC mailbox driver to improve >>>> initialisation order, interrupt handling, and completion signaling. >>>> >>> Are you happy to pull these patches directly from the list or do you >>> prefer me to send you pull request or do you want me to direct this via >>> ACPI/Rafael's tree. Please advice. >>> >> Hi Jassi, >> >> Sorry for the nag. I did see these patches in -next as well as your >> v6.19 merge window pull request which didn't make it to Linus tree. >> However I don't see it -next any longer. Please advice if you want >> anything from my side so that this can be merged for v6.20/v7.0 >> > > I thought you had an approach you wanted to implement for the > functions that provided access to the Mailbox internals: you wanted to > do them inline but hadn't gotten to them yet. Is that still the > case? I will resubmit mine as is with -next if that is acceptable. > Apologies, I realize now that this was about the previous set of patches, and not the ones that Sudeep and I were discussing that depend on them.
© 2016 - 2026 Red Hat, Inc.