OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?

[Catalin Marinas]

On 31 January 2012 07:38, Shilimkar, Santosh <santosh.shilimkar at ti.com> wrote:
> On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
>> On 31 January 2012 05:21, Aneesh V <aneesh at ti.com> 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