linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] ARM: Add Broadcom Brahma-B15 readahead cache support
Date: Tue, 17 Mar 2015 11:02:22 -0700	[thread overview]
Message-ID: <55086C2E.3030700@gmail.com> (raw)
In-Reply-To: <20150317172930.GY8399@arm.com>

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()?

Thanks!
-- 
Florian

  reply	other threads:[~2015-03-17 18:02 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 [this message]
2015-03-23 11:14       ` Will Deacon
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=55086C2E.3030700@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).