From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCHv2 1/5] mm: add coherence API for DMA to vmalloc/vmap areas Date: Sun, 03 Jan 2010 08:27:58 +1100 Message-ID: <1262467678.2173.244.camel@pasglop> References: <1261603345-2494-1-git-send-email-James.Bottomley@suse.de> <1261603345-2494-2-git-send-email-James.Bottomley@suse.de> <20091224100853.GA3165@console-pimps.org> <20091224123913.GD5335@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Matt Fleming , James Bottomley , linux-arch@vger.kernel.org, linux-parisc@vger.kernel.org, Christoph Hellwig , Russell King , Paul Mundt To: Matthew Wilcox Return-path: In-Reply-To: <20091224123913.GD5335@parisc-linux.org> List-ID: List-Id: linux-parisc.vger.kernel.org On Thu, 2009-12-24 at 05:39 -0700, Matthew Wilcox wrote: > > invalidates the processor cache for a given virtual address range > in the vmap area. This API addresses the problem that the processor > may have performed speculative reads into its cache of the vmapped > area while I/O was occurring to the underlying physical pages. > > Signed-off-by: Matthew Wilcox Interestingly, our DMA APIs in this regard are sub-optimal as they should provide 3 hooks, not 2. Flush is good for ensuring dirty lines have been pushed out before an outgoing DMA. But for incoming DMA it would be nice to properly split the 2 calls that may be needed on some archs, one before, one after the transfer. Sure, invalidate twice will "work" but the f will also be sub-optimal on some platforms depending on whether the platform is known to be able or not to speculatively load cache lines etc... Maybe just a "before" vs. "after" argument ? Also, the proposal goes contrary to most of our DMA APIs which don't actually expose the details of invalidate vs. flush but instead expose the direction of the transfer (both lack the above subtlety though). Thoughts ? Cheers, Ben.