On Mon, May 17, 2010 at 2:15 AM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > 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. Sure. I just mentioned that as one reason why portable code that does DMA must use the unmap API. > >> 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
