[PATCH v2 0/5] R-Car DU: Fix IOMMU operation when connected to VSP

[Laurent Pinchart]

Hello,

This patch series fixes the rcar-du-drm driver to support VSP plane sources
with an IOMMU. It is available for convenience at

        git://linuxtv.org/pinchartl/media.git iommu/devel/du

On R-Car Gen3 the DU has no direct memory access but sources planes through
VSP instances. When an IOMMU is inserted between the VSP and memory, the DU
framebuffers need to be DMA mapped using the VSP device, not the DU device as
currently done. The same situation can also be reproduced on Gen2 hardware by
linking the VSP to the DU in DT [1], effectively disabling direct memory
access by the DU.

The situation is made quite complex by the fact that different planes can be
connected to different DU instances, and thus served by different IOMMUs (or,
in practice on existing hardware, by the same IOMMU but through different
micro-TLBs). We thus can't allocate and map buffers to the right device in a
single dma_alloc_wc() operation as done in the DRM CMA GEM helpers.

However, on such setups, the DU DT node doesn't reference IOMMUs as the DU
does not perform any direct memory access. We can thus keep the GEM object
allocation unchanged, and the DMA addresses that we receive in the DU driver
will be physical addresses. Those buffers then need to be mapped to the VSP
device when they are associated with planes. Fortunately the atomic framework
provides two plane helper operations, .prepare_fb() and .cleanup_fb() that we
can use for this purpose.

The reality is slightly more complex than this on Gen3, as an FCP device
instance sits between VSP instances and memory. It is the FCP devices that are
connected to the IOMMUs, and buffer mapping thus need to be performed using
the FCP devices. This isn't required on Gen2 as the platforms don't have any
FCPs.

Patches 1/5 and 2/5 extend the rcar-fcp driver API to expose the FCP struct
device. Patch 3/5 then updates the vsp1 driver to map the display lists and
video buffers through the FCP when it exists. This alone fixes VSP operation
with an IOMMU on R-Car Gen3 systems.

Moving on to addressing the DU issue, patch 4/5 extends the vsp1 driver API to
allow mapping a scatter-gather list to the VSP, with the implementation using
the FCP devices instead when available. Patch 5/5 finally uses the vsp1
mapping API in the rcar-du-drm driver to map and unmap buffers when needed.

The series has been tested on the H2 Lager board and M3-W Salvator-X boards.
The IOMMU is known not to work properly on the H3 ES1.1, so the H3 Salvator-X
board hasn't been tested. In all cases both the DU and VSP operation has been
tested, and tests were run with and without linking the DU and VSP devices to
the IOMMU in DT.

For H2, the patches were tested on top of v4.12-rc1 with a set of out-of-tree
patches to link the VSP and DU to the IOMMUs and to enable VSP+DU combined
similar to R-Car Gen3, and an additional DMA mapping API patch [2] that fixes
IOMMU operation on ARM32, currently broken in v4.12-rc1. For M3-W, they were
were tested on top of renesas-drivers-2017-05-16-v4.12-rc1 with a set of
out-of-tree patches to add FCP, VSP, DU and IPMMU instances to the M3-W DT, as
well as a hack for the IPMMU driver to whitelist all bus master devices.

All tests passed successfully. The issue previously noticed on H3 with
synchronization between page flip and VSP operation that was caused by buffers
getting unmapped (and possibly freed) before the VSP was done reading them is
now gone thanks to the VSP+DU flicker fix that should be merged in v4.13 and
is available in renesas-drivers-2017-05-16-v4.12-rc1.

A possible improvement is to modify the GEM object allocation mechanism to use
non-contiguous memory when the DU driver detects that all the VSP instances it
is connected to use an IOMMU (possibly through FCP devices).

[1] https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg06589.html
[2] https://www.spinics.net/lists/arm-kernel/msg581410.html

Laurent Pinchart (4):
  v4l: rcar-fcp: Don't get/put module reference
  v4l: rcar-fcp: Add an API to retrieve the FCP device
  v4l: vsp1: Add API to map and unmap DRM buffers through the VSP
  drm: rcar-du: Map memory through the VSP device

Magnus Damm (1):
  v4l: vsp1: Map the DL and video buffers through the proper bus master

 drivers/gpu/drm/rcar-du/rcar_du_vsp.c    | 74 +++++++++++++++++++++++++++++---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h    |  2 +
 drivers/media/platform/rcar-fcp.c        | 17 ++++----
 drivers/media/platform/vsp1/vsp1.h       |  1 +
 drivers/media/platform/vsp1/vsp1_dl.c    |  4 +-
 drivers/media/platform/vsp1/vsp1_drm.c   | 25 +++++++++++
 drivers/media/platform/vsp1/vsp1_drv.c   |  9 ++++
 drivers/media/platform/vsp1/vsp1_video.c |  2 +-
 include/media/rcar-fcp.h                 |  5 +++
 include/media/vsp1.h                     |  3 ++
 10 files changed, 124 insertions(+), 18 deletions(-)

-- 
Regards,

Laurent Pinchart