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
