[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM2PR0201MB07676A546340135791F9F25EB8D20@DM2PR0201MB0767.namprd02.prod.outlook.com>
Date: Tue, 13 Mar 2018 18:56:38 +0000
From: Jolly Shah <JOLLYS@...inx.com>
To: Sudeep Holla <sudeep.holla@....com>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"matt@...eblueprint.co.uk" <matt@...eblueprint.co.uk>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"michal.simek@...inx.com" <michal.simek@...inx.com>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
"mingo@...nel.org" <mingo@...nel.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>,
Rajan Vaja <RAJANV@...inx.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH v5 1/4] dt-bindings: firmware: Add bindings for ZynqMP
firmware
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla@....com]
> Sent: Tuesday, March 13, 2018 3:16 AM
> To: Jolly Shah <JOLLYS@...inx.com>
> Cc: Sudeep Holla <sudeep.holla@....com>; gregkh@...uxfoundation.org;
> matt@...eblueprint.co.uk; hkallweit1@...il.com; michal.simek@...inx.com;
> robh+dt@...nel.org; mark.rutland@....com; ard.biesheuvel@...aro.org;
> mingo@...nel.org; keescook@...omium.org; dmitry.torokhov@...il.com;
> Rajan Vaja <RAJANV@...inx.com>; linux-arm-kernel@...ts.infradead.org; linux-
> kernel@...r.kernel.org; devicetree@...r.kernel.org
> Subject: Re: [PATCH v5 1/4] dt-bindings: firmware: Add bindings for ZynqMP
> firmware
>
>
>
> On 12/03/18 23:07, Jolly Shah wrote:
> > Hi Sudeep,
>
> >>>> Do you foresee using SMC/HVC for this firmware even on future
> platforms?
> >>>> If not, I suggest to keep the protocol part separate from the transport i.e.
> >>>> smc/hvc via ATF. It could be replaced with mailbox or some h/w
> >>>> mechanism in future ?
> >>>>
> >>>
> >>> We have PSCI and EEMI interfaces exposed to linux from ATF. PSCI is
> >>> an EEMI client. We do not have current plans to switch to mailbox as
> >>> it will require 2 communication channels to PMU as PSCI is through ATF.
> >>>
> >>
> >> OK, but I just saw some bindings that has mailbox interface, honestly
> >> it's getting too confusing with multiple series on the same thing
> >> floating and hence I requested to put it together as one series.
> >
> > Mailbox binding is used for power management driver. Mailbox is only
> > used for PMU->APU communication. APU->PMU communication is always
> > through EEMI firmware interface which is using SMC/HVC.
> >
>
> Ah OK, is it because there's no non-secure mailbox or to avoid races, all non-
> secure EEMI is channeled through SMC ?
>
2 reasons:
1> Avoid multiple EEMI communication channels as PSCI is through ATF.
2> We have some secure operations handled in ATF because of memory constraints on PMU
> --
> Regards,
> Sudeep
Powered by blists - more mailing lists