On Mon, 27 May 2019 05:19:41 +0000
Peng Fan [off-list ref] wrote:

Hi,

quoted

Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox

Hi,

On 5/22/19 10:50 PM, Peng Fan wrote:  

quoted

This is a modified version from Andre Przywara's patch series
 

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
rnel.org%2Fpatchwork%2Fcover%2F812997%2F&data=02%7C01%7Cpe
ng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1d3b
c2b4c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665&sdat
a=BbS5ZQtzMANSwaKRDJ62NKrPrAyaED1%2BvymQaT6Qr8E%3D&rese
rved=0.  

quoted

[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has
been implemented to work with hardware, power domain only supports get
name for now.

The traditional Linux mailbox mechanism uses some kind of dedicated
hardware IP to signal a condition to some other processing unit,
typically a dedicated management processor.
This mailbox feature is used for instance by the SCMI protocol to
signal a request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to  

provide  

quoted

those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.

The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires
a mailbox to actually trigger the action.  

We have had something similar done internally with a couple of minor
differences:

- a SGI is used to send SCMI notifications/delayed replies to support
asynchronism (patches are in the works to actually add that to the Linux SCMI
framework). There is no good support for SGI in the kernel right now so we
hacked up something from the existing SMP code and adding the ability to
register our own IPI handlers (SHAME!). Using a PPI should work and should
allow for using request_irq() AFAICT.  

So you are also implementing a firmware inside ATF for SCMI usecase, right?

Introducing SGI in ATF to notify Linux will introduce complexity, there is
no good framework inside ATF for SCMI, and I use synchronization call for
simplicity for now.

I think we don't disagree, but just to clarify on one thing:

I think we should avoid tying this driver to specific protocol or software on the other end, be it ATF or SCMI. After all it's just a mailbox driver, meant to signal some event (and parameters) to some external entity. Yes, SCMI (or SCPI back then) was the reason to push for this, but it should be independent from that. I am not even sure we should mention it too much in the documentation.

So whether the receiving end is ATF or something else it irrelevant, I think. For instance we have had discussions in Xen to provide guests some virtualised device management support, and using an HVC mailbox seems like a neat solution. This could be using the SCMI (or SCPI) protocol, but that's not a requirement. In this case the Xen hypervisor would be the one to pick up the mailbox trigger, probably forwarding the request to something else (Dom0 in this case).
Also having a generic SMC mailbox could avoid having the actual hardware mailbox drivers in the kernel, so EL3 firmware could forward the request to an external management processor, and Linux would just work, without the need to describe the actual hardware mailbox device in some firmware tables. This might help ACPI on those devices.

Cheers,
Andre.

quoted

- the mailbox identifier is indicated as part of the SMC call such that we can
have multiple SCMI mailboxes serving both standard protocols and
non-standard (in the 0x80 and above) range, also they may have different
throughput (in hindsight, these could simply be different channels)

Your patch series looks both good and useful to me, I would just put a
provision in the binding to support an optional interrupt such that
asynchronism gets reasonably easy to plug in when it is available (and
desirable).  

Ok. Let me think about and add that in new version patch.

Thanks,
Peng.

quoted

quoted

This patch series provides a Linux mailbox compatible service which
uses smc calls to invoke firmware code, for instance taking care of SCMI  

requests.  

quoted

The actual requests are still communicated using the standard SCMI way
of shared memory regions, but a dedicated mailbox hardware IP can be
replaced via this new driver.

This simple driver uses the architected SMC calling convention to
trigger firmware services, also allows for using "HVC" calls to call
into hypervisors or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2
introduces the actual mailbox driver.

Please note that this driver just provides a generic mailbox
mechanism, though this is synchronous and one-way only (triggered by
the OS only, without providing an asynchronous way of triggering
request from the firmware).
And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used
generically where the OS wants to signal a mailbox condition to
firmware or a hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
 

ub.com%2FMrVan%2Farm-trusted-firmware%2Ftree%2Fscmi&data=02
%7C01%7  

quoted

Cpeng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1
d3bc2b4  

quoted

c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665&sdata=kN
9bEFFcsZA  

quoted

1ePeNLLfHmONpVaG6O5ajVQvKMuaBXyk%3D&reserved=0

Peng Fan (2):
  DT: mailbox: add binding doc for the ARM SMC mailbox
  mailbox: introduce ARM SMC based mailbox

 .../devicetree/bindings/mailbox/arm-smc.txt        |  96  

+++++++++++++  

quoted

 drivers/mailbox/Kconfig                            |   7 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/arm-smc-mailbox.c                  | 154  

+++++++++++++++++++++  

quoted

 include/linux/mailbox/arm-smc-mailbox.h            |  10 ++
 5 files changed, 269 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/mailbox/arm-smc.txt
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c  create mode
100644 include/linux/mailbox/arm-smc-mailbox.h
 

--
Florian  

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel