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

[Cristian Marussi]

On Thu, Oct 30, 2025 at 01:52:42AM +0100, Marek Vasut wrote:
> On 10/23/25 4:00 PM, Marek Vasut wrote:
> 
> Hello again,
> 

Hi,

bit of a late reply...

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

Thanks,
Cristian