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: [...] >> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
