mbox series

[0/2] firmware: arm_scmi: add notification completion channel

Message ID 20240507-scmi-notify-v1-0-1fdefc984d53@nxp.com (mailing list archive)
Headers show
Series firmware: arm_scmi: add notification completion channel | expand

Message

Peng Fan (OSS) May 7, 2024, 3:34 p.m. UTC
Per spec:
Completion interrupts This transport supports polling or interrupt driven
modes of communication. In interrupt mode, when the callee completes
processing a message, it raises an interrupt to the caller. Hardware
support for completion interrupts is optional.

i.MX95 SCMI firmware is fully interrupt driven, so Platform expects
completion interrupt for Platform to Agent(P2A) notifictions.

Add another optional mailbox channel for Agent to notify Platform that
notification message has been accepted

After notification channel status become freed, Agent will use the
new mailbox channel to send completion interrupt to Platform.

Add shmem_channel_intr_enabled to check channel flags.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (2):
      dt-bindings: firmware: arm,scmi: Support notification completion channel
      firmware: arm_scmi: mailbox: support P2A channel completion

 .../devicetree/bindings/firmware/arm,scmi.yaml     | 12 +++--
 drivers/firmware/arm_scmi/common.h                 |  1 +
 drivers/firmware/arm_scmi/mailbox.c                | 51 +++++++++++++++++++---
 drivers/firmware/arm_scmi/shmem.c                  |  5 +++
 4 files changed, 59 insertions(+), 10 deletions(-)
---
base-commit: 9221b2819b8a4196eecf5476d66201be60fbcf29
change-id: 20240507-scmi-notify-07e87a8b9a23

Best regards,

Comments

Cristian Marussi May 8, 2024, 5:04 p.m. UTC | #1
On Tue, May 07, 2024 at 11:34:59PM +0800, Peng Fan (OSS) wrote:
> Per spec:

Hi Peng,

thanks for doing this.

> Completion interrupts This transport supports polling or interrupt driven
> modes of communication. In interrupt mode, when the callee completes
> processing a message, it raises an interrupt to the caller. Hardware
> support for completion interrupts is optional.
> 
> i.MX95 SCMI firmware is fully interrupt driven, so Platform expects
> completion interrupt for Platform to Agent(P2A) notifictions.
> 
> Add another optional mailbox channel for Agent to notify Platform that
> notification message has been accepted
> 
> After notification channel status become freed, Agent will use the
> new mailbox channel to send completion interrupt to Platform.
> 
> Add shmem_channel_intr_enabled to check channel flags.

Glancing through the series I think the bindings and the code are
quite good and sensible to achieve the addition of the optional P2A 
completion interrupt.

Your current solution, though, addresses only the case of a mailbox
controller providing unidirectional channels. (which I suppose is the
one you are using on your platform)

We should take care to add such optional P2A completion interrupt support
also for the case of mailboxes sporting bidirectional channels.

For bidirectional channels we really have already the needed bindings...
...no changes there...you have just to also ring the doorbell on that same P2A
if completion IRQs are requested.

IOW, when the DT description is made by 2 mboxes + 2 shmem, means we have
both A2P and P2A provided via bidirectional channels...we currently
just use the P2A (RX) channel to receive notifs/dresp via rx_callback
(so using only the platform_to_agent direction)...now we should also ring
the P2A doorbell on the existing P2A channel if the FLAG_INTR_ENABLED is set
to signal the completion interrupt on the other direction (agent_to_platform)

Not sure if I have been clear or make it worst with my explanation :P

Thanks,
Cristian
Peng Fan May 9, 2024, 3:38 a.m. UTC | #2
Hi Cristian,

> Subject: Re: [PATCH 0/2] firmware: arm_scmi: add notification completion
> channel
> 
> On Tue, May 07, 2024 at 11:34:59PM +0800, Peng Fan (OSS) wrote:
> > Per spec:
> 
> Hi Peng,
> 
> thanks for doing this.
> 
> > Completion interrupts This transport supports polling or interrupt
> > driven modes of communication. In interrupt mode, when the callee
> > completes processing a message, it raises an interrupt to the caller.
> > Hardware support for completion interrupts is optional.
> >
> > i.MX95 SCMI firmware is fully interrupt driven, so Platform expects
> > completion interrupt for Platform to Agent(P2A) notifictions.
> >
> > Add another optional mailbox channel for Agent to notify Platform that
> > notification message has been accepted
> >
> > After notification channel status become freed, Agent will use the new
> > mailbox channel to send completion interrupt to Platform.
> >
> > Add shmem_channel_intr_enabled to check channel flags.
> 
> Glancing through the series I think the bindings and the code are quite good
> and sensible to achieve the addition of the optional P2A completion interrupt.
> 
> Your current solution, though, addresses only the case of a mailbox controller
> providing unidirectional channels. (which I suppose is the one you are using
> on your platform)

Right. i.MX95 use unidirectional channels.

> 
> We should take care to add such optional P2A completion interrupt support
> also for the case of mailboxes sporting bidirectional channels.
> 
> For bidirectional channels we really have already the needed bindings...
> ...no changes there...you have just to also ring the doorbell on that same P2A
> if completion IRQs are requested.
> 
> IOW, when the DT description is made by 2 mboxes + 2 shmem, means we
> have both A2P and P2A provided via bidirectional channels...we currently just
> use the P2A (RX) channel to receive notifs/dresp via rx_callback (so using only
> the platform_to_agent direction)...now we should also ring the P2A doorbell
> on the existing P2A channel if the FLAG_INTR_ENABLED is set to signal the
> completion interrupt on the other direction (agent_to_platform)
> 
> Not sure if I have been clear or make it worst with my explanation :P

Thanks for detailed explanation, it is clear enough. I will update to support
bidirectional channel in V2.

Thanks,
Peng.
> 
> Thanks,
> Cristian