Hey there,
this question arose during some discussion with someone concerning the Exynos mixer and G2D.
The question is the following. Consider the Exynos mixer when run under the IOMMU (that's sysmmu_tv IIRC). What exactly does setup the IOMMU mapping so that the mixer can scanout the framebuffer?
There is exynos_gem_map_sgt_with_dma() in the Exynos GEM code, but it's currently exclusively used for the G2D and only when dealing with userptr (and not GEM) there.
I was looking at exynos_drm_alloc_buf() since this called when allocating a BO to be used as scanout.
I see dma_alloc_attrs() being called, which also sets the DMA address that is later used in the mixer code. But DMA_ATTR_NO_KERNEL_MAPPING is passed, so no mapping is done at this point.
Is the mapping done somewhere else, or is it simply not necessary here?
With best wishes, Tobias
On 10/31/2015 05:44 AM, Tobias Jakobi wrote:
Hey there,
this question arose during some discussion with someone concerning the Exynos mixer and G2D.
The question is the following. Consider the Exynos mixer when run under the IOMMU (that's sysmmu_tv IIRC). What exactly does setup the IOMMU mapping so that the mixer can scanout the framebuffer?
IOMMU mapping is in dma_alloc_attrs(). Already IOMMU was integrated in the DMA mapping API on ARM arch.
There is exynos_gem_map_sgt_with_dma() in the Exynos GEM code, but it's currently exclusively used for the G2D and only when dealing with userptr (and not GEM) there.
I was looking at exynos_drm_alloc_buf() since this called when allocating a BO to be used as scanout.
I see dma_alloc_attrs() being called, which also sets the DMA address that is later used in the mixer code. But DMA_ATTR_NO_KERNEL_MAPPING is passed, so no mapping is done at this point.
Did you read Documentation/DMA-attributes.txt document? DMA_ATTR_NO_KERNEL_MAPPING is just to avoid creating a kernel virtual mapping for the allocated buffer on ARM arch.
Is the mapping done somewhere else, or is it simply not necessary here?
What is the mapping you mean? As you know, the DMA address of the memory gets from dma_alloc_attrs() and it can be used by device. There is no reason to use dma_map_*().
Thanks.
Hello Joonyoung,
Joonyoung Shim wrote:
On 10/31/2015 05:44 AM, Tobias Jakobi wrote:
Hey there,
this question arose during some discussion with someone concerning the Exynos mixer and G2D.
The question is the following. Consider the Exynos mixer when run under the IOMMU (that's sysmmu_tv IIRC). What exactly does setup the IOMMU mapping so that the mixer can scanout the framebuffer?
IOMMU mapping is in dma_alloc_attrs(). Already IOMMU was integrated in the DMA mapping API on ARM arch.
Thanks, I'm going to take a closer look at dma_alloc_attrs() then.
There is exynos_gem_map_sgt_with_dma() in the Exynos GEM code, but it's currently exclusively used for the G2D and only when dealing with userptr (and not GEM) there.
I was looking at exynos_drm_alloc_buf() since this called when allocating a BO to be used as scanout.
I see dma_alloc_attrs() being called, which also sets the DMA address that is later used in the mixer code. But DMA_ATTR_NO_KERNEL_MAPPING is passed, so no mapping is done at this point.
Did you read Documentation/DMA-attributes.txt document?
I did, but I guess I should read it again...
DMA_ATTR_NO_KERNEL_MAPPING is just to avoid creating a kernel virtual mapping for the allocated buffer on ARM arch.
Ah OK, so the IOMMU mapping is always established.
Is the mapping done somewhere else, or is it simply not necessary here?
What is the mapping you mean? As you know, the DMA address of the memory gets from dma_alloc_attrs() and it can be used by device. There is no reason to use dma_map_*(). From my understanding the mixer doesn't directly access the physical
memory when running under IOMMU. It accesses memory through sysmmu_tv, so my question was who does the setup so that sysmmu_tv "knows" how to translate memory accesses.
With best wishes, Tobias
Thanks.
Hi Tobias,
2015년 11월 02일 19:29에 Tobias Jakobi 이(가) 쓴 글:
Hello Joonyoung,
Joonyoung Shim wrote:
On 10/31/2015 05:44 AM, Tobias Jakobi wrote:
Hey there,
this question arose during some discussion with someone concerning the Exynos mixer and G2D.
The question is the following. Consider the Exynos mixer when run under the IOMMU (that's sysmmu_tv IIRC). What exactly does setup the IOMMU mapping so that the mixer can scanout the framebuffer?
IOMMU mapping is in dma_alloc_attrs(). Already IOMMU was integrated in the DMA mapping API on ARM arch.
Thanks, I'm going to take a closer look at dma_alloc_attrs() then.
There is exynos_gem_map_sgt_with_dma() in the Exynos GEM code, but it's currently exclusively used for the G2D and only when dealing with userptr (and not GEM) there.
I was looking at exynos_drm_alloc_buf() since this called when allocating a BO to be used as scanout.
I see dma_alloc_attrs() being called, which also sets the DMA address that is later used in the mixer code. But DMA_ATTR_NO_KERNEL_MAPPING is passed, so no mapping is done at this point.
Did you read Documentation/DMA-attributes.txt document?
I did, but I guess I should read it again...
DMA_ATTR_NO_KERNEL_MAPPING is just to avoid creating a kernel virtual mapping for the allocated buffer on ARM arch.
Ah OK, so the IOMMU mapping is always established.
Is the mapping done somewhere else, or is it simply not necessary here?
What is the mapping you mean? As you know, the DMA address of the memory gets from dma_alloc_attrs() and it can be used by device. There is no reason to use dma_map_*(). From my understanding the mixer doesn't directly access the physical
memory when running under IOMMU. It accesses memory through sysmmu_tv, so my question was who does the setup so that sysmmu_tv "knows" how to translate memory accesses.
That is done by dma-mapping API, dma_alloc_attrs function in case of Exynos DRM.
This dma mapping API calls internally iommu_map function of iommu framework after allocating physical pages and iova space, and the iova space will be mapped with physical pages.
Please, look into the dma mapping framework - arch/arm/mm/dma-mapping.c - if you want to understand. I think you could understand it easily if you tried to look into exynos_drm_alloc_buf function before asking for it.
Thanks, Inki Dae
With best wishes, Tobias
Thanks.
-- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dri-devel@lists.freedesktop.org
-
Inki Dae -
Joonyoung Shim -
Tobias Jakobi