[PATCH v2] drm/exynos: use prime helpers

Inki Dae inki.dae at samsung.com
Sun Dec 9 20:33:46 PST 2012


2012/12/8 Aaron Plattner <aplattner at nvidia.com>

> On 12/06/2012 10:36 PM, Inki Dae wrote:
>
>>
>> Hi,
>>
>> CCing media guys.
>>
>> I agree with you but we should consider one issue released to v4l2.
>>
>> As you may know, V4L2-based driver uses vb2 as buffer manager and the
>> vb2 includes dmabuf feature>(import and export) And v4l2 uses streaming
>> concept>(qbuf and dqbuf)
>> With dmabuf and iommu, generally qbuf imports a fd into its own buffer
>> and maps it with its own iommu table calling dma_buf_map_attachment().
>> And dqbuf calls dma_buf_unmap_attachment() to unmap that buffer from its
>> own iommu table.
>> But now vb2's unmap_dma_buf callback is nothing to do. I think that the
>> reason is the below issue,
>>
>> If qbuf maps buffer with iomm table and dqbuf unmaps it from iommu table
>> then it has performance deterioration because qbuf and dqbuf are called
>> repeatedly.
>> And this means map/unmap are repeated also. So I think media guys moved
>> dma_unmap_sg call from its own unmap_dma_buf callback to detach callback
>> instead.
>> For this, you can refer to vb2_dc_dmabuf_ops_unmap and
>> vb2_dc_dmabuf_ops_detach function.
>>
>> So I added the below patch to avoid that performance deterioration and
>> am testing it now.(this patch is derived from videobuf2-dma-contig.c)
>> http://git.kernel.org/?p=**linux/kernel/git/daeinki/drm-**
>> exynos.git;a=commit;h=**576b1c3de8b90cf1570b8418b60afd**1edaae4e30<http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git;a=commit;h=576b1c3de8b90cf1570b8418b60afd1edaae4e30>
>>
>> Thus, I'm not sure that your common set could cover all the cases
>> including other frameworks. Please give me any opinions.
>>
>
> It seems like this adjustment would make perfect sense to add to the
> helper layer I suggested.  E.g., instead of having an exynos_attach
> structure that caches the sgt, there'd be a struct drm_gem_prime_attach
> that would do the same thing, and save the sgt it gets from
> driver->gem_prime_get_sg.  Then it would benefit nouveau and radeon, too.
>

If this change is applied to common helper and also that could be accepted
by other maintainers then I think it's better to use this common helper
instead of specific one.


>
> Alternatively, patch #4 could be dropped and Exynos can continue to
> reimplement all of this core functionality, since the helpers are optional,
> but I don't see anything about this change that should make it
> Exynos-specific,


I agree with you. I also think this change isn't specific to Exynos. But
you need to check if this is a reasonable change for other drivers also.

Thanks,
Inki Dae


> unless I'm missing something.
>
>
--
> Aaron
>
> ______________________________**_________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.**org <dri-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/dri-devel<http://lists.freedesktop.org/mailman/listinfo/dri-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121210/a5487809/attachment.html>


More information about the dri-devel mailing list