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. 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. -- Regards, Leonard
