[Linaro-mm-sig] [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
rob at ti.com
Sun Feb 5 15:08:07 UTC 2012
On Sat, Feb 4, 2012 at 5:43 AM, Sakari Ailus <sakari.ailus at iki.fi> wrote:
> Hi Rob,
> Clark, Rob wrote:
>> On Mon, Jan 30, 2012 at 4:01 PM, Sakari Ailus <sakari.ailus at iki.fi> 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
> 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()
> Sakari Ailus
> sakari.ailus at iki.fi
More information about the Linaro-mm-sig