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

[Shilimkar, Santosh]

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"