On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote: > On 13.02.2020 13:32, Lucas Stach wrote: > > On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote: > > > > -----Original Message----- > > > > From: Schrempf Frieder <frieder.schrempf@xxxxxxxxxx> > > > > Sent: Thursday, February 13, 2020 5:16 PM > > > > To: Adam Ford <aford173@xxxxxxxxx>; Sudeep Holla > > > > <sudeep.holla@xxxxxxx> > > > > Cc: Aisheng Dong <aisheng.dong@xxxxxxx>; mark.rutland@xxxxxxx; Peng > > > > Fan <peng.fan@xxxxxxx>; Souvik Chakravarty > > > > <Souvik.Chakravarty@xxxxxxx>; Jacky Bai <ping.bai@xxxxxxx>; > > > > devicetree@xxxxxxxxxxxxxxx; Clément Faure <clement.faure@xxxxxxx>; > > > > s.hauer@xxxxxxxxxxxxxx; shawnguo@xxxxxxxxxx; robh+dt@xxxxxxxxxx; > > > > dl-linux-imx <linux-imx@xxxxxxx>; kernel@xxxxxxxxxxxxxx; Andre Przywara > > > > <andre.przywara@xxxxxxx>; Silvano Di Ninno <silvano.dininno@xxxxxxx>; > > > > Leonard Crestez <leonard.crestez@xxxxxxx>; festevam@xxxxxxxxx; > > > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Lucas Stach <l.stach@xxxxxxxxxxxxxx> > > > > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family > > > > > > > > Hi, > > > > > > > > On 07.11.19 22:28, Adam Ford wrote: > > > > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@xxxxxxx> > > > > wrote: > > > > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: > > > > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote: > > > > > > > > > > I don't yet buy the security argument. There are many more shared > > > > > > > > > > parts on the SoC, like the clock controller, that would need to > > > > > > > > > > be taken away from the non-secure world if one would want to run > > > > > > > > > > an untrusted OS kernel on a i.MX8M system. > > > > > > > > > > > > > > > > > > > > To properly implement security on any i.MX8M based system the > > > > > > > > > > firmware would need to grow something like a full ARM SCPI > > > > > > > > > > implementation, so all shared critical peripherals are solely under > > > > firmware control. > > > > > > > > > It might be possible to rework this to use some form of > > > > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls > > > > > > > > > > I was just curious to know if there is any progress being made on > > > > > this. The i.mx8mm-evk is missing functionality upstream and I think > > > > > the power domain support would help enable some of these features. > > > > > > > > > > > > > Has there been any decision or action taken in this topic? > > > > Will the power domain driver as proposed in this patch be upstreamed at > > > > some time, or rather not? > > > > > > > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) > > > > and I integrated display and graphics support from the downstream NXP > > > > kernel. > > > > > > > > While most things already work fine, there's the issue of how to handle the > > > > power domains. Currently I need to ungate some clocks in the TF-A > > > > BL31 to get for example the GPU running. If I understand this correctly the > > > > proposed power domain driver could handle this in Linux otherwise. > > > > > > > > > > the SCMI over SMC is still under review > > > > Even if the SCMI over SMC is ready at some point, it's still unclear to > > me how you intend to abstract the GPC behind the SCMI interface in the > > TF-A. The power domains have dependencies both into the regulator and > > the clock framework. Both are currently under exclusive control of the > > rich OS. How do you intend to allow the TF-A to control the power > > supplies and necessary reset clocks without messing up any state in the > > rich OS? > > This is indeed difficult, SCMI assumes that the responder has sufficient > control over clocks to fully implement power domain handling, including > over clocks and regulators. > > Perhaps it might be possible to modify current gpcv2 driver to send SCMI > messages for power only and keep handling regulators itself? It could > switch based on whether it has a reference to a scmi channel as a DT > property. With such a split implementation I feel like we are getting worst of both worlds: more complexity as the implementation is split across multiple components (TF-A and kernel) and still the rich OS is able to mess up the power supply of a domain that it might not even own. This doesn't sound really enticing. IMHO it only makes sense to push this functionality down into TF-A if it allows to abstract all the implementation details behind a standard interface like SCMI. But then the needed changes are much more invasive than just pushing down the GPC implementation. > A full scmi-based implementation might use entirely very different > bindings and take a long time. If people want to support their chips by > implementing power domain support in the rich OS we shouldn't block them. > > So it would be good to accept gpcv2 enhancement for 8mm and similar. I fully agree. For a full SCMI based implementation I expect that much more than just the GPC functionality needs to be pushed down into the TF-A. Right now I see clocks, i2c and regulator handling, maybe there is more that escapes my mind. We should not block a Linux based implementation of this functionality on the basis that we might want to replace this with a SCMI based one at a later point in time. Regards, Lucas
