On Tue, May 18, 2010 at 2:02 PM, Felipe Contreras <felipe.contre...@gmail.com> wrote: > On Tue, May 18, 2010 at 11:05 AM, Ohad Ben-Cohen <o...@wizery.com> wrote: >> On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras >> <felipe.contre...@gmail.com> wrote: >>> So currently (v2.6.33), before sending a read-olny buffer (TO_DEVICE), >>> we do dmac_flush_range (should be clean, but whatever) and before >>> sending a write-only (FROM_DEVICE), we do dmac_inv_range. >>> >>> On v2.6.33 the same could be achieved with only dma_map_* functions, >>> but on v2.6.34 that's not the case. >> >> Sorry, I didn't completely follow you here, let's take a look at the >> mapping code: >> >> ENTRY(v7_dma_map_area) >> add r1, r1, r0 >> teq r2, #DMA_FROM_DEVICE >> beq v7_dma_inv_range >> b v7_dma_clean_range >> ENDPROC(v7_dma_map_area) >> >> DMA_FROM_DEVICE will get the cache invalidated and then cleaned, >> and DMA_BIDIRECTIONAL/DMA_TO_DEVICE will get the cache only >> cleaned. > > No, when DMA_FROM_DEVICE, only v7_dma_inv_range is executed (see the > mov pc, lr at the end).
Oh, sure. thanks for pointing that out. >> Unfortunately I don't have a setup right now to test this, but the code >> seems to be ok for our needs, don't you think ? > > But yeah, actually that fits our needs; calling the dma_map only, > while still wrong, will give us the same behavior we have right now > (v2.6.33). > Great, so are you ok with this patchset proposal ? I'll just add support for the VM_IO path you mentioned. Thanks, Ohad. > So my table was wrong, it's actually: > > in: begin BIDI: > dma_clean_range > > out: begin FROM_DEV: > dma_inv_range > > out: end FROM_DEV: > dma_inv_range > > in: end BIDI: > dma_inv_range > > Cheers. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
