From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/5] ARM: Add Broadcom Brahma-B15 readahead cache support
Date: Mon, 23 Mar 2015 11:14:28 +0000 [thread overview]
Message-ID: <20150323111427.GE11189@arm.com> (raw)
In-Reply-To: <55086C2E.3030700@gmail.com>
On Tue, Mar 17, 2015 at 06:02:22PM +0000, Florian Fainelli wrote:
> On 17/03/15 10:29, Will Deacon wrote:
> > On Sat, Mar 07, 2015 at 12:54:50AM +0000, Florian Fainelli wrote:
> >> This patch adds support for the Broadcom Brahma-B15 CPU readahead cache
> >> controller. This cache controller sits between the L2 and the memory bus
> >> and its purpose is to provide a friendler burst size towards the DDR
> >> interface than the native cache line size.
> >>
> >> The readahead cache is mostly transparent, except for
> >> flush_kern_cache_all, flush_kern_cache_louis and flush_icache_all, which
> >> is precisely what we are overriding here.
> >
> > I'm struggling to understand why you care about flush_kern_cache_louis
> > and flush_icache_all for a cache that sits the other side of the L2.
> >
> > Can you explain why we need to do anything in these cases, please?
>
> Let's try, as you may have read in the comment, all MVA-based cache
> maintenance operations are snooped by the RAC, so they are effectively
> "transparent" to software, all others are not.
>
> flush_kern_cache_louis() and flush_icache_all() both use ICALLIUS in the
> SMP case and ICIALLU in the UP case which were flagged as not being
> transparently handled.
>
> The concern is that, if you perform a L1 cache (data or instruction)
> flush (essentially an invalidate), this will also flush (invalidate)
> corresponding L2 cache lines, but the RAC has no way to be signaled that
> is should also invalidate its own RAC cache lines pertaining to that
> data, and RAC holds per-CPU "super" cache lines.
>
> In arch/arm/kernel/smp.c, all uses of flush_cache_louis() are for
> writing-back data, so the RAC is not an issue. In
> arch/arm/kernel/suspend.c, flush_cache_louis() is known not to guarantee
> a "clean" all the way to main memory, so __cpu_flush_dcache_area is used
> in conjunction. In arch/arm/mm/idmap.c and mmu.c, the use of
> flush_cache_louis() seems to be meant to see fresh data, not write-back,
> so not transparent to the RAC, is that right?
>
> It may very well be that we are super cautious here and that the only
> case to take care of is essentially flush_cache_all(), and nothing more.
>
> Would you suggestions on how to instrument/exercise whether we really
> need to deal with flush_cache_louis() and flush_icache_all()?
I think that both flush_cache_louis and flush_icache_all only care about
the inner-shareable domain, so you don't need to do anything with the
RAC. It's a bit like the PL310 outer-cache, which is also not affected
by these operations.
I don't think there's a good way to determine statically if we have
missing cacheflush calls. Maybe a better bet would be to implement a
RAC driver using the outer_cache framework and only implement the
flush_all callback.
Will
next prev parent reply other threads:[~2015-03-23 11:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 0:54 [PATCH 0/5] ARM: Broadcom Brahma-B15 readahead cache support Florian Fainelli
2015-03-07 0:54 ` [PATCH 1/5] ARM: v7: allow setting different cache functions Florian Fainelli
2015-03-07 0:54 ` [PATCH 2/5] ARM: Add Broadcom Brahma-B15 readahead cache support Florian Fainelli
2015-03-16 21:02 ` Russell King - ARM Linux
2015-03-16 21:20 ` Florian Fainelli
2015-03-17 0:10 ` Russell King - ARM Linux
2015-03-17 0:32 ` Florian Fainelli
2015-03-17 17:29 ` Will Deacon
2015-03-17 18:02 ` Florian Fainelli
2015-03-23 11:14 ` Will Deacon [this message]
2015-07-27 18:47 ` Florian Fainelli
2015-03-07 0:54 ` [PATCH 3/5] ARM: Hook B15 readahead cache functions based on processor Florian Fainelli
2015-03-07 0:54 ` [PATCH 4/5] ARM: B15: Add CPU hotplug awareness Florian Fainelli
2015-03-07 0:54 ` [PATCH 5/5] ARM: B15: Add suspend/resume hooks Florian Fainelli
2015-03-16 18:33 ` [PATCH 0/5] ARM: Broadcom Brahma-B15 readahead cache support Florian Fainelli
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=20150323111427.GE11189@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox