[U-Boot] [PATCH 04/28] armv8/ls2085a: Fix generic timer clock source

[Mark Rutland]

On Thu, Mar 19, 2015 at 06:24:10PM +0000, York Sun wrote:
> On 03/19/2015 11:17 AM, Mark Rutland wrote:
> > On Thu, Mar 19, 2015 at 06:16:25PM +0000, York Sun wrote:
> >> On 03/19/2015 11:08 AM, Mark Rutland wrote:
> >>>> +
> >>>> +int timer_init(void)
> >>>> +{
> >>>> +	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
> >>>> +	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
> >>>> +#ifdef COUNTER_FREQUENCY_REAL
> >>>> +	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
> >>>> +
> >>>> +	/* Update with accurate clock frequency */
> >>>> +	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
> >>>> +#endif
> >>>
> >>> Is this executed on all CPUs, or do secondary CPUs have CNTFRQ
> >>> programmed with the correct value elsewhere?
> >>>
> >>
> >> Only the primary CPU runs here. The secondary CPU doesn't come here.
> > 
> > Ok. Where does CNTFRQ get programmed for those CPUs?
> > 
> > If it's necessary to write COUNTER_FREQUENCY_REAL to the primary CPU's
> > CNTFRQ, that's also necessary on the secondaries before they enter the
> > OS.
> 
> Hmm, this may be a bug. Didn't hear any complain from Linux users. We found the
> timer wasn't correct during bring-up. Let me check with internal team.

Cheers!

If the CPUs don't have matching CNTFRQ, things will work most of the
time, but timekeeping will be broken in some cases (e.g. KVM guests,
after a kexec). It's not possible for the OS to fix this up, so the boot
protocol requires that it's programmed on all CPUs prior to entering the
kernel.

Since commit 127161aaf0fcd376 ("arm64: add runtime system sanity
checks"), Linux should complain at boot time if CNTFRQ is mismatched
across CPUs. We've added other sanity checks since that commit.

Mark.