Messages in this thread | | | Date | Tue, 28 Jan 2020 11:38:21 +0000 | From | Sudeep Holla <> | Subject | Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox |
| |
On Mon, Jan 27, 2020 at 12:58:12PM +0000, Peng Fan wrote: > > Subject: Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox > > > > Hello Peng and all, > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > This mailbox driver implements a mailbox which signals transmitted > > > data via an ARM smc (secure monitor call) instruction. The mailbox > > > receiver is implemented in firmware and can synchronously return data > > > when it returns execution to the non-secure world again. > > > An asynchronous receive path is not implemented. > > > This allows the usage of a mailbox to trigger firmware actions on SoCs > > > which either don't have a separate management processor or on which > > > such a core is not available. A user of this mailbox could be the SCP > > > interface. > > >
[...]
> > I've successfully tested your change on my board. It is a stm32mp1 with TZ > > secure hardening and I run an OP-TEE firmware (possibly a TF-A > > sp_min) with a SCMI server for clock and reset. Upstream in progress. > > The platform uses 2 instances of your SMC based mailbox device driver > > (2 mailboxes). Works nice with your change. > > > > You can add my T-b tag: Tested-by: Etienne Carriere > > <etienne.carriere@linaro.org> > > Thanks, but this patch has been dropped. > > Per Sudeep, we all use smc transport, not smc mailbox , > Yes, I asked if there are any other users of SMC mailbox other than SCMI. We are planning to separate the transport from the SCMI driver[1] to enable transport other than mailbox. SMC can be one of them and the other one planned is virtio. Please feel free to add to the discussion or review.
-- Regards, Sudeep
[1] https://lore.kernel.org/lkml/f170b33989b426ac095952634fcd1bf45b86a7a3.1580208329.git.viresh.kumar@linaro.org
| |