[PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Marian Mihailescu]

Hi,

After testing these patches, encoding using MFC fails when requesting
buffers for capture (it works for output) with ENOMEM (it complains it
cannot allocate memory on bank1).
Did anyone else test encoding?

Thanks,
Marian

Either I've been missing something or nothing has been going on. (K. E. Gordon)

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Javier Martinez Canillas]

Hello Marian,

On Wed, Mar 15, 2017 at 8:36 AM, Marian Mihailescu
<mihailescu2m@gmail.com> wrote:
> Hi,
>
> After testing these patches, encoding using MFC fails when requesting
> buffers for capture (it works for output) with ENOMEM (it complains it
> cannot allocate memory on bank1).
> Did anyone else test encoding?
>

I've not tested encoding, but I did test decoding and it works for me
with Shuah's patch to increase the CMA memory [0]. Did you test with
that one as well?

Also you could try using the 5p_mfc.mem kernel param as explained in
the commit message of "media: s5p-mfc: Add support for probe-time
preallocated block based allocator".

[0]: https://patchwork.kernel.org/patch/9596737/

> Thanks,
> Marian
>

Best regards,
Javier

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Marian Mihailescu]

Thanks for the quick reply.

Decoding works without issues for me too.
I did not change the CMA size or used s5p_mfc.mem parameter. However, according to the Marek, the default 8M should be enough for 3 instances of H264 encoders/decoders. My test was encoding a 30 seconds 720p clip, so I thought memory should not be a big issue; also it’s working w/o these patches applied, so I think CMA size is enough.
Nevertheless, I will try setting them, but I would feel better if someone else would try encoding too.

Cheers,
Marian

> On 15 Mar. 2017, at 10:19 pm, Javier Martinez Canillas <javier@dowhile0.org> wrote:
> 
> Hello Marian,
> 
> On Wed, Mar 15, 2017 at 8:36 AM, Marian Mihailescu
> <mihailescu2m@gmail.com> wrote:
>> Hi,
>> 
>> After testing these patches, encoding using MFC fails when requesting
>> buffers for capture (it works for output) with ENOMEM (it complains it
>> cannot allocate memory on bank1).
>> Did anyone else test encoding?
>> 
> 
> I've not tested encoding, but I did test decoding and it works for me
> with Shuah's patch to increase the CMA memory [0]. Did you test with
> that one as well?
> 
> Also you could try using the 5p_mfc.mem kernel param as explained in
> the commit message of "media: s5p-mfc: Add support for probe-time
> preallocated block based allocator".
> 
> [0]: https://patchwork.kernel.org/patch/9596737/
> 
>> Thanks,
>> Marian
>> 
> 
> Best regards,
> Javier

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Javier Martinez Canillas]

Hello Marian,

On Wed, Mar 15, 2017 at 9:00 AM, Marian Mihailescu
<mihailescu2m@gmail.com> wrote:
> Thanks for the quick reply.
>
> Decoding works without issues for me too.
> I did not change the CMA size or used s5p_mfc.mem parameter. However, according to the Marek, the default 8M should be enough for 3 instances of H264 encoders/decoders. My test was encoding a 30 seconds 720p clip, so I thought memory should not be a big issue; also it’s working w/o these patches applied, so I think CMA size is enough.
> Nevertheless, I will try setting them, but I would feel better if someone else would try encoding too.
>

Ok, I thought it may be that because Shuah and I needed to increase
the CMA size in order to decode a H.264 1080p video.

But if decoding is working correctly for you and only fails on
encoding, then I'm afraid that I won't be able to help you since as
mentioned I didn't test that.

> Cheers,
> Marian
>

Best regards,
Javier

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Andrzej Hajda]

Hi Marian,

On 15.03.2017 12:36, Marian Mihailescu wrote:
> Hi,
> 
> After testing these patches, encoding using MFC fails when requesting
> buffers for capture (it works for output) with ENOMEM (it complains it
> cannot allocate memory on bank1).
> Did anyone else test encoding?

I have tested encoding and it works on my test target. Could you provide
more details of your setup:
- which kernel and patches,
- which hw,
- which test app.

Regards
Andrzej


> 
> Thanks,
> Marian
> 
> Either I've been missing something or nothing has been going on. (K. E. Gordon)
> 

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Marian Mihailescu]

Hi,

I was testing with the linux-next kernel + the v2 patches
HW: odroid xu4
decoding (working): tested with gstreamer
encoding: tested with gstreamer && mfc-patched ffmpeg
before patches: encoding worked
after patches: encoding didn’t work.

