linux-kernel - Re: [PATCH 2/2] ARM: dts: enable init rate for clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3345042.lGjGYUIfnV@phil>
Date:	Tue, 07 Oct 2014 21:37:48 +0200
From:	Heiko Stübner <heiko@...ech.de>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Kever Yang <kever.yang@...k-chips.com>,
	Mike Turquette <mturquette@...aro.org>,
	Sonny Rao <sonnyrao@...omium.org>,
	Addy Ke <addy.ke@...k-chips.com>,
	Eddie Cai <cf@...k-chips.com>, Jianqun Xu <xjq@...k-chips.com>,
	han jiang <hj@...k-chips.com>,
	Tao Huang <huangtao@...k-chips.com>,
	戴克霖 (Jack) <dkl@...k-chips.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-rockchip@...ts.infradead.org,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] ARM: dts: enable init rate for clock

Am Dienstag, 7. Oktober 2014, 12:20:38 schrieb Doug Anderson:
> Heiko,
> 
> On Tue, Oct 7, 2014 at 11:27 AM, Heiko Stübner <heiko@...ech.de> wrote:
> > Am Dienstag, 7. Oktober 2014, 10:03:19 schrieb Doug Anderson:
> >> Kever,
> >> 
> >> On Tue, Oct 7, 2014 at 2:33 AM, Kever Yang <kever.yang@...k-chips.com>
> > 
> > wrote:
> >> > We need to initialize PLL rate and some of bus clock rate while
> >> > kernel init, for there is no other module will do that.
> >> > 
> >> > Signed-off-by: Kever Yang <kever.yang@...k-chips.com>
> >> > ---
> >> > 
> >> >  arch/arm/boot/dts/rk3288.dtsi | 10 ++++++++++
> >> >  1 file changed, 10 insertions(+)
> >> > 
> >> > diff --git a/arch/arm/boot/dts/rk3288.dtsi
> >> > b/arch/arm/boot/dts/rk3288.dtsi
> >> > index 874e66d..2f4519b 100644
> >> > --- a/arch/arm/boot/dts/rk3288.dtsi
> >> > +++ b/arch/arm/boot/dts/rk3288.dtsi
> >> > @@ -455,6 +455,16 @@
> >> > 
> >> >                 rockchip,grf = <&grf>;
> >> >                 #clock-cells = <1>;
> >> >                 #reset-cells = <1>;
> >> > 
> >> > +               assigned-clocks = <&cru PLL_GPLL>, <&cru PLL_CPLL>,
> >> > +                                 <&cru PLL_NPLL>, <&cru ACLK_CPU>,
> >> > +                                 <&cru HCLK_CPU>, <&cru PCLK_CPU>,
> >> > +                                 <&cru ACLK_PERI>, <&cru HCLK_PERI>,
> >> > +                                 <&cru PCLK_PERI>;
> >> > +               assigned-clock-rates = <594000000>, <400000000>,
> >> > +                                      <500000000>, <300000000>,
> >> 
> >> When I boot up, I see that ACLK_CPU was 297000000.  You specified
> >> 300000000.  Did you expect to get 300?  If you expected 297, I think
> >> you should put 297.  If you expected 300 then we have some debugging
> >> to do.  Note: I'm not quite sure how you'd expect to get 300 given
> >> that none of the PLLs divide evenly to 300...
> > 
> > I'd think 300 is simply the target value. I.e. take the closest rate <=
> > 300
> > MHz, same for 150 etc. I somehow like the approach of specifying what the
> > rate _should_ ideally be :-) .
> > 
> > Also reduces the amount of thougths necessary (and possible
> > head-scratching) when adapting the pll rates to some other constraints
> > (child-clocks already have the target rates and cannot drop to some even
> > stranger value).
> OK, fair enough.  I guess maybe I've overly paranoid and like to make
> sure that someone has thought through exactly what various core clocks
> should be and made sure that the voltage matched and that clocks were
> never out of spec.  ...but if others really like specifying more ideal
> values then I'm OK with it.

Especially as clocks like ACLK_CPU can select from different plls (cpll and 
gpll on the rk3288) it would be even more difficult to predict which path the 
clock selection would take. So it makes sense to specifiy the value we wish for 
and let the common-clock-framework do its magic to select the best sources.


>I will say that I'd really like the PLLs
> to be exact, though.  I think those are now...

agreed. PLL rates should be exact.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/