[v4,5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
diff mbox

Message ID 1464096690-23605-6-git-send-email-m.szyprowski@samsung.com
State Accepted
Headers show

Commit Message

Marek Szyprowski May 24, 2016, 1:31 p.m. UTC
Once MFC driver has been converted to generic reserved memory bindings,
there is no need for custom memory reservation code.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 arch/arm/mach-exynos/Makefile      |  2 -
 arch/arm/mach-exynos/exynos.c      | 19 --------
 arch/arm/mach-exynos/mfc.h         | 16 -------
 arch/arm/mach-exynos/s5p-dev-mfc.c | 93 --------------------------------------
 4 files changed, 130 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/mfc.h
 delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c

Comments

Javier Martinez Canillas May 25, 2016, 3:57 p.m. UTC | #1
Hello Marek,

On 05/24/2016 09:31 AM, Marek Szyprowski wrote:
> Once MFC driver has been converted to generic reserved memory bindings,
> there is no need for custom memory reservation code.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---

Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>

Best regards,
Krzysztof Kozlowski May 30, 2016, 7:28 a.m. UTC | #2
On 05/24/2016 03:31 PM, Marek Szyprowski wrote:
> Once MFC driver has been converted to generic reserved memory bindings,
> there is no need for custom memory reservation code.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  arch/arm/mach-exynos/Makefile      |  2 -
>  arch/arm/mach-exynos/exynos.c      | 19 --------
>  arch/arm/mach-exynos/mfc.h         | 16 -------
>  arch/arm/mach-exynos/s5p-dev-mfc.c | 93 --------------------------------------
>  4 files changed, 130 deletions(-)
>  delete mode 100644 arch/arm/mach-exynos/mfc.h
>  delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c

Thanks, applied.

What is your final decision for DTS patches? Which approach for MFC
reserved memory node?

Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Javier Martinez Canillas June 2, 2016, 3:20 p.m. UTC | #3
Hello Krzysztof,

On 05/30/2016 03:28 AM, Krzysztof Kozlowski wrote:
> On 05/24/2016 03:31 PM, Marek Szyprowski wrote:
>> Once MFC driver has been converted to generic reserved memory bindings,
>> there is no need for custom memory reservation code.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
>>  arch/arm/mach-exynos/Makefile      |  2 -
>>  arch/arm/mach-exynos/exynos.c      | 19 --------
>>  arch/arm/mach-exynos/mfc.h         | 16 -------
>>  arch/arm/mach-exynos/s5p-dev-mfc.c | 93 --------------------------------------
>>  4 files changed, 130 deletions(-)
>>  delete mode 100644 arch/arm/mach-exynos/mfc.h
>>  delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
> 
> Thanks, applied.
>

This patch can't be applied before patches 2/5 and 3/5, or the custom
memory regions reservation will break with the current s5p-mfc driver.
 
> What is your final decision for DTS patches? Which approach for MFC
> reserved memory node?
> 
> Krzysztof
> 
 
Best regards,
Krzysztof Kozlowski June 2, 2016, 4:31 p.m. UTC | #4
On 06/02/2016 05:20 PM, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 05/30/2016 03:28 AM, Krzysztof Kozlowski wrote:
>> On 05/24/2016 03:31 PM, Marek Szyprowski wrote:
>>> Once MFC driver has been converted to generic reserved memory bindings,
>>> there is no need for custom memory reservation code.
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> ---
>>>  arch/arm/mach-exynos/Makefile      |  2 -
>>>  arch/arm/mach-exynos/exynos.c      | 19 --------
>>>  arch/arm/mach-exynos/mfc.h         | 16 -------
>>>  arch/arm/mach-exynos/s5p-dev-mfc.c | 93 --------------------------------------
>>>  4 files changed, 130 deletions(-)
>>>  delete mode 100644 arch/arm/mach-exynos/mfc.h
>>>  delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
>>
>> Thanks, applied.
>>
> 
> This patch can't be applied before patches 2/5 and 3/5, or the custom
> memory regions reservation will break with the current s5p-mfc driver.

Yes, I know. As I understood from talk with Marek, the driver is broken
now so continuous work was not chosen. If it is not correct and full
bisectability is required, then entire patchset requires special
handling - I need a stable tag from media tree. Without this everything
will be broken anyway.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Javier Martinez Canillas June 2, 2016, 5:25 p.m. UTC | #5
Hello Krzysztof,

On 06/02/2016 12:31 PM, Krzysztof Kozlowski wrote:
> On 06/02/2016 05:20 PM, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 05/30/2016 03:28 AM, Krzysztof Kozlowski wrote:
>>> On 05/24/2016 03:31 PM, Marek Szyprowski wrote:
>>>> Once MFC driver has been converted to generic reserved memory bindings,
>>>> there is no need for custom memory reservation code.
>>>>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> ---
>>>>  arch/arm/mach-exynos/Makefile      |  2 -
>>>>  arch/arm/mach-exynos/exynos.c      | 19 --------
>>>>  arch/arm/mach-exynos/mfc.h         | 16 -------
>>>>  arch/arm/mach-exynos/s5p-dev-mfc.c | 93 --------------------------------------
>>>>  4 files changed, 130 deletions(-)
>>>>  delete mode 100644 arch/arm/mach-exynos/mfc.h
>>>>  delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
>>>
>>> Thanks, applied.
>>>
>>
>> This patch can't be applied before patches 2/5 and 3/5, or the custom
>> memory regions reservation will break with the current s5p-mfc driver.
> 
> Yes, I know. As I understood from talk with Marek, the driver is broken
> now so continuous work was not chosen. If it is not correct and full

It's true that the driven is currently broken in mainline and is not really
stable, I posted fixes for all the issues I found (mostly in module removal
and insert paths).

But with just the following patch from Ayaka on top of mainline, I'm able to
have video decoding working: https://lkml.org/lkml/2016/5/6/577

Marek mentioned that bisectability is only partially broken because the old
binding will still work after this series if IOMMU is enabled (because the
properties are ignored in this case). But will break if IOMMU isn't enabled
which will be the case for some boards that fails to boot with IOMMU due the
bootloader leaving the FIMD enabled doing DMA operations automatically AFAIU. 

Now, I'm OK with not keeping backwards compatibility for the MFC dt bindings
since arguably the driver has been broken for a long time and nobody cared
and also I don't think anyone in practice boots a new kernel with an old DTB
for Exynos.

But I don't think is correct to introduce a new issue as is the case if this
patch is applied before the previous patches in the series since this causes
the driver to probe to fail and the following warn on boot (while it used to
at least probe correctly in mainline):

[   17.190165] WARNING: CPU: 0 PID: 224 at kernel/memremap.c:111 memremap+0x1a8/0x1b0
[   17.193127] memremap attempted on ram 0x51000000 size: 0x800000
[   17.196247] Modules linked in: s5p_mfc(+) uvcvideo s5p_jpeg videobuf2_vmalloc v4l2_mem2mem
[   17.199569] CPU: 0 PID: 224 Comm: systemd-udevd Not tainted 4.7.0-rc1-next-20160531-00006-g569df5b983f3 #68
[   17.202556] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   17.205534] [<c010e1ac>] (unwind_backtrace) from [<c010af38>] (show_stack+0x10/0x14)
[   17.208535] [<c010af38>] (show_stack) from [<c0323b9c>] (dump_stack+0x88/0x9c)
[   17.211530] [<c0323b9c>] (dump_stack) from [<c011a828>] (__warn+0xe8/0x100)
[   17.214492] [<c011a828>] (__warn) from [<c011a878>] (warn_slowpath_fmt+0x38/0x48)
[   17.217479] [<c011a878>] (warn_slowpath_fmt) from [<c0194ee0>] (memremap+0x1a8/0x1b0)
[   17.220476] [<c0194ee0>] (memremap) from [<c040d92c>] (dma_init_coherent_memory+0xf8/0x130)
[   17.223489] [<c040d92c>] (dma_init_coherent_memory) from [<c040d990>] (dma_declare_coherent_memory+0x2c/0x6c)
[   17.226570] [<c040d990>] (dma_declare_coherent_memory) from [<bf1768c4>] (s5p_mfc_probe+0x170/0x650 [s5p_mfc])
[   17.229648] [<bf1768c4>] (s5p_mfc_probe [s5p_mfc]) from [<c03fb704>] (platform_drv_probe+0x4c/0xb0)
[   17.232718] [<c03fb704>] (platform_drv_probe) from [<c03f9e58>] (driver_probe_device+0x214/0x2c0)
[   17.235800] [<c03f9e58>] (driver_probe_device) from [<c03f9fb0>] (__driver_attach+0xac/0xb0)
[   17.238906] [<c03f9fb0>] (__driver_attach) from [<c03f81d0>] (bus_for_each_dev+0x68/0x9c)
[   17.242031] [<c03f81d0>] (bus_for_each_dev) from [<c03f944c>] (bus_add_driver+0x1a0/0x218)
[   17.245160] [<c03f944c>] (bus_add_driver) from [<c03fa7c8>] (driver_register+0x78/0xf8)
[   17.248300] [<c03fa7c8>] (driver_register) from [<c01017c0>] (do_one_initcall+0x40/0x170)
[   17.251475] [<c01017c0>] (do_one_initcall) from [<c01956e4>] (do_init_module+0x60/0x1b0)
[   17.254656] [<c01956e4>] (do_init_module) from [<c0188dc0>] (load_module+0x17ec/0x1dd0)
[   17.257844] [<c0188dc0>] (load_module) from [<c0189570>] (SyS_finit_module+0x8c/0x9c)
[   17.261037] [<c0189570>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)
[   17.265210] ---[ end trace 33de2b5daf697e0f ]---
[   17.269300] s5p_mfc_alloc_memdevs:1072: Failed to declare coherent memory for
               MFC device
