[lkml]   [2012]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
    On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark <> wrote:
    > On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae <> wrote:
    >> 2012/1/10 Rob Clark <>:
    >> at least with no IOMMU, the memory information(containing physical
    >> memory address) would be copied to vb2_xx_buf object if drm gem
    >> exported its own buffer and vb2 wants to use that buffer at this time,
    >> sg table is used to share that buffer. and the problem I pointed out
    >> is that this buffer(also physical memory region) could be released by
    >> vb2 framework(as you know, vb2_xx_buf object and the memory region for
    >> buf->dma_addr pointing) but the Exporter(drm gem) couldn't know that
    >> so some problems would be induced once drm gem tries to release or
    >> access that buffer. and I have tried to resolve this issue adding
    >> get_shared_cnt() callback to dma-buf.h but I'm not sure that this is
    >> good way. maybe there would be better way.
    Hi Inki,
    As also mentioned in the documentation patch, importer (the user of
    the buffer) - in this case for current RFC patches on
    v4l2-as-a-user[1] vb2 framework - shouldn't release the backing memory
    of the buffer directly - it should only use the dma-buf callbacks in
    the right sequence to let the exporter know that it is done using this
    buffer, so the exporter can release it if allowed and needed.
    > the exporter (in this case your driver's drm/gem bits) shouldn't
    > release that mapping / sgtable until the importer (in this case v4l2)
    > calls dma_buf_unmap fxn..
    > It would be an error if the importer did a dma_buf_put() without first
    > calling dma_buf_unmap_attachment() (if currently mapped) and then
    > dma_buf_detach() (if currently attached).  Perhaps somewhere there
    > should be some sanity checking debug code which could be enabled to do
    > a WARN_ON() if the importer does the wrong thing.  It shouldn't really
    > be part of the API, I don't think, but it actually does seem like a
    > good thing, esp. as new drivers start trying to use dmabuf, to have
    > some debug options which could be enabled.
    > It is entirely possible that something was missed on the vb2 patches,
    > but the way it is intended to work is like this:
    > where it does a detach() before the dma_buf_put(), and the vb2-contig
    > backend checks here that it is also unmapped():

    The proposed RFC for V4L2 adaptation at [1] does exactly the same
    thing; detach() before dma_buf_put(), and check in vb2-contig backend
    for unmapped() as mentioned above.

    > BR,
    > -R

    [1]: V4l2 as a dma-buf user RFC:
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-01-10 07:11    [W:0.024 / U:1.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site