Tomasz,
I've encountered an issue with this patch when userspace does several
stream_on/stream_off cycles. When the user tries to qbuf a buffer
after doing stream_off, we trigger the "dmabuf already pinned" warning
since we didn't unmap the buffer as dqbuf was never called.
The below patch adds calls to unmap in queue_cancel, but my feeling is that we
probably should be calling detach too (i.e. put_dmabuf).
Thoughts?
--Dima
Subject: [PATCH] v4l: vb2: unmap dmabufs on STREAM_OFF event
Currently, if the user issues a STREAM_OFF request and then
tries to re-enqueue buffers, it will trigger a warning in
the vb2 allocators as the buffer would still be mapped
from before STREAM_OFF was called. The current expectation
is that buffers will be unmapped in dqbuf, but that will never
be called on the mapped buffers after a STREAM_OFF event.
Cc: Sumit Semwal <sumit.semwal@xxxxxx>
Cc: Tomasz Stanislawski <t.stanislaws@xxxxxxxxxxx>
Signed-off-by: Dima Zavin <dima@xxxxxxxxxxx>
---
drivers/media/video/videobuf2-core.c | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c
index b431dc6..e2a8f12 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1592,8 +1592,26 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
/*
* Reinitialize all buffers for next use.
*/
- for (i = 0; i < q->num_buffers; ++i)
- q->bufs[i]->state = VB2_BUF_STATE_DEQUEUED;
+ for (i = 0; i < q->num_buffers; ++i) {
+ struct vb2_buffer *vb = q->bufs[i];
+ int plane;
+
+ vb->state = VB2_BUF_STATE_DEQUEUED;
+
+ if (q->memory != V4L2_MEMORY_DMABUF)
+ continue;
+
+ for (plane = 0; plane < vb->num_planes; ++plane) {
+ struct vb2_plane *p = &vb->planes[plane];
+
+ if (!p->mem_priv)
+ continue;
+ if (p->dbuf_mapped) {
+ call_memop(q, unmap_dmabuf, p->mem_priv);
+ p->dbuf_mapped = 0;
+ }
+ }
+ }
}
/**
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
