[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260130-light-piquant-termite-fcbec4@sudeepholla>
Date: Fri, 30 Jan 2026 12:34:31 +0000
From: Sudeep Holla <sudeep.holla@...nel.org>
To: Andre Przywara <andre.przywara@....com>
Cc: Debbie Horsfall <debbie.horsfall@....com>,
Cristian Marussi <cristian.marussi@....com>,
Rob Herring <robh@...nel.org>,
Sudeep Holla <sudeep.holla@...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
+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 ...
>
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.
--
Regards,
Sudeep
Powered by blists - more mailing lists