>Pawel Osciak [mailto:p.osciak@xxxxxxxxxxx] wrote: >>> +unsigned int v4l2_m2m_poll(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, >>> + struct poll_table_struct *wait) >>> +{ >>> + struct videobuf_queue *dst_q; >>> + struct videobuf_buffer *vb = NULL; >>> + unsigned int rc = 0; >>> + >>> + dst_q = v4l2_m2m_get_dst_vq(m2m_ctx); >>> + >>> + mutex_lock(&dst_q->vb_lock); >>> + >>> + if (dst_q->streaming) { >>> + if (!list_empty(&dst_q->stream)) >>> + vb = list_entry(dst_q->stream.next, >>> + struct videobuf_buffer, stream); >>> + } >>> + >>> + if (!vb) >>> + rc = POLLERR; >>> + >>> + if (0 == rc) { >>> + poll_wait(file, &vb->done, wait); >>> + if (vb->state == VIDEOBUF_DONE || vb->state == VIDEOBUF_ERROR) >>> + rc = POLLOUT | POLLRDNORM; >>> + } >>> + >>> + mutex_unlock(&dst_q->vb_lock); >> >>Would there be any need for polling for writing? > >Something has to be chosen, we could be polling for both of course, but in >my opinion in case of m2m devices we are usually interested in the result >of the operation. And in a great majority of cases (1:1 src:dst buffers) this >will also mean src buffer is ready as well. Besides, the app can always simply >sleep on dqbuf in one thread. > On second thought, we could set both and let the application use it as it sees fit... Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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
