Hi Yuji, On 10/24/22 06:02, yuji2.ishikawa@xxxxxxxxxxxxx wrote: > Hi, > > I'm porting a V4L2 capture driver from 4.19.y to 5.10.y [1]. > > When I test the ported driver, I sometimes find a corruption on a captured image. > > Because the corruption is exactly aligned with cacheline, I started investigation from map/unmap of DMA-BUF. > > > > The capture driver uses DMA-BUF for videobuf2. > > The capture hardware does not have HW-mantained cache coherency with CPU, that is, explicit map/unmap is essential on QBUF/DQBUF. > > After some hours of struggle, I found a patch removing cache synchronizations on QBUF/DQBUF. > > > > https://patchwork.kernel.org/project/linux-media/patch/20190124095156.21898-1-paul.kocialkowski@xxxxxxxxxxx/ <https://patchwork.kernel.org/project/linux-media/patch/20190124095156.21898-1-paul.kocialkowski@xxxxxxxxxxx/> > > > > When I removed this patch from my 5.10.y working-tree, the driver yielded images without any defects.v > > > > *************** > > Sorry for a mention to a patch released 4 years ago. > > The patch removes map/unmap on QBUF/DQBUF to improve the performance of V4L2 decoder device, by reusing previously decoded frames. > > However, there seems no cares nor compensations for modifying lifecycle of DMA-BUF, especially on video capture devices. I'm not entirely sure what you mean exactly. > > > > Would you tell me some idea on this patch: > > * Do well-implemented capture drivers work well even if this patch is applied? Yes, dmabuf is used extensively and I have not had any reports of issues. > > * How should a video capture driver call V4L2/videobuf2 APIs, especially when the hardware does not support cache coherency? It should all be handled correctly by the core frameworks. I think you need to debug more inside videobuf2-core.c. Some printk's that show the dmabuf fd when the buffer is mapped and when it is unmapped + the length it is mapping should hopefully help a bit. Regards, Hans > > > > *************** > > [1] FYI: the capture driver is not on mainline yet; the candidate is, > > https://lore.kernel.org/all/20220810132822.32534-1-yuji2.ishikawa@xxxxxxxxxxxxx/ <https://lore.kernel.org/all/20220810132822.32534-1-yuji2.ishikawa@xxxxxxxxxxxxx/> > > > > > > Regards, > > Yuji Ishikawa >
