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

[Marek Vasut]

On 11/13/25 12:03 PM, Cristian Marussi wrote:

Hello Cristian,

> bit of a late reply...

No worries, I am buried under email myself, take your time.

>>>> On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
>>>>> Document new property arm,poll-transport, which sets all SCMI
>>>>> operation into
>>>>> poll mode. This is meant to work around uncooperative SCP
>>>>> implementations,
>>>>> which do not generate completion interrupts. This applies
>>>>> primarily on mbox
>>>>> based implementations, but does also cover SMC and VirtIO ones.
>>>>
>>>> Hi,
>>>>
>>>> ..indeed I was thinking a while ago about exposing the existing
>>>> force- polling
>>>> switch but in my case it was purely a testing-scenario
>>>> configuration, so a
>>>> no-no for the DT, things are different if you have to describe an HW
>>>> that has
>>>> no completion IRQ also on the a2p channel...
>>>
>>> Correct, at least until the SCP on this hardware is updated.
>>>
>>>> ...having said that, though, usually polling-mode is reserved to a few
>>>> selected commands in a few chosen scenarios (as you may have seen),
>>>> 'carpet-polling' non-for-testing for all the commands on A2P seems a lot
>>>> inefficient and heavy...is it really a viable solution ? or these
>>>> systems use such a low rate of SCMI messages that polling after each and
>>>> every message is negligible ?
>>>>
>>>> ..just to understand the context...
>>>
>>> These systems are early in development and it is likely that the SCP
>>> will be updated to generate interrupts properly. Currently, this is not
>>> the case, hence the carpet-polling, until this is resolved.
>>
>> While I was going through the SCMI spec, DEN0056F , page 209 , section "4.1
>> Shared memory based transport" , bullet • Completion interrupts, I found it
>> explicitly states:
>>
>> "
>> 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.
>> "
> 
> Oh, yes...I knew that...it is just that till now, no systems were really
> ever developed that lacked the completion IRQ as a whole, it was, till now,
> more of a case of having the capability NOT to use it selectively at runtime
> and instead use polling when wanted (like for clock ops in ISR context)
> 
> I am not sure what is the reason why this only-polling scenario was never
> supported in the HW description, this indeed pre-dates my work on SCMI....
> ...I would/will check with Sudeep, when he's back, what are the reasons for
> this (if any)...

Thank you !

-- 
Best regards,
Marek Vasut