Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock features

[Marco Felsch]

On 24-03-18, Peng Fan wrote:
> > Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> > features
> > 
> > On 24-03-18, Peng Fan wrote:
> > > Hi Marco,
> > >
> > > > Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> > > > features
> > > >
> > > > Hi Peng,
> > > >
> > > > thank for the patchset.
> > > >
> > > > On 24-03-14, Peng Fan (OSS) wrote:
> > > > > i.MX95's several MIXes has BLK CTL module which could be used for
> > > > > clk settings, QoS settings, Misc settings for a MIX. This patchset
> > > > > is to add the clk feature support, including dt-bindings
> > > >
> > > > I have to ask since there is almost no public documentation
> > > > available yet. The
> > > > i.MX95 does have an system-controller for managing pinmux settings
> > > > and power-domains, right?
> > >
> > > Yes.
> > >
> > > If this is the case, why not making use of it via the
> > > > standard scmi_pm_domain.c driver?
> > >
> > > The SCMI firmware not handle the BLK CTL stuff, but blk ctl stuff is a
> > > mix of clk, qos, module specific things. It is not good for SCMI
> > > firmare to handle it.
> > 
> > Currently most of the blk-ctrl users do use the blk-ctrl as power-domain
> > consumer, except for the isi and the audio part. 
> 
> Yes, for i.MX8M.
> 
> > So as I said above the
> > scmi_pm_domain.c should be able to supply this. The audio blk-ctrl could be
> > abstracted via the clk-scmi.c driver. The ISI is another topic.
> 
> Pengutronix rejected the efforts for putting blk ctrl stuff in ATF for i.MX8M
> before. So we take the kernel power domain approach to handle blk ctrl
> clk gating.

AFAIK the problem here was that your proposal had an layering violation
even worse it was an layering inversion since the TF-A (lower layer)
code updated CCM registers which were under control of Linux (upper
layer).

> > What you're are going to do here is to put pinctrl etc into SCMI firmware and
> > power-control into Linux, which sound to me like an 50/50 approach and
> > IMHO is rather sub-optimal. 
> 
> Now back to i.MX95 which supports function safety.
> 
> The SCMI firmware only handle CCM/SRC/GPC for clock/power, it not
> handle blk ctrl.

I know that.

> The BLK CTRL registers are not only for clk gating, it has other
> module specific functions.

I suspected that this is the case for i.MX95 too :/

> Moving BLK CTRL to SCMI firmware, means linux accessing module
> specific functions needs go through vendor SCMI protocol.

Right and here it's a bit complicated to have an proper interface.
Therefore I'm not again the solution of keeping the blk-ctrl within
Linux.

> And BLK CTRL stuff is MIX level stuff, it is not SOC level stuff as
> CCM which is system critical resource.

Hm.. it's still SoC level albeit the area is more limited to specific
functions like HSIO, MEDIA, GPU, ...

> (BLK CTLR, I mean non system critical BLK CTRL, such as GPU,VPU,DISP)

What's system critical is up to the system design but I get your point
that having an safe DISP stack is not going to happen.

> The other approach is to let ATF as SCMI server to handle BLK CTRL stuff,
> But I not see benefits.

How is that any different from putting it into the system-controller
firmware.

> > To quote your online available fact sheet:
> > 
> > 8<----------------------------------------------------------
> > ENERGY FLEX ARCHITECTURE
> > 
> > The i,MX 95 family is designed to be configurable and scalable, with multiple
> > heterogenous processing domains.
> > This includes an application domain with up to 6 Arm Cortex A55 cores, a
> > high-performance real-time domain with Arm Cortex M7, and low-
> > power/safety domain with Arm Cortex M33, each able to access interfaces
> > including CAN-FD, 10GbE networking, PCIe Gen 3 x1 interfaces, and
> > accelerators such as V2X, ISP, and VPU.
> > 8<----------------------------------------------------------
> > 
> > 8<----------------------------------------------------------
> > HIGH-PERFORMANCE COMPUTE
> > The i.MX 95 family capabilities include a multi-core application domain with
> > up to six Arm Cortex(r)-A55 cores, as well as two independent real-time
> > domains for safety/low-power, and high-performance real-time use,
> > consisting of high-performance Arm Cortex-M7 and Arm Cortex-M33 CPUs,
> > combining low-power, real-time, and high-performance processing. The i.MX
> > 95 family is designed to enable ISO 26262 ASIL-B and SIL-2 IEC 61508
> > compliant platforms, with the safety domain serving as a critical capability for
> > many automotive and industrial applications.
> > ...
> > 8<----------------------------------------------------------
> > 
> > To me this sound like we can turn of the power/clock of an hardware block
> > which was assigned to a core running SIL-2 certified software from an non-
> > critical core running Linux if we follow that approach. Also the
> > SIL-2 software requires the non-critical software to turn on the power of these
> > hardware blocks. Is this correct?
> 
> Non-critical software not able to turn off power/clock of a critical resource in
> safety software domain.
> Safety software not require non-safety software to turn on power/clocks.

Due to lack of documentation I don't know how you implemented this in
HW/SW, also the system-design is telling us which parts should be seen
as safe and which don't. However I get your point, VPUMIX is not going
to be a part of the safe partition albeit it "could" due to complexity.

> CCM/SRC/GPC is handled by SCMI firmware, agent w/o safety needs use
> SCMI API to request SCMI firmware to enable clock/power for a module.
> The SCMI firmware will check whether the agent is allowed to touch
> a clock entry or a power entry.

I got this. I still don't like the 50/50 approach but I also get your
point about the GPR registers which is the only valid argument to me of
not putting the blk-ctrl handling into the system-controller firmware.

Regards,
  Marco