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" -- 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
