]> git.baikalelectronics.ru Git - kernel.git/commit
drm: rcar-du: Set the DMA coherent mask for the DU device
authorLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Sun, 12 Nov 2017 12:12:10 +0000 (14:12 +0200)
committerLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Thu, 7 Oct 2021 02:42:05 +0000 (05:42 +0300)
commit3586e036d7b72382b3f3ad096564b61783f5344b
tree47681c18e1e60c1af565ab540ee436baa63075d0
parentd452a6ec6309d101060d4e81ad8bd0458b03f7ed
drm: rcar-du: Set the DMA coherent mask for the DU device

The DU DMA address space is limited to 32 bits, so the DMA coherent mask
should be set accordingly. The DMA mapping implementation will
transparently map high memory buffers to 32-bit addresses through an
IOMMU when present (or through bounce buffers otherwise, which isn't a
supported use case as performances would be terrible).

However, when sourcing frames from a VSP, the situation is more
complicated. The DU delegates all memory accesses to the VSP and doesn't
perform any DMA access by itself. Due to how the GEM CMA helpers are
structured buffers are still mapped to the DU device. They are later
mapped to the VSP as well to perform DMA access, through the IOMMU
connected to the VSP.

Setting the DMA coherent mask to 32 bits for the DU when using a VSP can
cause issues when importing a dma_buf. If the buffer is located above
the 32-bit address space, the DMA mapping implementation will try to map
it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer
will be allocated, which in the best case will waste memory and in the
worst case will just fail.

To work around this issue, set the DMA coherent mask to the full 40-bit
address space for the DU. All dma-buf instances will be imported without
any restriction, and will be mapped to the VSP when preparing the
associated framebuffer.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
drivers/gpu/drm/rcar-du/rcar_du_drv.c