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 <willy@xxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
