LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Peng Fan <email@example.com> To: "André Przywara" <firstname.lastname@example.org>, "Sudeep Holla" <email@example.com>, "Florian Fainelli" <firstname.lastname@example.org> Cc: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, dl-linux-imx <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox Date: Mon, 27 May 2019 06:29:11 +0000 [thread overview] Message-ID: <AM0PR04MB4481665E2C99DEE66CCB2CA8881D0@AM0PR04MB4481.eurprd04.prod.outlook.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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. > >>>  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  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. > >  Documentation/devicetree/bindings/arm/pmu.yaml:45
next prev parent reply other threads:[~2019-05-27 6:29 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-23 5:50 [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox Peng Fan 2019-05-23 5:50 ` [PATCH 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox Peng Fan 2019-05-23 5:51 ` [PATCH 2/2] mailbox: introduce ARM SMC based mailbox Peng Fan 2019-05-23 17:30 ` [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox Florian Fainelli 2019-05-24 17:56 ` Sudeep Holla 2019-05-26 23:59 ` André Przywara 2019-05-27 6:29 ` Peng Fan [this message] 2019-05-27 6:18 ` Peng Fan 2019-05-27 5:19 ` Peng Fan 2019-05-27 19:11 ` Florian Fainelli 2019-05-30 11:23 ` Andre Przywara 2019-05-31 1:39 ` Peng Fan 2019-06-03 17:24 ` Andre Przywara 2019-05-27 1:55 ` Jassi Brar 2019-05-27 2:06 ` Peng Fan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=AM0PR04MB4481665E2C99DEE66CCB2CA8881D0@AM0PR04MB4481.eurprd04.prod.outlook.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).