Message-ID: <aYHmDTboOtkgac00@pluto>
Date: Tue, 3 Feb 2026 12:11:57 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Sudeep Holla <sudeep.holla@...nel.org>
Cc: Andre Przywara <andre.przywara@....com>,
	Debbie Horsfall <debbie.horsfall@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Liviu Dudau <liviu.dudau@....com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] arm64: dts: zena: Add support for Zena CSS

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

Powered by blists - more mailing lists