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

[Peng Fan]

Hi Andre,

> Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
> 
> On 24/05/2019 18:56, Sudeep Holla wrote:
> > On Thu, May 23, 2019 at 10:30:50AM -0700, Florian Fainelli wrote:
> 
> 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%2Flore.ke
> rnel.org%2Fpatchwork%2Fcover%2F812997%2F&data=02%7C01%7Cpe
> ng.fan%40nxp.com%7C02ee9487370c4eb9158008d6e2363ca0%7C686ea1d3
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636945119959534576&sda
> ta=U8FzX3FX2PoEZhRuRMhFbkaAnb3cqjZsb9%2FTdt8OfuY%3D&reserve
> d=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.
> >>
> >
> > We have been thinking this since we were asked if SMC can be transport.
> > Generally out of 16 SGIs, 8 are reserved for secure side and
> > non-secure has 8. Of these 8, IIUC 7 is already being used by kernel.
> > So unless we manage to get the last one reserved exclusive to SCMI, it
> > makes it difficult to add SGI support in SCMI.
> >
> > We have been telling partners/vendors about this limitation if they
> > use SMC as transport and need to have dedicated h/w interrupt for the
> > notifications.
> >
> > Another issue could be with virtualisation(using HVC) and EL handling
> > so called SCMI SGI. We need to think about those too. I will try to
> > get more info on this and come back on this.
> 
> I think regardless of the *current* feasibility of using SGIs in *Linux* we
> should at least specify an "interrupts" property in the binding, to allow for
> future usage. We might copy the pmuv3 way [1] of allowing to specify
> multiple SPI interrupts as well, to give more flexibility.

This needs to go with an optional property, agree?
That means smc mailbox needs to support synchronous and asynchronous
communication. I'll try to add that and write some porotype code to
verify.

Thanks,
Peng.

> After all an implementation could offload the asynchronous notification to a
> separate core, and that could use SPIs, for instance.
> 
> Cheers,
> Andre.
> 
> [1] Documentation/devicetree/bindings/arm/pmu.yaml:45