2012/1/10 Rob Clark rob@ti.com:
On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae daeinki@gmail.com wrote:
note : in case of sharing a buffer between v4l2 and drm driver, the memory info would be copied vb2_xx_buf to xx_gem or xx_gem to vb2_xx_buf through sg table. in this case, only memory info is used to share, not some objects.
which v4l2/vb2 patches are you looking at? The patches I was using, vb2 holds a reference to the 'struct dma_buf *' internally, not just keeping the sg_table
yes, not keeping the sg_table. I mean... see a example below please.
static void vb2_dma_contig_map_dmabuf(void *mem_priv) { struct sg_table *sg; ... sg = dma_buf_map_attachment(buf->db_attach, dir); ... buf->dma_addr = sg_dma_address(sg->sgl); ... }
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.
Thanks.
BR, -R