On 06/02/2016 07:25 PM, Javier Martinez Canillas wrote:

Hello Krzysztof,

On 06/02/2016 12:31 PM, Krzysztof Kozlowski wrote:

quoted

On 06/02/2016 05:20 PM, Javier Martinez Canillas wrote:

quoted

Hello Krzysztof,

On 05/30/2016 03:28 AM, Krzysztof Kozlowski wrote:

quoted

On 05/24/2016 03:31 PM, Marek Szyprowski wrote:

quoted

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