On 13.02.2020 16:47, Lucas Stach wrote: > 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. I2C regulator handling inside TF-A sounds very difficult. Not only would upstream TF-A likely object but on imx8m EVK boards the i2c bus for regulators is shared with other devices (like camera). So if we do this maybe SCMI dt bindings could be expanded to at least allow regulators on a per-domain basis? > 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.
