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

[Sudeep Holla]

On Tue, Dec 02, 2025 at 05:36:53PM +0100, Marek Vasut wrote:
> On 12/2/25 3:52 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > > 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)
> > > 
> > 
> > Indeed.
> > 
> > > 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)...
> > > 
> > 
> > As you mentioned earlier, no platform has required this before. I’m fine with
> > adding it, but we need to be more explicit about what it implies for SCMI. The
> > transport may be shared with other system components, and enforcing polling
> > for SCMI while the same transport generates interrupts for another user could
> > lead to issues.
> 
> How do you imagine this -- a transport shared with other components, one
> which does generate IRQs and one which does not -- would look like ? Can you
> think of an example ?
> 

Consider a system where a mailbox controller is present and one channel is
used for SCMI communication, while another channel is used for an unrelated
purpose. If both channels share the same interrupt line, and the other use
case enables interrupt mode on its channel, what would be the impact on the
SCMI-specific channel?

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 believe the same applies to OP-TEE.
While OP-TEE now provides a notification mechanism that could, in theory,
allow synchronous commands to be treated in a quasi-asynchronous manner, I
strongly doubt that the current SCMI-over-OP-TEE implementation behaves this
way, given that it ultimately reaches the secure side via an SMC call.

> I don't think a warning is justified, if the behavior follows the
> specification. But I do agree the behavior is ... suboptimal.
> 

The specification does not address SMC or OP-TEE transports, placing them
outside its scope and likewise these DT bindings. Consequently, what we
decide here in this discussion effectively defines the expected behavior in
this context, in my view. So I would like to start with minimal possible
coverage, why do you think that is not a good idea here ?

-- 
Regards,
Sudeep