On 31 January 2012 07:38, Shilimkar, Santosh <santosh.shilimkar@xxxxxx> wrote: > On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas > <catalin.marinas@xxxxxxx> wrote: >> On 31 January 2012 05:21, Aneesh V <aneesh@xxxxxx> wrote: >>> On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote: >>>> On Fri, Jan 20, 2012 at 08:57:11AM +0000, Joe Woodward wrote: >>>>>> So I re-iterate that we need to have solution to this problem. >>>>> >>>>> ... I don't want to be a pain, but it seems to me that this dicussion >>>>> didn't reach a full conclussion? >>>> >>>> Probably not, because it depends on many variables. See below my take on >>>> this. >>>> >>>>> I think it was left with the open options being: >>>>> 1) Leave the L2/outer cache enabled in the bootloader (not ideal and >>>>> may cause problems with future devices) >>>> >>>> This depends on whether the L2 is inner or outer: >>>> >>>> L2 inner - leave it enabled in the boot loader >>>> L2 outer - leave it disabled in the boot loader >>>> >>>>> 2) Turn the L2/outer cache on for OMAP3 later in the kernel boot when >>>>> the device is known >>>> >>>> Same as above: >>>> >>>> L2 inner - don't do anything, it gets used when SCTLR.M is enabled >>>> L2 outer - enabled at boot time via the platform code (later, after MMU >>>> was enabled). >>> >>> What is the reasoning behind this recommendation? Why the distinction >>> between L2 being inner or outer. I don't see anything to this effect in >>> the Cortex-A8 TRM? In fact the only recommendation I could find(section >>> 8.3) is asking to set L2EN to 1 before setting C bit to 1 irrespective >>> of inner/outer? >> >> Actually you have a good point. I was thinking about outer caches like >> PL310 or L220 that Linux enables later during platform initialisation. >> They could be left enabled or disabled at boot time but they must be >> cleaned/invalidated (you would need to flush after disabling just to >> make sure there are no further lines fetched; alternatively, there >> shouldn't be any cacheable mappings). >> >> So I would say in the context of A8, just leave the L2 enabled in the >> boot loader. As long as the MMU is disabled, it won't be used. The >> alternative is to enable L2 slightly later in Linux in the platform >> code to avoid SoC-dependent code in proc-v7.S. >> >> So in summary, either option is possible. You could take the approach >> of the cache-l2x0.c - check whether it is already enabled and, if not, >> issue an SMC from the platform code to enable the L2 cache. >> > if done late in kernel, wouldn't it violate "set L2EN to 1 before > setting C bit to 1" Not if you write the code sequence in such a way that it also switches the C bit to 0 and back to 1. I think Nicolas suggested that the platform code could go through the power management code. But I think with some carefully coded asm code and cache flushing you could set L2EN without a full MMU reset. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
