Re: Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks)

On 01/07/17 19:14, Uwe Kleine-König wrote:

Hello,

On Sat, Jul 01, 2017 at 07:02:48AM +0200, Dirk Behme wrote:

[...]

quoted

The other problem is security related. If, at all, you have to do it the
other way around, then:

Make Linux a consumer of the other CPU's (trusted/trustzone/whatever
secured) OS clock driver.

Yes, that's better and is getting common on newer platforms. They have
separate M-class(or even low A-class e.g. A5/A7) processors to handle
all the system management.

The new ARM SCMI specification[0][1] is designed to standardize the
interface. It covers the clocks in clock protocol.

That doesn't matter much. Either way the first CPU has to provide the
master side of this device (as it needs clks for booting up) and the 2nd
gets this virtual clk device that forwards clk requests to the first
CPU.

On my machine (Udoo Neo, A9 + M4) the A9 is the primary CPU that is
started by the bootrom. If I want the M4 being the primary device I'd
need support in the bootloader to wait long enough (i.e. until the M4 is
up) before letting the A9 jump into Linux.

I think that is platform specific. On few platforms I have seen
recently, it's M4 or whatever core that handles system power management
boots first and is responsible to even boot secondaries.

Managable I'd say. This way would even make sense if the M4 runs a
rt critical OS that shouldn't be forced to wait on the non-rt A9 to> enable a clk.

Exactly.

-- 
Regards,
Sudeep


[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
[1] https://marc.info/?l=devicetree&m=149849482623492&w=2