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] [day] [month] [year] [list]

Message-ID: <CAD=FV=WnSM1swHG7aEFk0ox11QmhMHM=WX6gD9jzPbXtUqnfTg@mail.gmail.com>
Date:	Tue, 7 Oct 2014 14:10:12 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Heiko Stübner <heiko@...ech.de>
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

Hi,

On Tue, Oct 7, 2014 at 12:37 PM, Heiko Stübner <heiko@...ech.de> wrote:
> 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.

OK, fair enough.  Then you can give my:

Reviewed-by: Doug Anderson <dianders@...omium.org>
Tested-by: Doug Anderson <dianders@...omium.org>

...of course I'd still like comments addressed for part 1 of this series.  ;)

-Doug
--
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/