I moved on from linux-next in the meantime and I cannot give you logs, BUT I’ve seen Hardkernel applied these patches (and all the linux-next MFC patches) on top of their 4.9 tree, and the result is very similar to mine on linux-next: https://github.com/hardkernel/linux/issues/284

Mar 21 13:04:54 odroid kernel: [   37.165153] s5p_mfc_alloc_priv_buf:78: Allocating private buffer of size 23243744 failed
Mar 21 13:04:54 odroid kernel: [   37.171865] s5p_mfc_alloc_codec_buffers_v6:244: Failed to allocate Bank1 memory
Mar 21 13:04:54 odroid kernel: [   37.179143] vidioc_reqbufs:1174: Failed to allocate encoding buffers


A user reported even adding s5p_mfc.mem=64M did not make the encoder work.
Any thoughts?

Thanks,
M.

(resent in plain text format)

> On 17 Mar. 2017, at 10:36 pm, Andrzej Hajda <a.hajda@samsung.com> wrote:
> 
> Hi Marian,
> 
> On 15.03.2017 12:36, Marian Mihailescu wrote:
>> Hi,
>> 
>> After testing these patches, encoding using MFC fails when requesting
>> buffers for capture (it works for output) with ENOMEM (it complains it
>> cannot allocate memory on bank1).
>> Did anyone else test encoding?
> 
> I have tested encoding and it works on my test target. Could you provide
> more details of your setup:
> - which kernel and patches,
> - which hw,
> - which test app.
> 
> Regards
> Andrzej
> 
> 
>> 
>> Thanks,
>> Marian
>> 
>> Either I've been missing something or nothing has been going on. (K. E. Gordon)
>> 
> 

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Marek Szyprowski]

Hi Marian,

On 2017-03-22 10:33, Marian Mihailescu wrote:
> Hi,
>
> I was testing with the linux-next kernel + the v2 patches
> HW: odroid xu4
> decoding (working): tested with gstreamer
> encoding: tested with gstreamer && mfc-patched ffmpeg
> before patches: encoding worked
> after patches: encoding didn’t work.
>
> I moved on from linux-next in the meantime and I cannot give you logs, BUT I’ve seen Hardkernel applied these patches (and all the linux-next MFC patches) on top of their 4.9 tree, and the result is very similar to mine on linux-next: https://github.com/hardkernel/linux/issues/284
>
> Mar 21 13:04:54 odroid kernel: [   37.165153] s5p_mfc_alloc_priv_buf:78: Allocating private buffer of size 23243744 failed
> Mar 21 13:04:54 odroid kernel: [   37.171865] s5p_mfc_alloc_codec_buffers_v6:244: Failed to allocate Bank1 memory
> Mar 21 13:04:54 odroid kernel: [   37.179143] vidioc_reqbufs:1174: Failed to allocate encoding buffers
>
>
> A user reported even adding s5p_mfc.mem=64M did not make the encoder work.
> Any thoughts?

Thanks for the report. Could you provide a bit more information about 
the encoder configuration (selected format, frame size, etc). 23MiB for 
the temporary buffer seems to be a bit large value, but I would like to 
reproduce it here and check what can be done to avoid allocating it from 
the preallocated buffer.




> Thanks,
> M.
>
> (resent in plain text format)
>
>> On 17 Mar. 2017, at 10:36 pm, Andrzej Hajda <a.hajda@samsung.com> wrote:
>>
>> Hi Marian,
>>
>> On 15.03.2017 12:36, Marian Mihailescu wrote:
>>> Hi,
>>>
>>> After testing these patches, encoding using MFC fails when requesting
>>> buffers for capture (it works for output) with ENOMEM (it complains it
>>> cannot allocate memory on bank1).
>>> Did anyone else test encoding?
>> I have tested encoding and it works on my test target. Could you provide
>> more details of your setup:
>> - which kernel and patches,
>> - which hw,
>> - which test app.
>>
>> Regards
>> Andrzej
>>
>>
>>> Thanks,
>>> Marian
>>>
>>> Either I've been missing something or nothing has been going on. (K. E. Gordon)
>>>
>
>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Marian Mihailescu]

Hi Marek,

I have been using gstreamer 1.11.2 with the following patches applied to gst-plugins-good (to add the encoder element): https://gist.github.com/mihailescu2m/f52a8f4df67a3d796247337ff67211a9
Also gst-plugins-good was compiled --without-libv4l2

This is a pipeline I used to test encoding (mfc-dec on /dev/video10 and mfc-enc on /dev/video11):

