Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks)
Peter De Schrijver
pdeschrijver at nvidia.com
Wed Jul 5 00:25:44 PDT 2017
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.
More information about the linux-arm-kernel
mailing list