On Tue, May 18, 2010 at 11:05 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
> On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> 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).
> 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).
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
