Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

Lucas Stach
2020-02-13T14:47:43Z

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@kontron.de>
> > > > Sent: Thursday, February 13, 2020 5:16 PM
> > > > To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> > > > <sudeep.holla@arm.com>
> > > > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> > > > Fan <peng.fan@nxp.com>; Souvik Chakravarty
> > > > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> > > > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> > > > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> > > > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> > > > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> > > > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> > > > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> > > > 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@arm.com>
> > > > 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