OSDN Git Service

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)
commit780d4223f662167fa0a58a98b09c20e3e173c0cc
tree47681c18e1e60c1af565ab540ee436baa63075d0
parent206c54710882d85b838f1899fd58adf8bad9454c
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