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