Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Am Donnerstag, den 16.04.2015, 10:23 +0200 schrieb Kamil Debski: [...] But, in general, in what kind of scenario would the driver want to call this function, as opposed to vb2 clearing this flag by itself on STREAMOFF? There is VIDIOC_DECODER_CMD / V4L2_DEC_CMD_START. I'd expect this timeline for decoder draining and restart: - userspace calls VIDIOC_DECODER_CMD, cmd=V4L2_DEC_CMD_STOP after queueing the last output buffer to be decoded - the driver processes remaining output buffers into capture buffers and sets the V4L2_BUF_FLAG_LAST set on the last capture Buffet I would like to confirm that it will work with MFC. Am I right that the below will work? Did you take that into account? I see no reason why it wouldn't. The only difference is that userspace has to be able to handle the empty frame. So in MFC's case the V4L2_BUF_FLAG_LAST will be set on the one buffer after the last one and the bytesused of that buffer would be set to 0. The problem of MFC is that it will signal that the last frame was decoded after it was decoded. To particularize: - a frame is decoded, an irq is sent by MFC - we have a new decoded picture - next an irq is sent with an internal MFC flag that the buffer is empty (last picture was already decoded) Doesn't MFC userspace currently stop on the empty frame? That empty frame will still be dequeued as before, the only difference is the added V4L2_BUF_FLAG_LAST on it, and that subsequent calls to DQBUF would return -EPIPE. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi, From: Philipp Zabel [mailto:p.za...@pengutronix.de] Sent: Monday, April 20, 2015 10:28 AM To: Kamil Debski Cc: 'Pawel Osciak'; 'LMML'; 'Hans Verkuil'; 'Laurent Pinchart'; 'Nicolas Dufresne'; 'Sakari Ailus'; ker...@pengutronix.de Subject: Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer Am Donnerstag, den 16.04.2015, 10:23 +0200 schrieb Kamil Debski: [...] But, in general, in what kind of scenario would the driver want to call this function, as opposed to vb2 clearing this flag by itself on STREAMOFF? There is VIDIOC_DECODER_CMD / V4L2_DEC_CMD_START. I'd expect this timeline for decoder draining and restart: - userspace calls VIDIOC_DECODER_CMD, cmd=V4L2_DEC_CMD_STOP after queueing the last output buffer to be decoded - the driver processes remaining output buffers into capture buffers and sets the V4L2_BUF_FLAG_LAST set on the last capture Buffet I would like to confirm that it will work with MFC. Am I right that the below will work? Did you take that into account? I see no reason why it wouldn't. The only difference is that userspace has to be able to handle the empty frame. I just checked the notes from the codec meeting in Dusseldorf. When we talked about the draining flow, we agreed to mention in the documentation that a buffer with the V4L2_BUF_FLAG_LAST can be empty. Thus the userspace applications should check the size of last frame. Could you please add that the last buffer can be empty (zero size) in the DocBook patch? So in MFC's case the V4L2_BUF_FLAG_LAST will be set on the one buffer after the last one and the bytesused of that buffer would be set to 0. The problem of MFC is that it will signal that the last frame was decoded after it was decoded. To particularize: - a frame is decoded, an irq is sent by MFC - we have a new decoded picture - next an irq is sent with an internal MFC flag that the buffer is empty (last picture was already decoded) Doesn't MFC userspace currently stop on the empty frame? That empty frame will still be dequeued as before, the only difference is the added V4L2_BUF_FLAG_LAST on it, and that subsequent calls to DQBUF would return -EPIPE. Ok, I see this. regards Philipp Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi,
From: Philipp Zabel [mailto:p.za...@pengutronix.de]
Sent: Monday, April 13, 2015 6:15 PM
To: Pawel Osciak
Cc: LMML; Hans Verkuil; Kamil Debski; Laurent Pinchart; Nicolas
Dufresne; Sakari Ailus; ker...@pengutronix.de
Subject: Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF
after the last buffer
Hi Pawel,
thanks for the review!
Am Montag, den 13.04.2015, 15:30 +0900 schrieb Pawel Osciak:
Hi,
On Wed, Mar 25, 2015 at 2:46 AM, Philipp Zabel
p.za...@pengutronix.de wrote:
If the last buffer was dequeued from a capture queue, let poll
return immediately and let DQBUF return -EPIPE to signal there will
no more buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the
V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must
explicitly call vb2_clear_last_buffer_queued. The last buffer
queued
flag is cleared automatically during STREAMOFF.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Added DocBook update mentioning DQBUF returning -EPIPE in the
encoder/decoder
stop command documentation.
---
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8
drivers/media/v4l2-core/v4l2-mem2mem.c | 10
+-
drivers/media/v4l2-core/videobuf2-core.c | 18
+-
include/media/videobuf2-core.h | 10
++
6 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
Would it make sense to perhaps split this patch into docbook and vb2
changes please?
Alright, I'll split DocBook from vb2 changes, with the documentation
patches first.
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 80c588f..1b5b432 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file,
struct v4l2_m2m_ctx *m2m_ctx,
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
- if (list_empty(dst_q-done_list))
+ if (list_empty(dst_q-done_list)) {
+ /*
+* If the last buffer was dequeued from the capture
queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (dst_q-last_buffer_dequeued)
+ return rc | POLLIN | POLLRDNORM;
These indicate there is data to be read. Is there something else we
could return? Maybe POLLHUP?
This is a good point, but I'm not sure. POLLHUP seems to mean a similar
thing, yet not quite the same. The documentation explicitly mentions
disconnected devices or FIFOs without writers, neither of which applies.
Also a FIFO signals POLLHUP when the last writer leaves, so we would
probably have to signal POLLHUP|POLLIN after the last buffer was
decoded for consistency, and keep that until the last buffer is
dequeued. Then we could signal POLLHUP alone here.
I didn't want to risk redefining/misinterpreting any poll(2) behavior,
so my interpretation was that POLLIN signals userspace to try a DQBUF,
as usual.
+
poll_wait(file, dst_q-done_wq, wait);
+ }
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..a0b9946 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2046,6 +2046,10 @@ static int vb2_internal_dqbuf(struct
vb2_queue *q, struct v4l2_buffer *b, bool n
struct vb2_buffer *vb = NULL;
int ret;
+ if (q-last_buffer_dequeued) {
+ dprintk(3, last buffer dequeued already\n);
+ return -EPIPE;
+ }
This should go after the check for queue type at least. However, best
probably to __vb2_wait_for_done_vb(), where we already have the
checks
for q-streaming and q-error.
Yes, that'll be better.
if (b-type != q-type) {
dprintk(1, invalid buffer type\n);
return -EINVAL;
[...]
@@ -2628,8 +2636,16 @@ unsigned int vb2_poll(struct vb2_queue *q,
struct file *file, poll_table *wait)
if (V4L2_TYPE_IS_OUTPUT(q-type) q-queued_count q-
num_buffers)
return res | POLLOUT | POLLWRNORM;
- if (list_empty(q-done_list))
+ if (list_empty(q-done_list
Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi,
On Wed, Mar 25, 2015 at 2:46 AM, Philipp Zabel p.za...@pengutronix.de wrote:
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must explicitly
call vb2_clear_last_buffer_queued. The last buffer queued flag is
cleared automatically during STREAMOFF.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Added DocBook update mentioning DQBUF returning -EPIPE in the
encoder/decoder
stop command documentation.
---
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8
drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +-
drivers/media/v4l2-core/videobuf2-core.c | 18
+-
include/media/videobuf2-core.h | 10 ++
6 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
Would it make sense to perhaps split this patch into docbook and vb2
changes please?
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 80c588f..1b5b432 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
- if (list_empty(dst_q-done_list))
+ if (list_empty(dst_q-done_list)) {
+ /*
+* If the last buffer was dequeued from the capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (dst_q-last_buffer_dequeued)
+ return rc | POLLIN | POLLRDNORM;
These indicate there is data to be read. Is there something else we
could return? Maybe POLLHUP?
+
poll_wait(file, dst_q-done_wq, wait);
+ }
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..a0b9946 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2046,6 +2046,10 @@ static int vb2_internal_dqbuf(struct vb2_queue *q,
struct v4l2_buffer *b, bool n
struct vb2_buffer *vb = NULL;
int ret;
+ if (q-last_buffer_dequeued) {
+ dprintk(3, last buffer dequeued already\n);
+ return -EPIPE;
+ }
This should go after the check for queue type at least. However, best
probably to __vb2_wait_for_done_vb(), where we already have the checks
for q-streaming and q-error.
if (b-type != q-type) {
dprintk(1, invalid buffer type\n);
return -EINVAL;
@@ -2073,6 +2077,9 @@ static int vb2_internal_dqbuf(struct vb2_queue *q,
struct v4l2_buffer *b, bool n
/* Remove from videobuf queue */
list_del(vb-queued_entry);
q-queued_count--;
+ if (!V4L2_TYPE_IS_OUTPUT(q-type)
+ vb-v4l2_buf.flags V4L2_BUF_FLAG_LAST)
+ q-last_buffer_dequeued = true;
/* go back to dequeued state */
__vb2_dqbuf(vb);
@@ -2286,6 +2293,7 @@ static int vb2_internal_streamoff(struct vb2_queue *q,
enum v4l2_buf_type type)
*/
__vb2_queue_cancel(q);
q-waiting_for_buffers = !V4L2_TYPE_IS_OUTPUT(q-type);
+ q-last_buffer_dequeued = false;
dprintk(3, successful\n);
return 0;
@@ -2628,8 +2636,16 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
if (V4L2_TYPE_IS_OUTPUT(q-type) q-queued_count q-num_buffers)
return res | POLLOUT | POLLWRNORM;
- if (list_empty(q-done_list))
+ if (list_empty(q-done_list)) {
+ /*
+* If the last buffer was dequeued from a capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (!V4L2_TYPE_IS_OUTPUT(q-type) q-last_buffer_dequeued)
Do we need to check !V4L2_TYPE_IS_OUTPUT(q-type) here? We wouldn't
have set last_buffer_dequeued to true if it wasn't, so we could drop
this check?
+ return res | POLLIN | POLLRDNORM;
Same comment as above.
+
poll_wait(file, q-done_wq, wait);
+ }
/*
* Take first buffer available for dequeuing.
diff --git
Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi Pawel,
thanks for the review!
Am Montag, den 13.04.2015, 15:30 +0900 schrieb Pawel Osciak:
Hi,
On Wed, Mar 25, 2015 at 2:46 AM, Philipp Zabel p.za...@pengutronix.de wrote:
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must explicitly
call vb2_clear_last_buffer_queued. The last buffer queued flag is
cleared automatically during STREAMOFF.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Added DocBook update mentioning DQBUF returning -EPIPE in the
encoder/decoder
stop command documentation.
---
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8
drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +-
drivers/media/v4l2-core/videobuf2-core.c | 18
+-
include/media/videobuf2-core.h | 10 ++
6 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
Would it make sense to perhaps split this patch into docbook and vb2
changes please?
Alright, I'll split DocBook from vb2 changes, with the documentation
patches first.
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 80c588f..1b5b432 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
- if (list_empty(dst_q-done_list))
+ if (list_empty(dst_q-done_list)) {
+ /*
+* If the last buffer was dequeued from the capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (dst_q-last_buffer_dequeued)
+ return rc | POLLIN | POLLRDNORM;
These indicate there is data to be read. Is there something else we
could return? Maybe POLLHUP?
This is a good point, but I'm not sure. POLLHUP seems to mean a similar
thing, yet not quite the same. The documentation explicitly mentions
disconnected devices or FIFOs without writers, neither of which applies.
Also a FIFO signals POLLHUP when the last writer leaves, so we would
probably have to signal POLLHUP|POLLIN after the last buffer was decoded
for consistency, and keep that until the last buffer is dequeued. Then
we could signal POLLHUP alone here.
I didn't want to risk redefining/misinterpreting any poll(2) behavior,
so my interpretation was that POLLIN signals userspace to try a DQBUF,
as usual.
+
poll_wait(file, dst_q-done_wq, wait);
+ }
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..a0b9946 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2046,6 +2046,10 @@ static int vb2_internal_dqbuf(struct vb2_queue *q,
struct v4l2_buffer *b, bool n
struct vb2_buffer *vb = NULL;
int ret;
+ if (q-last_buffer_dequeued) {
+ dprintk(3, last buffer dequeued already\n);
+ return -EPIPE;
+ }
This should go after the check for queue type at least. However, best
probably to __vb2_wait_for_done_vb(), where we already have the checks
for q-streaming and q-error.
Yes, that'll be better.
if (b-type != q-type) {
dprintk(1, invalid buffer type\n);
return -EINVAL;
[...]
@@ -2628,8 +2636,16 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
file *file, poll_table *wait)
if (V4L2_TYPE_IS_OUTPUT(q-type) q-queued_count
q-num_buffers)
return res | POLLOUT | POLLWRNORM;
- if (list_empty(q-done_list))
+ if (list_empty(q-done_list)) {
+ /*
+* If the last buffer was dequeued from a capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (!V4L2_TYPE_IS_OUTPUT(q-type)
q-last_buffer_dequeued)
Do we need to check !V4L2_TYPE_IS_OUTPUT(q-type) here? We wouldn't
have set last_buffer_dequeued to true if it wasn't, so we could drop
this check?
Indeed we don't. I'll drop the check.
+
[PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must explicitly
call vb2_clear_last_buffer_queued. The last buffer queued flag is
cleared automatically during STREAMOFF.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Added DocBook update mentioning DQBUF returning -EPIPE in the encoder/decoder
stop command documentation.
---
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8
drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +-
drivers/media/v4l2-core/videobuf2-core.c | 18 +-
include/media/videobuf2-core.h | 10 ++
6 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
index cbb7135..2601c37 100644
--- a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
@@ -200,7 +200,9 @@ set the picture to black after it stopped decoding.
Otherwise the last image wil
repeat. mem2mem decoders will stop producing new frames altogether. They will
send
a constantV4L2_EVENT_EOS/constant event after the last frame was decoded
and
will set the constantV4L2_BUF_FLAG_LAST/constant buffer flag when there
will
-be no new buffers produced to dequeue.
+be no new buffers produced to dequeue. Once this flag was set, the
+link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will not block anymore,
+but return an EPIPE;.
If constantV4L2_DEC_CMD_STOP_IMMEDIATELY/constant is set, then the decoder
stops immediately (ignoring the structfieldpts/structfield value),
otherwise it
will keep decoding until timestamp = pts or until the last of the pending
data from
diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
index e9cf601..def688f 100644
--- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
@@ -132,7 +132,9 @@ When the encoder is already stopped, this command does
nothing. mem2mem encoders will send a constantV4L2_EVENT_EOS/constant event
after the last frame was encoded and will set the
constantV4L2_BUF_FLAG_LAST/constant buffer flag on the capture queue when
-there will be no new buffers produced to dequeue/entry
+there will be no new buffers produced to dequeue. Once this flag was set, the
+link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will not block anymore,
+but return an EPIPE;./entry
/row
row
entryconstantV4L2_ENC_CMD_PAUSE/constant/entry
diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
index 3504a7f..6cfc53b 100644
--- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
@@ -186,6 +186,14 @@ In that case the application should be able to safely
reuse the buffer and
continue streaming.
/para
/listitem
+ termerrorcodeEPIPE/errorcode/term
+ listitem
+ paraconstantVIDIOC_DQBUF/constant returns this on an empty
+capture queue for mem2mem codecs if a buffer with the
+constantV4L2_BUF_FLAG_LAST/constant was already dequeued and no new buffers
+are expected to become available.
+ /para
+ /listitem
/varlistentry
/variablelist
/refsect1
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 80c588f..1b5b432 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
- if (list_empty(dst_q-done_list))
+ if (list_empty(dst_q-done_list)) {
+ /*
+* If the last buffer was dequeued from the capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (dst_q-last_buffer_dequeued)
+ return rc | POLLIN | POLLRDNORM;
+
poll_wait(file, dst_q-done_wq, wait);
+ }
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..a0b9946 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@
