[RFC 08/18] arm: msm: set L2CR1 to enable prefetch and burstonScorpion.

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Catalin Marinas
> Sent: Tuesday, January 12, 2010 7:03 PM
> To: Russell King - ARM Linux
> Cc: Larry Bassel; Daniel Walker; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC 08/18] arm: msm: set L2CR1 to enable prefetch and burstonScorpion.
> 
> On Tue, 2010-01-12 at 11:44 +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 12, 2010 at 10:51:41AM +0000, Catalin Marinas wrote:
> > > We discussed in the past but the thread died. There are various bits
> > > that may need to be enabled before the CPU is initialised but it is
> > > highly dependent on the hardware configuration and not only the CPU
> > > type. For example, Cortex-A8/A9 may have some bits in the ACTLR register
> > > which are fine to set on RealView but not on OMAP because the kernel
> > > there is running in non-secure mode. Now Scorpion has other needs.
> > >
> > > Since such initialisation would run before the MMU is enabled, should we
> > > add an additional per-platform macro to be invoked before the CPU is set
> > > up? A pointer in the machine_desc structure to an asm routine would also
> > > work assuming that care is taken to calculate the phys address and the
> > > code is position independent.
> >
> > What you're asking for is bith platform and CPU dependent - which makes
> > it much more difficult to generalize.  It also throws a spanner in the
> > works for the DT people.
> 
> If it would only be CPU dependent, we could just add some ID checking in
> proc-v*.S and but for some cases it's also platform dependent (like
> secure vs. non-secure vs. secure monitor API).
> >
> > > An alternative would be to briefly enable the MMU for the initialisation
> > > (using a temporary page table) than disable it and switch to the proper
> > > one built via create_mapping(). This would allow some initialisation
> > > code to be written in C (though I'm not sure it's worth the effort).
> >
> > How would that work?  You're saying on one hand that there's initialization
> > which needs to be done before the MMU is initialized, and in this paragraph
> > you're saying it can be done while the MMU is initialized and enabled.
> 
> Standard (architecture) MMU initialisation without additional
> optimisation bits (similar to what we have in the decompressor). It
> won't support SMP, shared page tables etc.
> 
> > Actually, what you describe is what's already being done by the head.S
> > code - we already build a temporary page table and enable the MMU so that
> > we can get the C code running to setup the page tables properly.
> 
> Yes, that's the table I was referring to. It could be even made not to
> depend on CONFIG_SMP and always make it UP (no shared bit, this way it
> would be simpler to run SMP kernel on UP hardware by doing some checks
> later).
> 
> We still have things like the SMP/nAMP mode which is Cortex-A9 and
> ARM11MPCore specific. There is also the TLB ops broadcasting bit in
> ACTLR which is also specific to ARM Ltd cores and some of these bits may
> not be accessible directly if you run in non-secure mode.
> 
> > It strikes me that things are just becoming excessively complicated with
> > these seemingly "catch-22" issues.  Maybe a totally different approach is
> > needed - such as requiring some of this low level setup to be done by the
> > platform's boot loader?
> 
> Ideally, yes, it would be nice if these were done by the boot loader. We
> would have to define some clear requirements or at least saying that
> Linux only touches the architectured registers and not the
> implementation defined ones. But I'm not sure how feasible this would
> be.
> 
> There is also the CPU hotplug case where CPUs come back via the setup
> function and may need to touch bits like SMP/nAMP. This should work
> together with a boot monitor.
Doing this in Bootloader only fixes half of the problem. When doing 
power management in the kernel, you still need to play with these bits 
so having support in the kernel is preferable.
Also people will use custom boot-loaders for the same SOC and in such 
cases it's difficult to ensure/control that the needed bits are enabled.

Regards,
Santosh