[   17.277593] ------------[ cut here ]------------

Best regards,
Krzysztof Kozlowski June 3, 2016, 6:57 a.m. UTC | #6
On 06/02/2016 07:25 PM, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 06/02/2016 12:31 PM, Krzysztof Kozlowski wrote:
>> On 06/02/2016 05:20 PM, Javier Martinez Canillas wrote:
>>> Hello Krzysztof,
>>>
>>> On 05/30/2016 03:28 AM, Krzysztof Kozlowski wrote:
>>>> On 05/24/2016 03:31 PM, Marek Szyprowski wrote:
>>>>> Once MFC driver has been converted to generic reserved memory bindings,
>>>>> there is no need for custom memory reservation code.
>>>>>
>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> ---
>>>>>  arch/arm/mach-exynos/Makefile      |  2 -
>>>>>  arch/arm/mach-exynos/exynos.c      | 19 --------
>>>>>  arch/arm/mach-exynos/mfc.h         | 16 -------
>>>>>  arch/arm/mach-exynos/s5p-dev-mfc.c | 93 --------------------------------------
>>>>>  4 files changed, 130 deletions(-)
>>>>>  delete mode 100644 arch/arm/mach-exynos/mfc.h
>>>>>  delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
>>>>
>>>> Thanks, applied.
>>>>
>>>
>>> This patch can't be applied before patches 2/5 and 3/5, or the custom
>>> memory regions reservation will break with the current s5p-mfc driver.
>>
>> Yes, I know. As I understood from talk with Marek, the driver is broken
>> now so continuous work was not chosen. If it is not correct and full
> 
> It's true that the driven is currently broken in mainline and is not really
> stable, I posted fixes for all the issues I found (mostly in module removal
> and insert paths).
> 
> But with just the following patch from Ayaka on top of mainline, I'm able to
> have video decoding working: https://lkml.org/lkml/2016/5/6/577

