Hi I am facing an issue while using videobuf2-dma-contig.c mem_ops. Following is brief description of the driver architecture and the limitation. Any pointers/hints are appreciated. Driver architecture: It is a video codec driver for video decoding. It exposes two ports - CAPTURE and OUTPUT. Raw bitstream buffers are queued/dequeued via OUTPUT capability and YUV via CAPTURE. This driver uses vb2_qops as well as vb2_mem_ops from videobuf2-dma-contig.c. Video hardware has MMU. V4L2 framework limitation: The empty buffers are allocated by userspace and file descriptor is queued to the V4L2 driver via VIDIOC_QBUF call. I am using vb2_mem_ops so the buffers are mapped into video device's MMU by map_dmabuf op. Then video driver sends this buffer down to hardware and hardware does the decoding and writes YUV data in this buffer. This buffer is ready to be shared with userspace so hardware returns this buffer back to driver. Userspace calls VIDIOC_DQBUF to get the buffer but as a result the buffer is also unmapped from video device's MMU. This is because DQBUF calls unmap_dmabuf op. This causes problem because video device will still need this buffer so future frames referencing to it can be decoded properly. Has anyone else faced this problem? Is there a patch for reference counting the MMU mappings/unmappings so that driver has more control over it? Thanks Vinay -- 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