gst-launch-1.0 filesrc location=~/sintel_trailer-720p.mp4 ! qtdemux ! h264parse ! v4l2video10dec !  v4l2video11h264enc extra-controls="encode,h264_level=10,h264_profile=4,frame_level_rate_control_enable=1,video_bitrate=4097152" ! h264parse ! matroskamux ! filesink location=~/sintel-encoded.mkv

I believe this uses all the default MFC encoder options, except:
H264 profile, set to High
H264 level, set to 3.2
max bitrate set to ~4M (default is unlimited, which results in ~100MB/min files).

Cheers,
Marian


> On 22 Mar. 2017, at 8:10 pm, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> 
> Hi Marian,
> 
> On 2017-03-22 10:33, Marian Mihailescu wrote:
>> Hi,
>> 
>> I was testing with the linux-next kernel + the v2 patches
>> HW: odroid xu4
>> decoding (working): tested with gstreamer
>> encoding: tested with gstreamer && mfc-patched ffmpeg
>> before patches: encoding worked
>> after patches: encoding didn’t work.
>> 
>> I moved on from linux-next in the meantime and I cannot give you logs, BUT I’ve seen Hardkernel applied these patches (and all the linux-next MFC patches) on top of their 4.9 tree, and the result is very similar to mine on linux-next: https://github.com/hardkernel/linux/issues/284
>> 
>> Mar 21 13:04:54 odroid kernel: [   37.165153] s5p_mfc_alloc_priv_buf:78: Allocating private buffer of size 23243744 failed
>> Mar 21 13:04:54 odroid kernel: [   37.171865] s5p_mfc_alloc_codec_buffers_v6:244: Failed to allocate Bank1 memory
>> Mar 21 13:04:54 odroid kernel: [   37.179143] vidioc_reqbufs:1174: Failed to allocate encoding buffers
>> 
>> 
>> A user reported even adding s5p_mfc.mem=64M did not make the encoder work.
>> Any thoughts?
> 
> Thanks for the report. Could you provide a bit more information about the encoder configuration (selected format, frame size, etc). 23MiB for the temporary buffer seems to be a bit large value, but I would like to reproduce it here and check what can be done to avoid allocating it from the preallocated buffer.
> 
> 
> 
> 
>> Thanks,
>> M.
>> 
>> (resent in plain text format)
>> 
>>> On 17 Mar. 2017, at 10:36 pm, Andrzej Hajda <a.hajda@samsung.com> wrote:
>>> 
>>> Hi Marian,
>>> 
>>> On 15.03.2017 12:36, Marian Mihailescu wrote:
>>>> Hi,
>>>> 
>>>> After testing these patches, encoding using MFC fails when requesting
>>>> buffers for capture (it works for output) with ENOMEM (it complains it
>>>> cannot allocate memory on bank1).
>>>> Did anyone else test encoding?
>>> I have tested encoding and it works on my test target. Could you provide
>>> more details of your setup:
>>> - which kernel and patches,
>>> - which hw,
>>> - which test app.
>>> 
>>> Regards
>>> Andrzej
>>> 
>>> 
>>>> Thanks,
>>>> Marian
>>>> 
>>>> Either I've been missing something or nothing has been going on. (K. E. Gordon)
>>>> 
>> 
>> 
> 
> Best regards
> -- 
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Marek Szyprowski]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

Hi Marian,


On 2017-03-22 10:33, Marian Mihailescu wrote:
> Hi,
>
> I was testing with the linux-next kernel + the v2 patches
> HW: odroid xu4
> decoding (working): tested with gstreamer
> encoding: tested with gstreamer && mfc-patched ffmpeg
> before patches: encoding worked
> after patches: encoding didn’t work.
>
> I moved on from linux-next in the meantime and I cannot give you logs, BUT I’ve seen Hardkernel applied these patches (and all the linux-next MFC patches) on top of their 4.9 tree, and the result is very similar to mine on linux-next: https://github.com/hardkernel/linux/issues/284
>
> Mar 21 13:04:54 odroid kernel: [   37.165153] s5p_mfc_alloc_priv_buf:78: Allocating private buffer of size 23243744 failed
> Mar 21 13:04:54 odroid kernel: [   37.171865] s5p_mfc_alloc_codec_buffers_v6:244: Failed to allocate Bank1 memory
> Mar 21 13:04:54 odroid kernel: [   37.179143] vidioc_reqbufs:1174: Failed to allocate encoding buffers
>
>
> A user reported even adding s5p_mfc.mem=64M did not make the encoder work.
> Any thoughts?

s5p_mfc.mem=64M should fix the issue. If not then there is some kind of different issue.

