[PATCH 2/2] ARM: omap5/dra7xx: Fix counter frequency drift for AM572x errata i856.
Nishanth Menon
nm at ti.com
Wed Dec 17 07:22:25 PST 2014
On 09:55-20141217, Lennart Sorensen wrote:
> On Wed, Dec 17, 2014 at 03:21:27PM +0200, Tero Kristo wrote:
> > Yea I think the 32k clock node should be fixed based on this.
> > Something like this:
> >
> > --- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
> > +++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
> > @@ -100,8 +100,10 @@
> >
> > sys_32k_ck: sys_32k_ck {
> > #clock-cells = <0>;
> > - compatible = "fixed-clock";
> > - clock-frequency = <32768>;
> > + compatible = "fixed-factor-clock";
> > + clocks = <&sys_clkin1>;
> > + clock-mult = <1>;
> > + clock-div = <610>;
> > };
> >
> > virt_12000000_ck: virt_12000000_ck {
> >
> >
> > It might be better then just query the actual clock rate from the
> > timer code.
>
> But it is only SYSCLK1 / 610 if the DRA7_CTRL_CORE_BOOTSTRAP register
> says it is. Otherwise is is in fact 32768Hz. I certainly would expect
> that if another revision of the chip is made (and even for the single
> core AM571x chips when they are done) will have this fixed and will work
> with the external 32.768KHz crystal, if it is present.
>
> So how does one make the dtb reflect what the state of the CPU actually
> is?
>
> The errata even says that if SYSCLK1 is 26MHz (not a supported option
> in the manual), then the 32.768KHz crystal does work and the counter
> frequency will in fact be 6.144MHz like it should be.
>
> So just changing the dtb is not an option.
A clock mux might do the job?
value 1, 2 , 3 will imply sysclk1 / 610
value of 0 implies fixed 32768
soemthing like
sys_clk32_crystal {
compatible = "fixed-clock";
clock-frequency = <32768>;
}
sys_clk32_pseudo {
compatible = "fixed-clock";
compatible = "fixed-factor-clock";
clocks = <&sys_clkin1>;
clock-mult = <1>;
clock-div = <610>;
}
sys_32k_ck: sys_32k_ck {
compatible = "ti,mux-clock";
clocks = <&sys_clk32_crystal>, <&sys_clk32_pseudo>, <&sys_clk32_pseudo>, <&sys_clk32_pseudo>;
};
I think... The only issue is that the BOOTSTRAP register is not around
the usual CM1,2 address region...
--
Regards,
Nishanth Menon
More information about the linux-arm-kernel
mailing list