Which is still a "future" patch, not current state...
> 
> Marek mentioned that bisectability is only partially broken because the old
> binding will still work after this series if IOMMU is enabled (because the
> properties are ignored in this case). But will break if IOMMU isn't enabled
> which will be the case for some boards that fails to boot with IOMMU due the
> bootloader leaving the FIMD enabled doing DMA operations automatically AFAIU. 
> 
> Now, I'm OK with not keeping backwards compatibility for the MFC dt bindings
> since arguably the driver has been broken for a long time and nobody cared
> and also I don't think anyone in practice boots a new kernel with an old DTB
> for Exynos.
> 
> But I don't think is correct to introduce a new issue as is the case if this
> patch is applied before the previous patches in the series since this causes
> the driver to probe to fail and the following warn on boot (while it used to
> at least probe correctly in mainline):

Okay but the patches will go through separate tree. This is not a
problem, as I said, I just need a stable tag from media tree with first
four patches (Mauro?).

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Krzysztof Kozlowski June 6, 2016, 7:24 a.m. UTC | #7
On 06/03/2016 11:59 AM, Sylwester Nawrocki wrote:
> On 06/03/2016 08:57 AM, Krzysztof Kozlowski wrote:
>> On 06/02/2016 07:25 PM, Javier Martinez Canillas wrote:
>>> On 06/02/2016 12:31 PM, Krzysztof Kozlowski wrote:
>>>> On 06/02/2016 05:20 PM, Javier Martinez Canillas wrote:
>>>>> On 05/30/2016 03:28 AM, Krzysztof Kozlowski wrote:
>>>>>> On 05/24/2016 03:31 PM, Marek Szyprowski wrote:
>>>>>>> Once MFC driver has been converted to generic reserved memory bindings,
>>>>>>> there is no need for custom memory reservation code.
>>>>>>>
>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>> ---
>>>>>>>  arch/arm/mach-exynos/Makefile      |  2 -
>>>>>>>  arch/arm/mach-exynos/exynos.c      | 19 --------
>>>>>>>  arch/arm/mach-exynos/mfc.h         | 16 -------
>>>>>>>  arch/arm/mach-exynos/s5p-dev-mfc.c | 93 -----------------------------
>>>>>>>  4 files changed, 130 deletions(-)
>>>>>>>  delete mode 100644 arch/arm/mach-exynos/mfc.h
>>>>>>>  delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
>>>>>>
>>>>>> Thanks, applied.
>>>>>
>>>>> This patch can't be applied before patches 2/5 and 3/5, or the custom
>>>>> memory regions reservation will break with the current s5p-mfc driver.
>>>>
>>>> Yes, I know. As I understood from talk with Marek, the driver is broken
>>>> now so continuous work was not chosen. If it is not correct and full
>>>
>>> It's true that the driven is currently broken in mainline and is not really
>>> stable, I posted fixes for all the issues I found (mostly in module removal
>>> and insert paths).
>>>
>>> But with just the following patch from Ayaka on top of mainline, I'm able to
>>> have video decoding working: https://lkml.org/lkml/2016/5/6/577
>>
>> Which is still a "future" patch, not current state...
>>>
>>> Marek mentioned that bisectability is only partially broken because the old
>>> binding will still work after this series if IOMMU is enabled (because the
>>> properties are ignored in this case). But will break if IOMMU isn't enabled
>>> which will be the case for some boards that fails to boot with IOMMU due the
>>> bootloader leaving the FIMD enabled doing DMA operations automatically AFAIU. 
>>>
>>> Now, I'm OK with not keeping backwards compatibility for the MFC dt bindings
>>> since arguably the driver has been broken for a long time and nobody cared
>>> and also I don't think anyone in practice boots a new kernel with an old DTB
>>> for Exynos.
>>>
>>> But I don't think is correct to introduce a new issue as is the case if this
>>> patch is applied before the previous patches in the series since this causes
>>> the driver to probe to fail and the following warn on boot (while it used to
>>> at least probe correctly in mainline):
>>
>> Okay but the patches will go through separate tree. This is not a
>> problem, as I said, I just need a stable tag from media tree with first
>> four patches (Mauro?).
> 
> I have prepared a topic branch including media patches from this patch
> series and the dependency fix patches from Javier and Marek.
> So this could be used as a topic branch to pull into media master branch
> and a dependency topic branch for Krzysztof's samsung-soc tree.
> Mauro, can we do it this way? I already talked to Kamil about this.
> 
> ---8<----
> The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
> 
>   Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/snawrocki/samsung.git for-v4.8/media/exynos-mfc
> 
> for you to fetch changes up to 04f776734c4e03e33111d3d5a994b589870df623:
> 
>   media: s5p-mfc: add iommu support (2016-06-03 11:13:45 +0200)

