From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] Cache maintenance on VIPT caches
Date: Fri, 16 Jul 2010 15:39:17 +0100 [thread overview]
Message-ID: <1279291157.17878.49.camel@e102109-lin.cambridge.arm.com> (raw)
In-Reply-To: <20100716131908.GA15032@bnru02.bnr.st.com>
On Fri, 2010-07-16 at 14:19 +0100, Rabin VINCENT wrote:
> On Fri, Jun 25, 2010 at 14:01:27 +0200, Catalin Marinas wrote:
> > The first and third patches have already been posted in the same form.
> > The second patch have been modified to handle all the VIPT caches via
> > __sync_icache_dcache(). The initial use case for this patch was dealing
> > with an SMP race condition but following suggestions from Rabin, it was
> > extended to cover ARMv6 onwards, both UP and SMP.
> >
> > Any Tested-by's are welcome.
>
> This version also fixes the MMC rootfs init crashes, without the need
> for the flush_kernel_dcache_page() change:
>
> Tested-by: Rabin Vincent <rabin.vincent@stericsson.com>
Thanks for testing.
> Will you be submitting this patch for linux-next?
I'd like to but I'm still waiting for Russell's feedback (the linux-next
rules are that we shouldn't dump patches there that haven't been
reviewed yet).
> I ask because the
> mmci patches that I posted convert that driver to use the sg_miter API
> (which uses flush_kernel_dcache_page() internally), and not do any
> flushing inside the driver itself. Or do you think it would be
> appropriate to have the driver call flush_dcache_page() explicitly?
> (Although this would be double flushing on systems with aliasing caches
> where flush_kernel_dcache_page() is not a no-op.)
I'm not sure why sg_miter doesn't call flush_dcache_page() but
flush_kernel_dcache_page() (I cc'ed Fujita as he seems to have added
this code).
Anyway, we could actually set the PG_dcache_clean bit in
flush_kernel_dcache_page() and thus avoid additional flushing when the
page gets mapped to user space (on VIPT non-aliasing caches).
I think it's fine for your driver not to call flush_dcache_page() as
long as a form of page flushing is done in the sg_miter API. The only
thing we miss is ARM11MPCore with VIPT non-aliasing caches where
flush_kernel_dcache_page() is a no-op, though we have to do non-lazy
flushing because the cache maintenance operations aren't broadcast to
the other CPUs.
There are several places where we can fix this - (1) implement
flush_kernel_dcache_page() for ARM11MPCore, (2) use flush_dcache_page()
in the sg_miter code or (3) call flush_dcache_page() in the mmci driver.
--
Catalin
next prev parent reply other threads:[~2010-07-16 14:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 12:01 [PATCH 0/3] Cache maintenance on VIPT caches Catalin Marinas
2010-06-25 12:01 ` [PATCH 1/3] ARM: Assume new page cache pages have dirty D-cache Catalin Marinas
2010-06-28 14:22 ` Rabin Vincent
2010-06-28 16:49 ` Catalin Marinas
2010-06-25 12:01 ` [PATCH 2/3] ARM: Introduce __sync_icache_dcache() for VIPT caches Catalin Marinas
2010-06-25 12:01 ` [PATCH 3/3] ARM: Use lazy cache flushing on ARMv7 SMP systems Catalin Marinas
2010-07-16 13:19 ` [PATCH 0/3] Cache maintenance on VIPT caches Rabin VINCENT
2010-07-16 14:39 ` Catalin Marinas [this message]
2010-07-20 9:56 ` FUJITA Tomonori
2010-07-20 11:37 ` Catalin Marinas
2010-07-20 11:42 ` Catalin Marinas
2010-07-20 13:39 ` Catalin Marinas
2010-07-20 15:22 ` Nicolas Pitre
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=1279291157.17878.49.camel@e102109-lin.cambridge.arm.com \
--to=catalin.marinas@arm.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).