On Sat, Feb 4, 2012 at 5:43 AM, Sakari Ailus <sakari.ailus@xxxxxx> wrote: > Hi Rob, > > Clark, Rob wrote: >> On Mon, Jan 30, 2012 at 4:01 PM, Sakari Ailus <sakari.ailus@xxxxxx> wrote: >>> >>>> So to summarize I understand your constraints - gpu drivers have worked >>>> like v4l a few years ago. The thing I'm trying to achieve with this >>>> constant yelling is just to raise awereness for these issues so that >>>> people aren't suprised when drm starts pulling tricks on dma_bufs. >>> >>> I think we should be able to mark dma_bufs non-relocatable so also DRM can >>> work with these buffers. Or alternatively, as Laurent proposed, V4L2 be >>> prepared for moving the buffers around. Are there other reasons to do so >>> than paging them out of system memory to make room for something else? >> >> fwiw, from GPU perspective, the DRM device wouldn't be actively >> relocating buffers just for the fun of it. I think it is more that we >> want to give the GPU driver the flexibility to relocate when it really >> needs to. For example, maybe user has camera app running, then puts >> it in the background and opens firefox which tries to allocate a big >> set of pixmaps putting pressure on GPU memory.. >> >> I guess the root issue is who is doing the IOMMU programming for the >> camera driver. I guess if this is something built in to the camera >> driver then when it calls dma_buf_map() it probably wants some hint >> that the backing pages haven't moved so in the common case (ie. buffer >> hasn't moved) it doesn't have to do anything expensive. >> >> On omap4 v4l2+drm example I have running, it is actually the DRM >> driver doing the "IOMMU" programming.. so v4l2 camera really doesn't >> need to care about it. (And the IOMMU programming here is pretty > > This part sounds odd to me. Well, I guess it _could_ be done that way, > but the ISP IOMMU could be as well different as the one in DRM. That's > the case on OMAP 3, for example. Yes, this is a difference between OMAP4 and OMAP3.. although I think the intention is that OMAP3 type scenarios, if the IOMMU mapping was done through the dma mapping API, then it could still be done (and cached) by the exporter. >> fast.) But I suppose this maybe doesn't represent all cases. I >> suppose if a camera didn't really sit behind an IOMMU but uses >> something more like a DMA descriptor list would want to know if it >> needed to regenerate it's descriptor list. Or likewise if camera has >> an IOMMU that isn't really using the IOMMU framework (although maybe >> that is easier to solve). But I think a hint returned from >> dma_buf_map() would do the job? > > An alternative to IOMMU I think in practice would mean CMA-allocated > buffers. > > I need to think about this a bit and understand how this would really > work to properly comment this. > > For example, how does one mlock() something that isn't mapped to process > memory --- think of a dma buffer not mapped to the user space process > address space? The scatter list that the exporter gives you should be locked/pinned already so importer should not need to call mlock() BR, -R > Cheers, > > -- > Sakari Ailus > sakari.ailus@xxxxxx -- 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
