[PATCH RFC v2 05/11] remoteproc: virtio: report VIRTIO_F_ACCESS_PLATFORM when required

[Francesco Valla]

Depending on the driver originating them, data buffers used for virtio
communication can either:

  - already be allocated from the coherent memory area that is
    accessible by the remote processor; this is the case of
    remoteproc-specific virtio devices, i.e., rpmsg and rproc-serial;
  - be allocated from generic kmem, and thus not necessarily accessible
    directly by the remote processor.

In the second case, the DMA APIs can be exploited to obtain a
functional communication, since they will take care of cache maintenance
and - if required - bounce buffering. The VIRTIO_F_ACCESS_PLATFORM
feature flag can be used for this purpose: with it set, the virtio
framework will use the aforementioned DMA APIs to map and unmap buffers.

Bounce buffering will be transparently used in two cases:

  - if the buffer address supplied by the virtio driver is not suitable
    for DMA transfers, or
  - if the reserved memory associated to the vdev is a
    restricted-dma-pool; in this case, *all* buffers will be bounced to
    and from this pool.

With this support in place, any kind of virtio device can be supported
through the remoteproc-virtio transport, at least from a data exchange
standpoint.

Note that remote processors behind an IOMMU need da == pa for the memory
region(s) the buffers are allocated from.

Existing use cases (e.g., rpmsg and virtio-console) are not impacted as
they are explicitly excluded.

Signed-off-by: Francesco Valla <francesco at valla.it>
---
 drivers/remoteproc/remoteproc_virtio.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
index f1b362158a9c..1496659ddff9 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -280,9 +280,14 @@ static u64 rproc_virtio_get_features(struct virtio_device *vdev)
 	 * All non-remoteproc-specific virtio devices are assumed to be
 	 * compliant with virtio specifications 1.x; there is no other method
 	 * to transmit this capability from the remote processor to the host.
+	 *
+	 * Virtio devices that are specific for remoteproc usage take care on
+	 * their own to allocate memory from the device's coherent pool; use
+	 * the DMA APIs for the others through VIRTIO_F_ACCESS_PLATFORM.
 	 */
 	if (!rproc_virtio_rsc_vdev_rproc_specific(rsc))
-		features |= (1ULL << VIRTIO_F_VERSION_1);
+		features |= ((1ULL << VIRTIO_F_VERSION_1) |
+			     (1ULL << VIRTIO_F_ACCESS_PLATFORM));
 
 	return features;
 }
@@ -312,7 +317,8 @@ static int rproc_virtio_finalize_features(struct virtio_device *vdev)
 	features = vdev->features;
 
 	if (!rproc_virtio_rsc_vdev_rproc_specific(rsc))
-		features &= ~(1ULL << VIRTIO_F_VERSION_1);
+		features &= ~((1ULL << VIRTIO_F_VERSION_1) |
+			      (1ULL << VIRTIO_F_ACCESS_PLATFORM));
 
 	if (WARN_ON((u32)vdev->features != features))
 		return -EINVAL;

-- 
2.56.0