Hi Tobias, On 2017-10-20 15:59, Tobias Jakobi wrote:
Hey Marek and others, just wanted to point out that I've also played around with Seung-Woo' patch for a while. However this patch alone is very much incomplete. In particular this is missing: - At least v5 MFC hw needs source buffers to be also writable, so dma mapping needs to be setup bidirectional. - Like with mmap, all buffers need to be setup before decoding can begin. This is due to how MFC hw gets initialized. dmabufs that are added later are not going to be used before MFC hw isn't reinitialized. - Removing dmabufs, or replacing them seems to be impossible with the current code architecture.
Right. Those are limitations of the hardware and in next version of this patch I will
add checks for them.
I had extended samsung-utils with some C++ app to test stuff when I was looking into this. You can find the code here: https://github.com/tobiasjakobi/samsung-utils/tree/devel/v4l2-mfc-drm-direct Now here is what happens. I allocate N buffer objects in DRM land to be used as destination for the MFC decoder. The BOs are exported, so that I can then use them in V4L2 space. I have to queue n (with n < N) buffers before I can start the MFC engine.
According to my knowledge of the MFC HW, if you want to use N buffers with MFC, you have to queue all N buffers to initialize the HW. Otherwise, HW will produce
video data only to the n buffer queued on stream on.
If I do start the engine at that point (n buffers queued), I soon get an IOMMU pagefault. I need to queue all N buffers before anything works at all. Queueing a buffer the first time also registers it, and this has to happen before the MFC hw is initialized. In particular I can't just allocate more buffers from DRM and use them here _after_ decoding has started. To me it looks like the MFC code was never written with dmabuf in mind. It's centered around a static memory setup that is fixed before decoding begins.
That's true, but still, using it with DMA-bufs might be convenient in some cases, even with the above limitations. The IOMMU fault can be mitigated by enabling bidirectional flag on OUTPUT queue. This is a bit strange, but that's how the hardware behaves. From my research it looks that it happens only in case of MFCv5,
higher versions don't modify source stream. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
