Le mardi 13 mars 2018 à 21:09 -0400, Nicolas Dufresne a écrit : > > I've looked into this again. I have hit the same issue but with CPU > > to > > DRM, using DMABuf allocated from DRM Dumb buffers. In that case, > > using > > DMA_BUF_IOCTL_SYNC fixes the issues. > > > > This raises a lot of question around the model used in V4L2. As you > > mention, prepare/finish are missing in dma-vmalloc mem_ops. I'll > > give > > a > > try implementing that, it should cover my initial use case, but > > then > > I > > believe it will fail if my pipeline is: > > > > UVC -> in plane CPU modification -> DRM > > > > Because we don't implement begin/end_cpu_access on our exported > > DMABuf. > > It should also fail for the following use case: > > > > UVC (importer) -> DRM > > > > UVC driver won't call the remote dmabuf being/end_cpu_access > > method. > > This one is difficult because UVC driver and vivid don't seem to be > > aware of being an importer, exported or simply exporting to CPU > > (through mmap). I believe what we have now pretty much assumes the > > what > > we export as vmalloc is to be used by CPU only. Also, the usual > > direction used by prepare/finish ops won't work for drivers like > > vivid > > and UVC that write into the buffers using the cpu. > > > > To be continued ... > > While I was writing that, I was already outdated, as of now, we only > have one ops, called sync. This implements the to_cpu direction only. Replying to myself again, obviously looking at the old videobuf code can only get one confused. Nicolas
