[PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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
---
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
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
#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..000
--- 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..000
--- 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
-#include
-#include
-#include
-#include
-#include
-#include
-
-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)
-{
-
Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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 > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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 > --- > 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-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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 >> --- >> 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, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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 >>> --- >>> 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-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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 --- 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 0x5100 size: 0x80 [ 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-6-g569df5b983f3 #68 [ 17.202556] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 17.205534] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 17.208535] [] (show_stack) from [] (dump_stack+0x88/0x9c) [ 17.211530] [] (dump_stack) from [] (__warn+0xe8/0x100) [ 17.214492] [] (__warn) from [] (warn_slowpath_fmt+0x38/0x48) [ 17.217479] [] (warn_slowpath_fmt) from [] (memremap+0x1a8/0x1b0) [ 17.220476] [] (memremap) from [] (dma_init_coherent_memory+0xf8/0x130) [ 17.223489] [] (dma_init_coherent_memory) from [] (dma_declare_coherent_memory+0x2c/0x6c) [ 17.226570] [] (dma_declare_coherent_memory) from [] (s5p_mfc_probe+0x170/0x650 [s5p_mfc]) [ 17.229648] [] (s5p_mfc_probe [s5p_mfc]) from [] (platform_drv_probe+0x4c/0xb0) [ 17.232718] [] (platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0) [ 17.235800] [] (driver_probe_device) from [] (__driver_attach+0xac/0xb0) [ 17.238906] [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c) [ 17.242031] [] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218) [ 17.245160] [] (bus_add_driver) from [] (driver_register+0x78/0xf8) [ 17.248300] [] (driver_register) from [] (do_one_initcall+0x40/0x170) [ 17.251475] [] (do_one_initcall) from [] (do_init_module+0x60/0x1b0) [ 17.254656] [] (do_init_module) from [] (load_module+0x17ec/0x1dd0) [ 17.257844] [] (load_module) from [] (SyS_finit_module+0x8c/0x9c) [ 17.261037] [] (SyS_finit_module) from [] (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, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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 > --- > 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-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ATTN] Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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 >> --- >> 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) Javier Martinez Canillas (3): s5p-mfc: Set device name for reserved memory region devs s5p-mfc: Add release callback for memory region devs s5p-mfc: Fix race between s5p_mfc_probe() and s5p_mfc_open() Marek Szyprowski (6): media: vb2-dma-contig: add helper for setting dma max seg size media: set proper max seg size for devices on Exynos SoCs of: reserved_mem: add support for using more than one region for given device media: s5p-mfc: use generic reserved memory bindings media: s5p-mfc: replace custom reserved memory handling code with generic one media: s5p-mfc: add iommu support Documentation/devicetree/bindings/media/s5p-mfc.txt | 39 - drivers/media/platform/exynos-gsc/gsc-core.c| 2 + drivers/media/platform/exynos4-is/fimc-core.c | 2 + drivers/media/platform/exynos4-is/fimc-is.c | 2 + drivers/media/platform/exynos4-is/fimc-lite.c | 2 + drivers/media/platform/s5p-g2d/g2d.c| 2 + drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 + drivers/media/platform/s5p-mfc/s5p_mfc.c| 198 ++--- drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h | 79 ++ drivers/media/platform/s5p-tv/mixer_video.c | 2 + drivers/media/v4l2-core/videobuf2-dma-contig.c | 53 +++ drivers/of/of_reserved_mem.c| 85 --- includ
Re: [ATTN] Re: [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling
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 >>> --- >>> 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-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
