On Tue, Jul 04, 2017 at 09:49:25AM +0100, Sudeep Holla wrote: > > > On 04/07/17 08:31, Peter De Schrijver wrote: > > On Mon, Jul 03, 2017 at 10:17:22AM +0100, Sudeep Holla wrote: > >> > >> > >> 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. > >> > > > > 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. -- 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
