From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Rutland <mark.rutland@arm.com>
Date: Mon, 16 Feb 2015 13:51:16 +0000
Subject: [U-Boot] [PATCH v2 12/12] tegra: Set CNTFRQ for secondary CPUs
In-Reply-To: <54E1F444.8080205@siemens.com>
References: <cover.1424091289.git.jan.kiszka@siemens.com>
 <6fc4b6faf718f56c4ca0ffb109fe80774299f558.1424091289.git.jan.kiszka@siemens.com>
 <20150216133659.GB8994@leverpostej> <54E1F444.8080205@siemens.com>
Message-ID: <20150216135116.GE8994@leverpostej>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.kiszka@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.