[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100304154103.GA9384@linux-sh.org>
Date: Fri, 5 Mar 2010 00:41:03 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: James Bottomley <James.Bottomley@...senPartnership.com>,
Pavel Machek <pavel@....cz>,
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
benh@...nel.crashing.org, linux@....linux.org.uk,
mdharm-kernel@...-eyed-alien.net, linux-usb@...r.kernel.org,
x0082077@...com, sshtylyov@...mvista.com, tom.leiming@...il.com,
bigeasy@...utronix.de, oliver@...kum.org,
linux-kernel@...r.kernel.org, santosh.shilimkar@...com,
greg@...ah.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: USB mass storage and ARM cache coherency
On Thu, Mar 04, 2010 at 03:29:38PM +0000, Catalin Marinas wrote:
> On Thu, 2010-03-04 at 14:21 +0000, James Bottomley wrote:
> > The thing which was discovered in this thread is basically that ARM is
> > handling deferred flushing (for D/I coherency) in a slightly different
> > way from everyone else ...
>
> Doing a grep for PG_dcache_dirty defined in terms of PG_arch_1 reveals
> that MIPS, Parisc, Score, SH and SPARC do similar things to ARM. PowerPC
> and IA-64 use PG_arch_1 as a clean rather than dirty bit.
>
SH used to use it as a PG_mapped which was roughly similar to the
PG_dcache_clean approach, at which point things like flushing for the PIO
case in the HCD wasn't necessary. It did result in rather aggressive over
flushing though, which is one of the reasons we elected to switch to
PG_dcache_dirty.
Note that the PG_dcache_dirty semantics are also outlined in
Documentation/cachetlb.txt for PG_arch_1 usage, so it's hardly esoteric.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists