From: Catalin Marinas <catalin.marinas@arm.com>
To: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Cc: Aneesh V <aneesh@ti.com>, Joe Woodward <jw@terrafix.co.uk>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Date: Tue, 17 Jan 2012 13:39:18 +0000 [thread overview]
Message-ID: <20120117133918.GE11475@arm.com> (raw)
In-Reply-To: <CAMQu2gyft96O61Toja-h-MPpzFTQ8dpJWauw3o6qcPQBXEC_6A@mail.gmail.com>
On Tue, Jan 17, 2012 at 12:40:54PM +0000, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V <aneesh@ti.com> wrote:
> > Hi Catalin,
> >
> >
> > On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
> >>
> >> On Tue, Jan 17, 2012 at 08:54:44AM +0000, Joe Woodward wrote:
> >>>
> >>> So, is the upshot of this that the kernel isn't going to be in a
> >>> position to enable the L2/outer cache on OMAP3 (due to the need for
> >>> hacky/unmaintainable code)?
> >>>
> >>> Hence the bootloader/uBoot had better leave it enabled...
> >>
> >> It could but the Linux decompressor needs to be aware and either flush
> >> the L2 (more difficult as it doesn't have all the device information) or
> >
> > Cortex-A8 is aware of L2$ and can flush it, isn't it?
> >
> >> set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100).
> >
> > If the above is right, this is not needed right?
>
> Well the L2 can be configured as inner or outer, so above
> alone won't work.
>
> Boot-loader disabling L2 cache ( all caches) is still right thing
> and that's what kernel expect.
>
> Since the early kernel code can't be patches for A8, may be
> delaying L2 enabled would work.
Ah, I missed the fact that the L2 is an inner cache on OMAP3+A8. In this
case, I would argue to just leave it enabled since as long as the MMU is
off it won't be accessed. Why does U-Boot need to disable the L2 (I
suspect via some auxiliary control register)?
> But then on A15, we are back to square one since there is no
> control to turn ON/OFF l2 cache.
Well, it's an inner cache, it gets disabled/enabled via the SCTLR.M bit
as is the L1 cache. It does not need to be disabled independently.
> On A15 infact there are other CP15 registers which needs to be set
> before MMU is enabled to have best configuration.
Yes, there are, and my view is that it is up to the platform firmware to
set things right.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Date: Tue, 17 Jan 2012 13:39:18 +0000 [thread overview]
Message-ID: <20120117133918.GE11475@arm.com> (raw)
In-Reply-To: <CAMQu2gyft96O61Toja-h-MPpzFTQ8dpJWauw3o6qcPQBXEC_6A@mail.gmail.com>
On Tue, Jan 17, 2012 at 12:40:54PM +0000, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V <aneesh@ti.com> wrote:
> > Hi Catalin,
> >
> >
> > On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
> >>
> >> On Tue, Jan 17, 2012 at 08:54:44AM +0000, Joe Woodward wrote:
> >>>
> >>> So, is the upshot of this that the kernel isn't going to be in a
> >>> position to enable the L2/outer cache on OMAP3 (due to the need for
> >>> hacky/unmaintainable code)?
> >>>
> >>> Hence the bootloader/uBoot had better leave it enabled...
> >>
> >> It could but the Linux decompressor needs to be aware and either flush
> >> the L2 (more difficult as it doesn't have all the device information) or
> >
> > Cortex-A8 is aware of L2$ and can flush it, isn't it?
> >
> >> set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100).
> >
> > If the above is right, this is not needed right?
>
> Well the L2 can be configured as inner or outer, so above
> alone won't work.
>
> Boot-loader disabling L2 cache ( all caches) is still right thing
> and that's what kernel expect.
>
> Since the early kernel code can't be patches for A8, may be
> delaying L2 enabled would work.
Ah, I missed the fact that the L2 is an inner cache on OMAP3+A8. In this
case, I would argue to just leave it enabled since as long as the MMU is
off it won't be accessed. Why does U-Boot need to disable the L2 (I
suspect via some auxiliary control register)?
> But then on A15, we are back to square one since there is no
> control to turn ON/OFF l2 cache.
Well, it's an inner cache, it gets disabled/enabled via the SCTLR.M bit
as is the L1 cache. It does not need to be disabled independently.
> On A15 infact there are other CP15 registers which needs to be set
> before MMU is enabled to have best configuration.
Yes, there are, and my view is that it is up to the platform firmware to
set things right.
--
Catalin
next prev parent reply other threads:[~2012-01-17 13:39 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-16 10:03 OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)? Joe Woodward
2012-01-16 10:18 ` Shilimkar, Santosh
2012-01-16 10:18 ` Shilimkar, Santosh
2012-01-16 10:59 ` Russell King - ARM Linux
2012-01-16 10:59 ` Russell King - ARM Linux
2012-01-16 12:43 ` Shilimkar, Santosh
2012-01-16 12:43 ` Shilimkar, Santosh
2012-01-16 13:13 ` Russell King - ARM Linux
2012-01-16 13:13 ` Russell King - ARM Linux
2012-01-16 13:22 ` Shilimkar, Santosh
2012-01-16 13:22 ` Shilimkar, Santosh
2012-01-17 8:54 ` Joe Woodward
2012-01-17 12:11 ` Catalin Marinas
2012-01-17 12:11 ` Catalin Marinas
2012-01-17 12:27 ` Aneesh V
2012-01-17 12:27 ` Aneesh V
2012-01-17 12:40 ` Shilimkar, Santosh
2012-01-17 13:39 ` Catalin Marinas [this message]
2012-01-17 13:39 ` Catalin Marinas
2012-01-17 13:58 ` Shilimkar, Santosh
2012-01-17 13:58 ` Shilimkar, Santosh
2012-01-17 16:27 ` Catalin Marinas
2012-01-17 16:27 ` Catalin Marinas
2012-01-17 17:27 ` Shilimkar, Santosh
2012-01-17 17:27 ` Shilimkar, Santosh
2012-01-17 19:39 ` Nicolas Pitre
2012-01-17 19:39 ` Nicolas Pitre
2012-01-17 20:27 ` Shilimkar, Santosh
2012-01-17 20:27 ` Shilimkar, Santosh
2012-01-17 20:45 ` Nicolas Pitre
2012-01-17 20:45 ` Nicolas Pitre
2012-01-17 20:57 ` Nicolas Pitre
2012-01-17 20:57 ` Nicolas Pitre
2012-01-17 20:58 ` Shilimkar, Santosh
2012-01-17 20:58 ` Shilimkar, Santosh
2012-01-17 21:02 ` Nicolas Pitre
2012-01-17 21:02 ` Nicolas Pitre
2012-01-18 8:43 ` Shilimkar, Santosh
2012-01-18 8:43 ` Shilimkar, Santosh
2012-01-17 21:15 ` Russell King - ARM Linux
2012-01-17 21:15 ` Russell King - ARM Linux
2012-01-17 19:47 ` Russell King - ARM Linux
2012-01-17 19:47 ` Russell King - ARM Linux
2012-01-17 20:11 ` Shilimkar, Santosh
2012-01-17 20:11 ` Shilimkar, Santosh
2012-01-17 20:48 ` Russell King - ARM Linux
2012-01-17 20:48 ` Russell King - ARM Linux
2012-01-17 19:43 ` Russell King - ARM Linux
2012-01-17 19:43 ` Russell King - ARM Linux
2012-01-20 8:57 ` Joe Woodward
2012-01-27 11:45 ` Joe Woodward
2012-01-27 17:30 ` Catalin Marinas
2012-01-27 17:30 ` Catalin Marinas
2012-01-31 5:21 ` Aneesh V
2012-01-31 5:21 ` Aneesh V
2012-01-31 7:31 ` Catalin Marinas
2012-01-31 7:31 ` Catalin Marinas
2012-01-31 7:38 ` Shilimkar, Santosh
2012-01-31 7:38 ` Shilimkar, Santosh
2012-01-31 8:54 ` Catalin Marinas
2012-01-31 8:54 ` Catalin Marinas
2012-01-31 9:05 ` Shilimkar, Santosh
2012-01-31 9:05 ` Shilimkar, Santosh
2012-01-31 9:53 ` Catalin Marinas
2012-01-31 9:53 ` Catalin Marinas
2012-01-31 10:10 ` Russell King - ARM Linux
2012-01-31 10:10 ` Russell King - ARM Linux
2012-01-31 12:10 ` Catalin Marinas
2012-01-31 12:10 ` Catalin Marinas
2012-01-31 18:09 ` Nicolas Pitre
2012-01-31 18:09 ` Nicolas Pitre
2012-02-02 14:32 ` Catalin Marinas
2012-02-02 14:32 ` Catalin Marinas
2012-02-02 14:49 ` Russell King - ARM Linux
2012-02-02 14:49 ` Russell King - ARM Linux
2012-02-02 15:10 ` Catalin Marinas
2012-02-02 15:10 ` Catalin Marinas
2012-01-31 9:56 ` Russell King - ARM Linux
2012-01-31 9:56 ` Russell King - ARM Linux
2012-01-31 10:51 ` Shilimkar, Santosh
2012-01-31 10:51 ` Shilimkar, Santosh
2012-01-31 18:27 ` Nicolas Pitre
2012-01-31 18:27 ` Nicolas Pitre
2012-02-01 7:12 ` Shilimkar, Santosh
2012-02-01 7:12 ` Shilimkar, Santosh
2012-01-17 14:18 ` Grazvydas Ignotas
2012-01-17 14:18 ` Grazvydas Ignotas
2012-01-17 13:41 ` Catalin Marinas
2012-01-17 13:41 ` Catalin Marinas
2012-01-17 13:54 ` Aneesh V
2012-01-17 13:54 ` Aneesh V
2012-01-17 14:23 ` Måns Rullgård
2012-01-17 14:23 ` Måns Rullgård
2012-01-17 12:01 ` Aneesh V
2012-01-17 12:01 ` Aneesh V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120117133918.GE11475@arm.com \
--to=catalin.marinas@arm.com \
--cc=aneesh@ti.com \
--cc=jw@terrafix.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=santosh.shilimkar@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.