Thanks Sylwester! Although this is branch not a tag but I believe it
will stay stable. Pulled. I will apply Exynos-specific patches on top of it.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Krzysztof Kozlowski June 6, 2016, 7:40 a.m. UTC | #8
On 06/03/2016 08:57 AM, Krzysztof Kozlowski wrote:
> On 06/02/2016 07:25 PM, Javier Martinez Canillas wrote:
>> Marek mentioned that bisectability is only partially broken because the old
>> binding will still work after this series if IOMMU is enabled (because the
>> properties are ignored in this case). But will break if IOMMU isn't enabled
>> which will be the case for some boards that fails to boot with IOMMU due the
>> bootloader leaving the FIMD enabled doing DMA operations automatically AFAIU. 
>>
>> Now, I'm OK with not keeping backwards compatibility for the MFC dt bindings
>> since arguably the driver has been broken for a long time and nobody cared
>> and also I don't think anyone in practice boots a new kernel with an old DTB
>> for Exynos.
>>
>> But I don't think is correct to introduce a new issue as is the case if this
>> patch is applied before the previous patches in the series since this causes
>> the driver to probe to fail and the following warn on boot (while it used to
>> at least probe correctly in mainline):
> 
> Okay but the patches will go through separate tree. This is not a
> problem, as I said, I just need a stable tag from media tree with first
> four patches (Mauro?).

