summaryrefslogtreecommitdiffstats
path: root/include/media
diff options
context:
space:
mode:
authorStanimir Varbanov <stanimir.varbanov@linaro.org>2017-08-21 07:34:10 -0400
committerMauro Carvalho Chehab <mchehab@s-opensource.com>2017-08-26 14:15:54 -0400
commit5b6f9abe5a49df81737fbbfba890ee5b093f8168 (patch)
tree4e93b0ae2f3405ff80bb61c4212be27a8f7b03d3 /include/media
parentd533d5010ec373ea06ae4f253d7d69deb3fe0cfd (diff)
downloadlinux-5b6f9abe5a49df81737fbbfba890ee5b093f8168.tar.bz2
media: vb2: add bidirectional flag in vb2_queue
This change is intended to give to the v4l2 drivers a choice to change the default behavior of the v4l2-core DMA mapping direction from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or OUTPUT) to DMA_BIDIRECTIONAL during queue_init time. Initially the issue with DMA mapping direction has been found in Venus encoder driver where the hardware (firmware side) adds few lines padding on bottom of the image buffer, and the consequence is triggering of IOMMU protection faults. This will help supporting venus encoder (and probably other drivers in the future) which wants to map output type of buffers as read/write. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Diffstat (limited to 'include/media')
-rw-r--r--include/media/videobuf2-core.h13
1 files changed, 13 insertions, 0 deletions
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index cb97c224be73..ef9b64398c8c 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -427,6 +427,16 @@ struct vb2_buf_ops {
* @dev: device to use for the default allocation context if the driver
* doesn't fill in the @alloc_devs array.
* @dma_attrs: DMA attributes to use for the DMA.
+ * @bidirectional: when this flag is set the DMA direction for the buffers of
+ * this queue will be overridden with DMA_BIDIRECTIONAL direction.
+ * This is useful in cases where the hardware (firmware) writes to
+ * a buffer which is mapped as read (DMA_TO_DEVICE), or reads from
+ * buffer which is mapped for write (DMA_FROM_DEVICE) in order
+ * to satisfy some internal hardware restrictions or adds a padding
+ * needed by the processing algorithm. In case the DMA mapping is
+ * not bidirectional but the hardware (firmware) trying to access
+ * the buffer (in the opposite direction) this could lead to an
+ * IOMMU protection faults.
* @fileio_read_once: report EOF after reading the first buffer
* @fileio_write_immediately: queue buffer after each write() call
* @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver
@@ -465,6 +475,7 @@ struct vb2_buf_ops {
* Private elements (won't appear at the uAPI book):
* @mmap_lock: private mutex used when buffers are allocated/freed/mmapped
* @memory: current memory type used
+ * @dma_dir: DMA mapping direction.
* @bufs: videobuf buffer structures
* @num_buffers: number of allocated/used buffers
* @queued_list: list of buffers currently queued from userspace
@@ -495,6 +506,7 @@ struct vb2_queue {
unsigned int io_modes;
struct device *dev;
unsigned long dma_attrs;
+ unsigned bidirectional:1;
unsigned fileio_read_once:1;
unsigned fileio_write_immediately:1;
unsigned allow_zero_bytesused:1;
@@ -516,6 +528,7 @@ struct vb2_queue {
/* private: internal use only */
struct mutex mmap_lock;
unsigned int memory;
+ enum dma_data_direction dma_dir;
struct vb2_buffer *bufs[VB2_MAX_FRAME];
unsigned int num_buffers;