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
On Mon, Jul 03, 2017 at 10:17:22AM +0100, Sudeep Holla wrote:
On 01/07/17 19:14, Uwe Kleine-K?nig wrote:
quoted
Hello,
On Sat, Jul 01, 2017 at 07:02:48AM +0200, Dirk Behme wrote:
[...]
quoted
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.
Yes, however this doesn't exist on older SoCs which still have multiple CPU's
Peter.
On 04/07/17 08:31, Peter De Schrijver wrote:
On Mon, Jul 03, 2017 at 10:17:22AM +0100, Sudeep Holla wrote:
quoted
On 01/07/17 19:14, Uwe Kleine-K?nig wrote:
quoted
Hello,
On Sat, Jul 01, 2017 at 07:02:48AM +0200, Dirk Behme wrote:
[...]
quoted
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.
Yes, however this doesn't exist on older SoCs which still have multiple CPU's
Agreed. But if someone is fixing/adding support in Linux as well as in
the other OS running on those cores, why not consider this interface
instead of trying to generalize something which will invariably SoC
specific.
--
Regards,
Sudeep
On Tue, Jul 04, 2017 at 09:49:25AM +0100, Sudeep Holla wrote:
On 04/07/17 08:31, Peter De Schrijver wrote:
quoted
On Mon, Jul 03, 2017 at 10:17:22AM +0100, Sudeep Holla wrote:
quoted
On 01/07/17 19:14, Uwe Kleine-K?nig wrote:
quoted
Hello,
On Sat, Jul 01, 2017 at 07:02:48AM +0200, Dirk Behme wrote:
[...]
quoted
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.
Yes, however this doesn't exist on older SoCs which still have multiple CPU's
Agreed. But if someone is fixing/adding support in Linux as well as in
the other OS running on those cores, why not consider this interface
instead of trying to generalize something which will invariably SoC
specific.
Because the firmware of the other CPUs might not be able to support this
or is frozen and cannot be changed.
Peter.