[lkml]   [2012]   [Jan]   [9]   [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 Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
    > I has test dmabuf based drm gem module for exynos and I found one problem.
    > you can refer to this test repository:
    > at this repository, I added some exception codes for resource release
    > in addition to Dave's patch sets.
    > let's suppose we use dmabuf based vb2 and drm gem with physically
    > continuous memory(no IOMMU) and we try to share allocated buffer
    > between them(v4l2 and drm driver).
    > 1. request memory allocation through drm gem interface.
    > 2. request DRM_SET_PRIME ioctl with the gem handle to get a fd to the
    > gem object.
    > - internally, private gem based dmabuf moudle calls drm_buf_export()
    > to register allocated gem object to fd.
    > 3. request qbuf with the fd(got from 2) and DMABUF type to set the
    > buffer to v4l2 based device.
    > - internally, vb2 plug in module gets a buffer to the fd and then
    > calls dmabuf->ops->map_dmabuf() callback to get the sg table
    > containing physical memory info to the gem object. and then the
    > physical memory info would be copied to vb2_xx_buf object.
    > for DMABUF feature for v4l2 and videobuf2 framework, you can refer to
    > this repository:
    > git:// drmplane-dmabuf
    > after that, if v4l2 driver want to release vb2_xx_buf object with
    > allocated memory region by user request, how should we do?. refcount
    > to vb2_xx_buf is dependent on videobuf2 framework. so when vb2_xx_buf
    > object is released videobuf2 framework don't know who is using the
    > physical memory region. so this physical memory region is released and
    > when drm driver tries to access the region or to release it also, a
    > problem would be induced.
    > for this problem, I added get_shared_cnt() callback to dma-buf.h but
    > I'm not sure that this is good way. maybe there may be better way.
    > if there is any missing point, please let me know.

    The dma_buf object needs to hold a reference on the underlying
    (necessarily reference-counted) buffer object when the exporter creates
    the dma_buf handle. This reference should then get dropped in the
    exporters dma_buf->ops->release() function, which is only getting called
    when the last reference to the dma_buf disappears.

    If this doesn't work like that currently, we have a bug, and exporting the
    reference count or something similar can't fix that.

    Yours, Daniel

    PS: Please cut down the original mail when replying, otherwise it's pretty
    hard to find your response ;-)
    Daniel Vetter
    Mobile: +41 (0)79 365 57 48

     \ /
      Last update: 2012-01-09 09:11    [W:4.067 / U:0.112 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site