Tried to add MFC hardware encoder support

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 2014 02 26 07:39, Nicolas Dufresne wrote:
> Le mardi 25 février 2014 à 20:56 +0100, Sebastian Dröge a écrit :
>> No, the only documentation is the source code. But that's exactly
>> why v4l2videodec is better. v4l2 is not simple and the code in
>> mfcdec is only covering a very specific case and gets that
>> working. For a generic video decoder element you'll have to do so
>> much more.
> 
> The decoder has now been merged today and can be found in git
> master. The complexity of the code is not higher then expected
> considering this element fully probes and negotiate. Userptr
> support and dmabuf will add up slightly to this complexity, but
> still seems under control. It also implements buffers pools, which
> helps to avoid copies. Also, this implementation is not bound to
> the FIMC, which has multiple drivers.
> 
About FIMC, I found it is in the decoder in old code, I thought it had
better to be a independent element as "FIMC-IS V1.5 has
many sub-blocks for image processing as well as an ARM core" from
samsung document.
> If you have more specific question, or need to understand something
> in particular, feel free to ask here or on freenode #gstreamer (I'm
> stormer over there). I will most likely ignore patches to mfcdec
> from now on.
> 
Thank you I will. One problem of my code is that it takes too much cpu
resource(frequently using memcpy), I will try to fix this problem
first and then try to commit it to gstreamer.
> From Exynos stand point, it has been tested mostly on kernel 3.8,
> but it is known to work on Cotton Candy 3.4 kernel, with some
> visible bugs due to bugs in that version of the driver (I can
> explain the work around as needed, but not going to maintain it in
> GStreamer). In most cases, increasing the CMA reservation size will
> help. I have still been unable to test on git master mostly because
> of a lack of time figuring out why the CMA reservation does not
> happen on DT kernel. Mainline kernel also has bugs in the format it
> expose on Exynos 4 (e.g. it exposes VP8 even if only supported on
> Exynos 5) fixing the kernel should be simple in this case.
> 
I have tested my code in kernel 3.5 in FriendlyARM tiny4412.
In the recent kernel, it seems that it doesn't use CMA anymore, it use
dma_alloc_coherent instead of using vb2_dma_contig_memops.alloc in 3.5.
I have trid increasing the CMA reservation size but no use, you can
find it in linux-media mail list
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/74373/
.
Another problem, as I know that the kernel 3.8 is not a DT fully
kernel for exynos4, then how many drivers are supported in that
kernel? If the usb phy and mmc can be able to work I will try to port
a kernel to 3.8.
> For your interest, I'm currently working on an GStreamer element
> that wraps the v42l-m2m FIMC driver, in order to provide hardware
> accelerated conversion. My goal is to be able to get buffers in a
> format the Mali understand (for texture streaming). On the roadmap,
> I also need to enabled dynamic resolution change, correctly handle
> non-top-left aligned cropping (maybe manual cropping if downstream
> don't support it?). Any kind of help is welcome.
> 
I am sorry I don't know anything about that, but I have SEC document
of exynos 4412, if you need, I can offer the information for you.
> cheers, Nicolas

Thank you

ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJTDWqtAAoJEPb4VsMIzTzi8ZwIALnNF8tRVd0Qn6ThXI8jCK86
VMSX4tkQRERs+BGJGE1+Nlsc0SNqe1GY2fr7EYJJ/7ncTIjumGNwV9l3JoSKVOZY
bEx9xBkuaxD1jDgrP3R2XBcOoh331NDOk4CTSgLMOBGfGZ3OQu+FiWr1IZOspin/
Acuy24PCMLfZ6dP8zS+nSvzD4UhVEdrE5nOKkYiTSA88rmipfd3KBa5sO7l1hvkT
MrHMKwXxen/mDfdscn3xh4u4Sk+W77VOLcCdniQUSKM4YitaPWZGKtSEoAhkoZq8
YQi3bKnKycMKGbNFHzuhDMdxllpNi8s2Cr9QGhv/vN+geqgzwGnqLMidFxi3DWI=
=Szg7
-----END PGP SIGNATURE-----