Hi Ohad, On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: >> I looked into the dma code (I guess it's in arch/arm/mm/dma-mapping.c) >> and I don't understand what dma_unmap_sg is supposed to do. > > Portable code must use the dma_unmap_* APIs. > > As you mentioned, one of the things it's crucial for > (but not used in our case) is bounce buffers: > e.g. when doing a DMA from a device using a buffer > that is out of the platform's DMA reach, > the DMA API uses bounce buffers: data DMA'ed to that > bounce buffer, and then the dma unmap copies it back > to the original buffer). Yes, but in dspbridge the most important use-case is video encoding/decoding, so we definitely don't want bouncing buffers. Besides, from what I can see very few platforms need them. > Another thing unmap is taking care of is speculative prefetch: > modern ARM processors can access the buffer during DMA > in order to speculatively prefetch data into the cache. Naturally > this can seriously break a DMA from a device, so unmap is > invalidating the caches to prevent this. > > The current dspbridge cache API is mostly relying on the > application to do the right thing: application programmer should > decide when to clean, flush or invalidate the caches in order > to have a successful DMA operation. > > This is prone to mistakes, it's not portable, and of course > not upstreamable. > > Using the standard DMA API we take the freedom from the > application programmer - we just ask him/her to tell us before > a DMA operation begins, and after it ends. The DMA API > is then responsible to do the right thing. It is a higher level of abstraction, but the application still needs to do the right thing, and errors can still happen. Anyway, I see now the changes 2.6.34. can > I read at your latest posts that after rebasing to newest dspbridge > code the issue doesn't reproduce anymore ? Please tell me if it's back. Yes... I haven't tried in the old commit you started from + the patch Omar suggested, but I guess there's no need for that any more. I can play with this code now :) -- 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
