On Mon, Feb 16, 2015 at 01:44:36PM +0000, Jan Kiszka wrote: > On 2015-02-16 14:37, Mark Rutland wrote: > > On Mon, Feb 16, 2015 at 12:54:49PM +0000, Jan Kiszka wrote: > >> We only set CNTFRQ in arch_timer_init for the boot CPU. But this has to > >> happen for all cores. > >> > >> Fixing this resolves problems of KVM with emulating the generic > >> timer/counter. > >> > >> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> > >> --- > >> arch/arm/cpu/armv7/tegra-common/psci.S | 13 +++++++++++++ > >> 1 file changed, 13 insertions(+) > >> > >> diff --git a/arch/arm/cpu/armv7/tegra-common/psci.S > >> b/arch/arm/cpu/armv7/tegra-common/psci.S > >> index b7501fb..119c246 100644 > >> --- a/arch/arm/cpu/armv7/tegra-common/psci.S > >> +++ b/arch/arm/cpu/armv7/tegra-common/psci.S > >> @@ -51,12 +51,25 @@ ENTRY(psci_arch_init) > >> > >> mrc p15, 0, r4, c0, c0, 5 @ MPIDR > >> and r4, r4, #7 @ number of CPUs in cluster > >> + > >> + adr r5, _sys_clock_freq > >> + cmp r4, #0 > >> + > >> + mrceq p15, 0, r7, c14, c0, 0 @ read CNTFRQ from CPU0 > >> + streq r7, [r5] > >> + > >> + ldrne r7, [r5] > >> + mcrne p15, 0, r7, c14, c0, 0 @ write CNTFRQ to CPU1..3 > > > > Is it not possible to have a hook that uses the same variable as > > arch_timer_init rather than doing a here copy? It seems a shame to > > duplicate the effort. > > The problem is related to the different address spaces. Here we run in > the secure monitor, arch_timer_init - to my understanding - in > non-secure mode. Didn't find a pattern so far how to transfer data (and > that shouldn't be more complex than the above code).
Surely arch_timer_init must be run in a secure mode in order to be allowed to write to CNTFRQ? If this is simply the easiest way of moving the data around then there's no real problem with it; it's just a shame that it only happens in the PSCI case. Thanks, Mark. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
