[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120725084731.GB11389@arm.com>
Date: Wed, 25 Jul 2012 09:47:31 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Christopher Covington <cov@...eaurora.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Will Deacon <Will.Deacon@....com>
Subject: Re: [08/36] AArch64: Kernel booting and initialisation
On Tue, Jul 24, 2012 at 08:42:28PM +0100, Christopher Covington wrote:
> On 01/-10/-28163 02:59 PM, Catalin Marinas wrote:
> > +- Architected timers
> > + CNTFRQ must be programmed with the timer frequency.
> > + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
> > + set where available.
>
> After Marc Zyngier's virtual timer patches come in, will the latter
> requirement only be strictly necessary for kernels wanting to do
> virtualization?
A kernel is usually entered at EL1 (rather than EL2) if it is a guest.
In this case, the EL1PCTEN bit should have been enabled from the higher
level to give access to the physical counter.
We assume that the generic timers are present on any AArch64 platform.
> > +/*
> > + * cpu_init - initialise one CPU.
> > + *
> > + * cpu_init sets up the per-CPU stacks.
> > + */
> > +void cpu_init(void)
> > +{
> > +}
>
> It looks like the comment above is a holdover from the 32-bit code and
> no longer applies. Perhaps you could replace it with a comment on where
> stack pointer initialization is actually handled. Searching briefly, it
> looks like it's done in __mmap_switched and __secondary_switched.
I removed this function entirely. On AArch64 we only have a stack per
exception level, so no need for additional initialisation.
Thanks.
--
Catalin
--
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/
Powered by blists - more mailing lists