Re: [PATCH 2/2] arm64: dts: zena: Add support for Zena CSS

[Debbie Horsfall <debbie.horsfall@arm.com>]

On 03/02/2026 12:11, Cristian Marussi wrote:
> On Fri, Jan 30, 2026 at 12:34:31PM +0000, Sudeep Holla wrote:
>>
>> +Cristian(in case I am talking no sense)
>>
>> On Fri, Jan 30, 2026 at 11:31:25AM +0100, Andre Przywara wrote:
>>>
>>> So do you need just one "tx", but "rx" plus "rx_reply"? Which isn't valid in
>>> the current binding?
>>> If that's the case, then we would need a patch to relax the binding and
>>> allowing this combination as well.
>>> Looking into the kernel code it looks like the SCMI driver doesn't use
>>> mbox-names, but explicitly expects assignments depending on the number of
>>> mboxes? Somewhat confusing ...
> 
> Hi,
> 
> so the mbox-names are NOT mandatory, since the SCMI stack initially did
> NOT identify mboxes by names and such decision pre-dates me so I am not
> sure about the why...
> 
> ...anyway, when unidirectional mailboxes hw came along, in order to add
> clarity, WHILE maintaining backward compatibility, mbox-names were added
> only as optional and the stack really does NOT use them; the only thing
> that matters is the number and order of mboxes AND shmem areas: only the
> combination described in the mboxes binding description are allowed and
> accepted in order to manage both the case of unidirectional and
> bidirectional mailboxes while surviving backward compatibility.
> 
>>>
>>
>> It is generally transmitted via tx, and tx_reply is necessary when the
>> platform has unidirectional channels. tx_reply is used to determine when the
>> synchronization commands have completed, without requiring polling of the
>> shared memory. rx_reply is necessary only if the platform firmware expects
>> it and doesn't poll the shared memory for OSPM/agent acknowledgement.
> 
> In SCMI you have generally A2P (Agent-to-Platform) bidirectional channels
> to send commands and receive related replies using one dedicated shmem and,
> optionally, a distinct dedicated unidirectional channel P2A, with a
> distinct dedicated shmem, for receiving notifications and/or delayed
> responses sent asynchronously by the platform.
> 
> These two channels, A2P and P2A, maps in the SCMI stack (for historical
> reasons) respectively to TX and RX naming.
> 
> If the underlying transport is based on birectional mailboxes you can
> happily have 2 mboxes "tx", "rx" with 2 dedicated mbox areas.
> 
> Instead if your mailboxes are unidirectional like MHUv3, you will need
> effectively 2 mboxes to represent the 2 parts of the A2P birectional
> channel AND one mailbox to represent the P2A unidirectional channel,
> exactly like you do.
> 
> So, if you want to add the optional mbox-names would be:
> 
> 	firmware {
> 	    scmi {
> 	         compatible = "arm,scmi";
> 		 mbox-names = "tx", "tx_reply", "rx";
> 		 mboxes = <&mbox_db_tx 0 0 0 &mbox_db_rx 0 0 0 &mbox_db_rx 0 0 2>
>                   shmem = <&scmi_shmem_tx &scmi_shmem_rx>;
> 
> 
> ...since the first 2 mboxes effectively represents the 2 unidirectional
> sides of the A2P channel, with first being the cmd-request direction and
> the second being the cmd-reply direction, while the third mbox is just the
> P2A unidrectional channel...
> 
> ....so it is fine, even though admittedly fuorviating, that the tx_reply
> is attached to a db_rx block, since it is exactly what represents: the
> reply to a previously sent command.
> 
> Anyway, being the names optional, the only thing that really matters in all
> of the above is that the numbers of mboxes and shmems matches:
> 
> 	 3 mbox / 2 shmem => SCMI TX and RX over 3 mailbox unidirectional channels
> 
> The additional optional rx_reply mboxes was added to represent P2A
> channels that have an completion interrupt.
> 
> All of this madness was the best way I could find to address the problem
> of supporting such new unidirectional mailboxes in the SCMI while NOT
> breaking backward compatibility in the absence of mandatory naming from
> the start.
> 
> Hope to have shed a light, beside having annoyed you all with all of the
> above flood of words :P
> 
> Thanks,
> Cristian
> 

Hi Cristian,

Thanks very much for the detailed explanation, all makes sense. I will 
add those mbox-names in accordance.

-- 

Kind regards,
Debbie