Applied again this and DTS changes (remaining two patches) for v4.8 on
top of branch provided by Sylwester:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-v4.8/exynos-mfc

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 34d29df..b91b382 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -23,5 +23,3 @@  AFLAGS_sleep.o			:=-Wa,-march=armv7-a$(plus_sec)
 
 obj-$(CONFIG_EXYNOS5420_MCPM)	+= mcpm-exynos.o
 CFLAGS_mcpm-exynos.o		+= -march=armv7-a
-
-obj-$(CONFIG_S5P_DEV_MFC)	+= s5p-dev-mfc.o
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 52ccf24..a8620c6 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -27,7 +27,6 @@ 
 #include <mach/map.h>
 
 #include "common.h"
-#include "mfc.h"
 
 static struct map_desc exynos4_iodesc[] __initdata = {
 	{
@@ -237,23 +236,6 @@  static char const *const exynos_dt_compat[] __initconst = {
 	NULL
 };
 
-static void __init exynos_reserve(void)
-{
-#ifdef CONFIG_S5P_DEV_MFC
-	int i;
-	char *mfc_mem[] = {
-		"samsung,mfc-v5",
-		"samsung,mfc-v6",
-		"samsung,mfc-v7",
-		"samsung,mfc-v8",
-	};
-
-	for (i = 0; i < ARRAY_SIZE(mfc_mem); i++)
-		if (of_scan_flat_dt(s5p_fdt_alloc_mfc_mem, mfc_mem[i]))
-			break;
-#endif
-}
-
 static void __init exynos_dt_fixup(void)
 {
 	/*
@@ -275,6 +257,5 @@  DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
 	.init_machine	= exynos_dt_machine_init,
 	.init_late	= exynos_init_late,
 	.dt_compat	= exynos_dt_compat,
-	.reserve	= exynos_reserve,
 	.dt_fixup	= exynos_dt_fixup,
 MACHINE_END
diff --git a/arch/arm/mach-exynos/mfc.h b/arch/arm/mach-exynos/mfc.h
deleted file mode 100644
index dec93cd..0000000
--- a/arch/arm/mach-exynos/mfc.h
+++ /dev/null
@@ -1,16 +0,0 @@ 
-/*
- * Copyright (C) 2013 Samsung Electronics Co.Ltd
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#ifndef __MACH_EXYNOS_MFC_H
-#define __MACH_EXYNOS_MFC_H __FILE__
-
-int __init s5p_fdt_alloc_mfc_mem(unsigned long node, const char *uname,
-				int depth, void *data);
-
-#endif /* __MACH_EXYNOS_MFC_H */
diff --git a/arch/arm/mach-exynos/s5p-dev-mfc.c b/arch/arm/mach-exynos/s5p-dev-mfc.c
deleted file mode 100644
index 8ef1f3e..0000000
--- a/arch/arm/mach-exynos/s5p-dev-mfc.c
+++ /dev/null
@@ -1,93 +0,0 @@ 
-/*
- * Copyright (C) 2010-2011 Samsung Electronics Co.Ltd
- *
- * Base S5P MFC resource and device definitions
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/dma-mapping.h>
-#include <linux/memblock.h>
-#include <linux/ioport.h>
-#include <linux/of_fdt.h>
-#include <linux/of.h>
-
-static struct platform_device s5p_device_mfc_l;
-static struct platform_device s5p_device_mfc_r;
-
-struct s5p_mfc_dt_meminfo {
-	unsigned long	loff;
-	unsigned long	lsize;
-	unsigned long	roff;
-	unsigned long	rsize;
-	char		*compatible;
-};
-
-struct s5p_mfc_reserved_mem {
-	phys_addr_t	base;
-	unsigned long	size;
-	struct device	*dev;
-};
-
-static struct s5p_mfc_reserved_mem s5p_mfc_mem[2] __initdata;
-
-
-static void __init s5p_mfc_reserve_mem(phys_addr_t rbase, unsigned int rsize,
-				phys_addr_t lbase, unsigned int lsize)
-{
-	int i;
-
-	s5p_mfc_mem[0].dev = &s5p_device_mfc_r.dev;
-	s5p_mfc_mem[0].base = rbase;
-	s5p_mfc_mem[0].size = rsize;
-
-	s5p_mfc_mem[1].dev = &s5p_device_mfc_l.dev;
-	s5p_mfc_mem[1].base = lbase;
-	s5p_mfc_mem[1].size = lsize;
-
-	for (i = 0; i < ARRAY_SIZE(s5p_mfc_mem); i++) {
-		struct s5p_mfc_reserved_mem *area = &s5p_mfc_mem[i];
-		if (memblock_remove(area->base, area->size)) {
-			printk(KERN_ERR "Failed to reserve memory for MFC device (%ld bytes at 0x%08lx)\n",
-			       area->size, (unsigned long) area->base);
-			area->base = 0;
-		}
-	}
-}
-
-int __init s5p_fdt_alloc_mfc_mem(unsigned long node, const char *uname,
-				int depth, void *data)
-{
-	const __be32 *prop;
-	int len;
-	struct s5p_mfc_dt_meminfo mfc_mem;
-
-	if (!data)
-		return 0;
-
-	if (!of_flat_dt_is_compatible(node, data))
-		return 0;
-
-	prop = of_get_flat_dt_prop(node, "samsung,mfc-l", &len);
-	if (!prop || (len != 2 * sizeof(unsigned long)))
-		return 0;
-
-	mfc_mem.loff = be32_to_cpu(prop[0]);
-	mfc_mem.lsize = be32_to_cpu(prop[1]);
-
-	prop = of_get_flat_dt_prop(node, "samsung,mfc-r", &len);
-	if (!prop || (len != 2 * sizeof(unsigned long)))
-		return 0;
-
-	mfc_mem.roff = be32_to_cpu(prop[0]);
-	mfc_mem.rsize = be32_to_cpu(prop[1]);
-
-	s5p_mfc_reserve_mem(mfc_mem.roff, mfc_mem.rsize,
-			mfc_mem.loff, mfc_mem.lsize);
-
-	return 1;
-}