> -----Original Message----- > From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel- > owner@xxxxxxxxxxxxxxx] On Behalf Of David Xiao > Sent: Thursday, August 06, 2009 2:46 PM > To: Laurent Pinchart > Cc: Ben Dooks; Hugh Dickins; Robin Holt; linux-kernel@xxxxxxxxxxxxxxx; > v4l2_linux; linux-arm-kernel@xxxxxxxxxxxxxxxxxxxxxx > Subject: Re: How to efficiently handle DMA and cache on ARMv7 ? (was "Is > get_user_pages() enough to prevent pages from being swapped out ?") > > On Thu, 2009-08-06 at 06:06 -0700, Laurent Pinchart wrote: > > Hi Ben, > > > > On Thursday 06 August 2009 13:46:19 Ben Dooks wrote: > > > On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: > > [snip] > > > > > > > > The second problem is to ensure cache coherency. As the userspace > > > > application will read data from the video buffers, those buffers > will end > > > > up being cached in the processor's data cache. The driver does need > to > > > > invalidate the cache before starting the DMA operation (userspace > could > > > > in theory write to the buffers, but the data will be overwritten by > DMA > > > > anyway, so there's no need to clean the cache). > > > > > > You'll need to clean the write buffers, otherwise the CPU may have > data > > > queued that it has yet to write back to memory. > > > > Good points, thanks. > > I thought this should have been taken care of by the CPU specific > dma_inv_range routine. However, In arch/arm/mm/cache-v7.c, > v7_dma_inv_range does not drain the write buffer; and the > v6_dma_inv_range does that in the end of all the cache maintenance > operaitons. > So this is probably something Russel can clarify. > Something non-related. I haven't used this specific api but ARM1156 has an issue. If you use the clean-cache-block mcr feature then it might result in memory-corruption. So be careful. I'm not sure which of these(ARM1156T2-S or ARM1156T2F-S) variants has that errata. Chetan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
