On 24-03-18, Peng Fan wrote:

quoted

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

On 24-03-18, Peng Fan wrote:

quoted

Hi Marco,

quoted

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:

quoted

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

quoted

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.

quoted

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).

quoted

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.

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel