On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > 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. > That would need identity mapping and also correct cache flushing as you said above. L2 enabled for A8 is fine but not sure about the A15 where L2 is enabled with C bit. Then there are some settings for ACTLR, L2ACCTRL and L2PFR which needs to be setup before MMU is ebabled. And then the errata's on A9, needing setting up dignostic register, changing cache policy etc Hopefully we don't get hit by those issues/erratas in the window from initial MMU setup to this new sequence code. Will this approach be ok for other cases I mentioned ? Regards Santosh -- 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
