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
