> > > > Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered > > > mailbox > > > > > > Hi, > > > > > > On 5/22/19 10:50 PM, Peng Fan wrote: > > > > This is a modified version from Andre Przywara's patch series > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo > > > re.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. > > > > [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 > > > > 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. Thanks, I agree. > I am not even sure we should mention it too much in the documentation. I think we need a usecase here, so it should be fine. > > 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). I do not get the point "forwarding the request", DomU HVC will trap to Xen, so how to forward to Dom0? Thanks, Peng. > 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. > > > > > > > - 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. > > > > > > > > > > > > > This patch series provides a Linux mailbox compatible service > > > > which uses smc calls to invoke firmware code, for instance taking > > > > care of SCMI > > > requests. > > > > 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%2F > > > > gith > > > > > > > > ub.com%2FMrVan%2Farm-trusted-firmware%2Ftree%2Fscmi&data=02 > > > %7C01%7 > > > > > > > > Cpeng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1 > > > d3bc2b4 > > > > > > > > c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665&sdata=kN > > > 9bEFFcsZA > > > > 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 > > > +++++++++++++ > > > > drivers/mailbox/Kconfig | 7 + > > > > drivers/mailbox/Makefile | 2 + > > > > drivers/mailbox/arm-smc-mailbox.c | 154 > > > +++++++++++++++++++++ > > > > 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
