[PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Thu, Dec 04, 2025 at 07:59:20PM +0100, Marek Vasut wrote:
> On 12/4/25 1:33 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > Wouldn't such a setup use separate mailbox channels, therefore even if
> > > mailbox driver calls mbox_chan_received_data(), it would be called for a
> > > specific mailbox channel , and it won't interfere with the SCMI mailbox
> > > channel.
> > > 
> > 
> > Ideally yes. Because PCC uses shared interrupts and provides no mechanism to
> > identify the channel that raised the interrupt, we must run the handler for
> > every registered channel. This behaviour is specific to PCC; other controllers
> > that support interrupt source detection may not need to do this. But SCMI
> > must work with any mailbox or other transports.
> 
> It seems the pcc_mbox_irq() operates per-channel, so it seems even the PCC
> can demux channels for each IRQ and does trigger mbox_chan_received_data()
> for correct channel ?
> 
> What exactly happens on the PCC mailbox driver with this polling mode
> enabled ?
> 
> > > > Also IIUC, the irq request happens
> > > > as part of channel startup and there are no explicit APIs for the mbox client
> > > > driver to control that. SCMI is mbox client in this case.
> > > 
> > > Sure, but the mailbox driver has to make sure it is correctly demuxing the
> > > IRQs it handles and correctly sends received_data notifications to the right
> > > channel(s) .
> > > 
> > 
> > Agreed, but the concern is that if SCMI is forced to use polling when the
> > channel is opened, and IRQs are enabled by default with no way for SCMI to
> > disable them in polling mode, we could run into issues.
> 
> This constellation seems odd -- if the channel can do IRQs, then this
> property should not be present in DT.
> 

Yes, but there is no way to validate or check this and that is the root
cause for all my worries.

> > I realise it’s a very
> > specific corner case, but every time I’ve assumed such scenarios wouldn’t
> > occur, we eventually ended up encountering them. So sorry if I am very
> > pedantic, but I prefer to start smaller and restrictive and expand if and
> > when necessary or required only.
> 
> I don't think this case, where mailbox channel does IRQs and polling is
> enabled, can/should even be considered valid. Either the channel does not do
> IRQs and then it should do polling, or it does IRQs and then it should use
> IRQs, but not both.
> 

Yes ideally, but having loose ends like this binding which allows someone
to add it to their DT complicates though it is invalid. We have no way to
detect and I don't want to work around such configs in the future.

> > > > > > I am aware of systems that implement such sharing, which is why I prefer to be
> > > > > > explicit that this type of design is challenging to support within this
> > > > > > binding. The intent is to support only minimal, constrained cases - essentially
> > > > > > systems that are already somewhat broken. I do not see value in broadening the
> > > > > > binding to cover every conceivable scenario.
> > > > > > 
> > > > > > > > Clearly defining these constraints would be helpful. It may also be useful to
> > > > > > > > note that this is primarily intended for mailbox transports, if that’s
> > > > > > > > accurate. Alternatively, we could keep the DT binding definition broader but
> > > > > > > > emit warnings when a transport other than mailbox is used. That approach might
> > > > > > > > make it easier to move forward.
> > > > > > > 
> > > > > > > DEN0056F refers to this polling mode in Shared memory based transports, that
> > > > > > > can be other than mailbox transports, it includes e.g. SMC or OPTEE
> > > > > > > transports.
> > > > > > > 
> > > > > > 
> > > > > > However, polling does not make sense in the context of SMC. Once control
> > > > > > returns from an SMC call, the command has completed. What form of polling in
> > > > > > an SMC workflow do you have in mind?
> > > > > 
> > > > > I think the polling happens on the SHMEM and the SMC transport is capable of
> > > > > that too, see :
> > > > > 
> > > > > drivers/firmware/arm_scmi/transports/smc.c
> > > > > 
> > > > > 175         /*
> > > > > 176          * If there is an interrupt named "a2p", then the service and
> > > > > 177          * completion of a message is signaled by an interrupt rather
> > > > > than by
> > > > > 178          * the return of the SMC call.
> > > > > 179          */
> > > > > 180         scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");
> > > > > 
> > > > 
> > > > Ah this one, is actually implemented to avoid sort of implicit polling
> > > > mode we get with any SMC/HVC. I don't know how the platform deals with it
> > > > but SMC/HVC is synchronous and doesn't need this polling. The irq introduced
> > > > here is again a sort of workaround to get some sort of async/non-polling
> > > > mode with SMC/HVC. So, to repeat polling mode make absolutely no sense
> > > > whatsoever for SMC/OPTEE(based on pure SMC) transports.
> > > 
> > > I can drop the SMC part from this patch if you think that's helpful ?
> > > 
> > 
> > Yes, that’s essential, because polling in an SMC context is meaningless in my
> > opinion.
> 
> Maybe the "a2p" IRQ is also used for notifications from longer running
> operations ?
> 

Yes, it is some sort of work around some platforms implemented as by design
when the SMC returns, the synchronous commands must complete and it is had
to support async SCMI commands without platform specific interrupt(p2a). This
a2p is sort of completion interrupt for synchronous command. I assume the
platform may offload the task from secure f/w to something else otherwise
secure side needs to be given CPU cycles to complete which complicates this.
In short SMC is synchronous and if the execution returns from it in NS world,
the command is complete.

> [...]
> 
> > > > Yes it can be minimalistic but not restrictive. As I already clearly mentioned
> > > > I don't see it makes any sense to enable this for SMC/OPTEE. Lets start with
> > > > just mailbox to start with and extend to other transports if and when needed.
> > > > It would be good to impose that restriction in the binding as well but that
> > > > is not a must IMO. I am fine if the bindings for whatever reasons(though I
> > > > don't see the need) to apply for any transport.
> > > So I should simply drop the smc.c changes , keep the rest, and send V2 ?
> > 
> > Not just that. Unless DT maintainers oppose, I just want to keep this
> > new property valid only for mailbox transport(i.e. "arm,scmi" compatible
> > not otherwise) so that we can catch any other use in binding checks and
> > interested parties must discuss on the list and expand that if they require.
> > 
> > Also we can explore if we can parse and scan this in mailbox transport for
> > now.
> I feel that this only adds more implementation complexity and makes the
> solution less generic, while it does win us very little in the end ? The
> generic solution implementation is actually easier to implement.

Yes I want it less generic to start with. Why you want to start making
this workaround on your platform a generic implementation just because
the specification has provision for it ?

-- 
Regards,
Sudeep