We did a bit more tests and in fact encoding h264 requires quite a lot of memory, so the default preallocated size might be not enough. However the codec temporary buffers don't need to be allocated from the preallocated region. In our tests it also worked when codec buffers were allocated in a generic way. Please check if the attached patch (applied on top of v3 patchset) fixes the issue.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


[-- Attachment #2: 0001-media-s5p-mfc-Don-t-allocate-codec-buffers-from-pre-.patch --]
[-- Type: text/x-patch, Size: 3969 bytes --]

From: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Wed, 22 Mar 2017 10:59:26 +0100
Subject: [PATCH] media: s5p-mfc: Don't allocate codec buffers from
 pre-allocated region

Further investigation revealed that codec buffers also don't need to
be allocated at higher addresses than firmware base for MFC v6+ hardware.
Those buffers can be quite large and its size depends on the selected
format and framesize. This patch changes the way the codec buffers are
allocated - driver will use generic allocator for them instead of the
pre-allocated buffer for firmware and contexts.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c    | 28 +++++++++++++++++++++++++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h    |  4 ++++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  4 ++--
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
index 34a66189d980..7f33cf23947f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
@@ -79,6 +79,25 @@ int s5p_mfc_alloc_priv_buf(struct s5p_mfc_dev *dev, unsigned int mem_ctx,
 	return -ENOMEM;
 }
 
+int s5p_mfc_alloc_generic_buf(struct s5p_mfc_dev *dev, unsigned int mem_ctx,
+			   struct s5p_mfc_priv_buf *b)
+{
+	struct device *mem_dev = dev->mem_dev[mem_ctx];
+
+	mfc_debug(3, "Allocating generic buf: %zu\n", b->size);
+
+	b->ctx = mem_ctx;
+	b->virt = dma_alloc_coherent(mem_dev, b->size, &b->dma, GFP_KERNEL);
+	if (!b->virt)
+		goto no_mem;
+
+	mfc_debug(3, "Allocated addr %p %pad\n", b->virt, &b->dma);
+	return 0;
+no_mem:
+	mfc_err("Allocating generic buffer of size %zu failed\n", b->size);
+	return -ENOMEM;
+}
+
 void s5p_mfc_release_priv_buf(struct s5p_mfc_dev *dev,
 			      struct s5p_mfc_priv_buf *b)
 {
@@ -97,3 +116,12 @@ void s5p_mfc_release_priv_buf(struct s5p_mfc_dev *dev,
 	b->size = 0;
 }
 
+void s5p_mfc_release_generic_buf(struct s5p_mfc_dev *dev,
+			      struct s5p_mfc_priv_buf *b)
+{
+	struct device *mem_dev = dev->mem_dev[b->ctx];
+	dma_free_coherent(mem_dev, b->size, b->virt, b->dma);
+	b->virt = NULL;
+	b->dma = 0;
+	b->size = 0;
+}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
index 108e59382e0c..16d553fcff08 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
@@ -319,6 +319,10 @@ int s5p_mfc_alloc_priv_buf(struct s5p_mfc_dev *dev, unsigned int mem_ctx,
 			   struct s5p_mfc_priv_buf *b);
 void s5p_mfc_release_priv_buf(struct s5p_mfc_dev *dev,
 			      struct s5p_mfc_priv_buf *b);
+int s5p_mfc_alloc_generic_buf(struct s5p_mfc_dev *dev, unsigned int mem_ctx,
+			   struct s5p_mfc_priv_buf *b);
+void s5p_mfc_release_generic_buf(struct s5p_mfc_dev *dev,
+			      struct s5p_mfc_priv_buf *b);
 
 
 #endif /* S5P_MFC_OPR_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 70071a12db16..85880e9106be 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -239,7 +239,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 
 	/* Allocate only if memory from bank 1 is necessary */
 	if (ctx->bank1.size > 0) {
-		ret = s5p_mfc_alloc_priv_buf(dev, BANK_L_CTX, &ctx->bank1);
+		ret = s5p_mfc_alloc_generic_buf(dev, BANK_L_CTX, &ctx->bank1);
 		if (ret) {
 			mfc_err("Failed to allocate Bank1 memory\n");
 			return ret;
@@ -252,7 +252,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 /* Release buffers allocated for codec */
 static void s5p_mfc_release_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 {
-	s5p_mfc_release_priv_buf(ctx->dev, &ctx->bank1);
+	s5p_mfc_release_generic_buf(ctx->dev, &ctx->bank1);
 }
 
 /* Allocate memory for instance data buffer */
-- 
1.9.1

[PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Marek Szyprowski]

Dear All,

This patchset is a result of my work on enabling full support for MFC device
(multimedia codec) on Exynos 5433 on ARM64 architecture. Initially I thought
that to let it working on ARM64 architecture with IOMMU, I would need to
solve the issue related to the fact that s5p-mfc driver was depending on the
first-fit allocation method in the DMA-mapping / IOMMU glue code (ARM64 use
different algorithm). It turned out, that there is a much simpler way.

During my research I found that some of the requirements for the memory
buffers for MFC v6+ devices were blindly copied from the previous
hardware (v5) version and simply turned out to be excessive. It turned out
that there is no strict requirement for ALL buffers to be allocated on
the higher addresses than the firmware base. This requirement is true only
for the device and per-context buffers. All video data buffers can be
allocated anywhere for all MFC v6+ versions. This heavily simplifies
memory management in the driver.

Such relaxed requirements for the memory buffers can be easily fulfilled
by allocating firmware, device and per-context buffers from the probe-time
preallocated larger buffer. There is no need to create special reserved
memory regions. The only case, when those memory regions are needed is an
oldest Exynos series - Exynos4210 or Exyno4412, which both have MFC v5
hardware, and only when IOMMU is disabled.

This patchset has been tested on Odroid U3 (Exynos4412 with MFC v5), Google
Snow (Exynos5250 with MFC v6), Odroid XU3 (Exynos5422 with MFC v8) and
TM2 (Exynos5433 with MFC v8, ARM64) boards.

To get it working on TM2/Exynos5433 with IOMMU enabled, the 'architectural
clock gating' in SYSMMU has to be disabled. Fixing this will be handled
separately. As a temporary solution, one need to clear CFG_ACGEN bit in
REG_MMU_CFG of the SYSMMU, see __sysmmu_init_config function in
drivers/iommu/exynos-iommu.c.

Patches are based on linux-next from 20th February 2017 with "media:
s5p-mfc: Fix initialization of internal structures" patch applied:
https://patchwork.linuxtv.org/patch/39198/

I've tried to split changes into small pieces to make it easier to review
the code. I've also did a bit of cleanup while touching the driver.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Changelog:

v2:
- fixed issues pointed by Javier Martinez Canillas: code compiles now
  after applying each patch, added missing cleanup
- added tags

v1: https://www.spinics.net/lists/linux-media/msg111156.html
- initial version


Patch summary:

Marek Szyprowski (15):
  media: s5p-mfc: Remove unused structures and dead code
  media: s5p-mfc: Use generic of_device_get_match_data helper
  media: s5p-mfc: Replace mem_dev_* entries with an array
  media: s5p-mfc: Replace bank1/bank2 entries with an array
  media: s5p-mfc: Simplify alloc/release private buffer functions
  media: s5p-mfc: Move setting DMA max segment size to DMA configure
    function
  media: s5p-mfc: Put firmware to private buffer structure
  media: s5p-mfc: Move firmware allocation to DMA configure function
  media: s5p-mfc: Allocate firmware with internal private buffer alloc
    function
  media: s5p-mfc: Reduce firmware buffer size for MFC v6+ variants
  media: s5p-mfc: Split variant DMA memory configuration into separate
    functions
  media: s5p-mfc: Add support for probe-time preallocated block based
    allocator
  media: s5p-mfc: Remove special configuration of IOMMU domain
  media: s5p-mfc: Use preallocated block allocator always for MFC v6+
  ARM: dts: exynos: Remove MFC reserved buffers

 .../devicetree/bindings/media/s5p-mfc.txt          |   2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts           |   1 -
 arch/arm/boot/dts/exynos5250-smdk5250.dts          |   1 -
 arch/arm/boot/dts/exynos5250-spring.dts            |   1 -
 arch/arm/boot/dts/exynos5420-arndale-octa.dts      |   1 -
 arch/arm/boot/dts/exynos5420-peach-pit.dts         |   1 -
 arch/arm/boot/dts/exynos5420-smdk5420.dts          |   1 -
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |   1 -
 arch/arm/boot/dts/exynos5800-peach-pi.dts          |   1 -
 drivers/media/platform/s5p-mfc/regs-mfc-v6.h       |   2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v7.h       |   2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h       |   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c           | 214 +++++++++++++--------
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c    |   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h    |  43 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c      |  71 ++-----
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h      |   1 -
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c       |   8 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c       |  10 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h     |  51 +----
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c       |  65 +++++--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h       |   8 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c    |  48 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c    |  14 +-
 24 files changed, 268 insertions(+), 283 deletions(-)

-- 
1.9.1