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

[Marek Vasut]

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.

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

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