diff mbox

[14/15] media: s5p-mfc: Use preallocated block allocator always for MFC v6+

Message ID 1487058728-16501-15-git-send-email-m.szyprowski@samsung.com (mailing list archive)
State Not Applicable
Headers show

Commit Message

Marek Szyprowski Feb. 14, 2017, 7:52 a.m. UTC
It turned out that all versions of MFC v6+ hardware doesn't have a strict
requirement for ALL buffers to be allocated on higher addresses than the
firmware base like it was documented for MFC v5. 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. Basing on this fact, the
special DMA configuration based on two reserved memory regions is not
really needed for MFC v6+ devices, because the memory requirements for the
firmware, device and per-context buffers can be fulfilled by the simple
probe-time pre-allocated block allocator instroduced in previous patch.

This patch enables support for such pre-allocated block based allocator
always for MFC v6+ devices. Due to the limitations of the memory management
subsystem the largest supported size of the pre-allocated buffer when no
CMA (Contiguous Memory Allocator) is enabled is 4MiB.

This patch also removes the requirement to provide two reserved memory
regions for MFC v6+ devices in device tree. Now the driver is fully
functional without them.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c            | 9 ++++++---
 2 files changed, 7 insertions(+), 4 deletions(-)

Comments

Javier Martinez Canillas Feb. 17, 2017, 9:13 p.m. UTC | #1
Hello Marek,

On 02/14/2017 04:52 AM, Marek Szyprowski wrote:
> It turned out that all versions of MFC v6+ hardware doesn't have a strict
> requirement for ALL buffers to be allocated on higher addresses than the
> firmware base like it was documented for MFC v5. 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. Basing on this fact, the
> special DMA configuration based on two reserved memory regions is not
> really needed for MFC v6+ devices, because the memory requirements for the
> firmware, device and per-context buffers can be fulfilled by the simple
> probe-time pre-allocated block allocator instroduced in previous patch.

s/instroduced/introduced

> 
> This patch enables support for such pre-allocated block based allocator
> always for MFC v6+ devices. Due to the limitations of the memory management
> subsystem the largest supported size of the pre-allocated buffer when no
> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
> 
> This patch also removes the requirement to provide two reserved memory
> regions for MFC v6+ devices in device tree. Now the driver is fully
> functional without them.
>

Great!

> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---

The patch looks good to me though and it works on my tests,
I've just one comment below.

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

>  Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc.c            | 9 ++++++---
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> index 2c901286d818..d3404b5d4d17 100644
> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> @@ -28,7 +28,7 @@ Optional properties:
>    - memory-region : from reserved memory binding: phandles to two reserved
>  	memory regions, first is for "left" mfc memory bus interfaces,
>  	second if for the "right" mfc memory bus, used when no SYSMMU
> -	support is available
> +	support is available; used only by MFC v5 present in Exynos4 SoCs
>  
>  Obsolete properties:
>    - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 8fc6fe4ba087..36f0aec2a1b3 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev)
>  static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
>  {
>  	struct device *dev = &mfc_dev->plat_dev->dev;
> -	unsigned long mem_size = SZ_8M;
> +	unsigned long mem_size = SZ_4M;
>  	unsigned int bitmap_size;
>  
> +	if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev))
> +		mem_size = SZ_8M;
> +
>  	if (mfc_mem_size)
>  		mem_size = memparse(mfc_mem_size, NULL);
> 

The driver allows the user to set mem_size > SZ_4M using the s5p_mfc.mem
parameter even when CMA ins't enabled and IOMMU isn't available. Maybe it
should fail early instead and notify the user what's missing?

Best regards,
Marek Szyprowski Feb. 20, 2017, 1:23 p.m. UTC | #2
Hi Javier,

On 2017-02-17 22:13, Javier Martinez Canillas wrote:
> On 02/14/2017 04:52 AM, Marek Szyprowski wrote:
>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>> requirement for ALL buffers to be allocated on higher addresses than the
>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the
>> special DMA configuration based on two reserved memory regions is not
>> really needed for MFC v6+ devices, because the memory requirements for the
>> firmware, device and per-context buffers can be fulfilled by the simple
>> probe-time pre-allocated block allocator instroduced in previous patch.
> s/instroduced/introduced
>
>> This patch enables support for such pre-allocated block based allocator
>> always for MFC v6+ devices. Due to the limitations of the memory management
>> subsystem the largest supported size of the pre-allocated buffer when no
>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>
>> This patch also removes the requirement to provide two reserved memory
>> regions for MFC v6+ devices in device tree. Now the driver is fully
>> functional without them.
>>
> Great!
>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
> The patch looks good to me though and it works on my tests,
> I've just one comment below.
>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
>>   Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
>>   drivers/media/platform/s5p-mfc/s5p_mfc.c            | 9 ++++++---
>>   2 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>> index 2c901286d818..d3404b5d4d17 100644
>> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
>> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>> @@ -28,7 +28,7 @@ Optional properties:
>>     - memory-region : from reserved memory binding: phandles to two reserved
>>   	memory regions, first is for "left" mfc memory bus interfaces,
>>   	second if for the "right" mfc memory bus, used when no SYSMMU
>> -	support is available
>> +	support is available; used only by MFC v5 present in Exynos4 SoCs
>>   
>>   Obsolete properties:
>>     - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> index 8fc6fe4ba087..36f0aec2a1b3 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev)
>>   static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
>>   {
>>   	struct device *dev = &mfc_dev->plat_dev->dev;
>> -	unsigned long mem_size = SZ_8M;
>> +	unsigned long mem_size = SZ_4M;
>>   	unsigned int bitmap_size;
>>   
>> +	if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev))
>> +		mem_size = SZ_8M;
>> +
>>   	if (mfc_mem_size)
>>   		mem_size = memparse(mfc_mem_size, NULL);
>>
> The driver allows the user to set mem_size > SZ_4M using the s5p_mfc.mem
> parameter even when CMA ins't enabled and IOMMU isn't available. Maybe it
> should fail early instead and notify the user what's missing?

It will notify user that driver failed to preallocate memory. 4M is the 
upper
limit for standard kernel configuration, but afair there were some kconfig
knobs to force kernel to use larger buckets for buddy allocator (what 
changes
the limit). Frankly I would leave it as is.

If user wants to specify s5p-mfc.mem, he already has some knowledge how to
configure the kernel. I don't think that driver should check all possible
scenarios of failing and give detailed explanation what was configured
wrong. You can also enable CMA and configure the 8MiB of the default global
area. In such configuration preallocation of mfc firmware buffer will also
fail. Should the driver care about it? IMO it is enough to tell user that
preallocating of given megabytes failed.

Best regards
Javier Martinez Canillas Feb. 20, 2017, 1:27 p.m. UTC | #3
Hello Marek,

On 02/20/2017 10:23 AM, Marek Szyprowski wrote:
> Hi Javier,
> 
> On 2017-02-17 22:13, Javier Martinez Canillas wrote:
>> On 02/14/2017 04:52 AM, Marek Szyprowski wrote:
>>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>>> requirement for ALL buffers to be allocated on higher addresses than the
>>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the
>>> special DMA configuration based on two reserved memory regions is not
>>> really needed for MFC v6+ devices, because the memory requirements for the
>>> firmware, device and per-context buffers can be fulfilled by the simple
>>> probe-time pre-allocated block allocator instroduced in previous patch.
>> s/instroduced/introduced
>>
>>> This patch enables support for such pre-allocated block based allocator
>>> always for MFC v6+ devices. Due to the limitations of the memory management
>>> subsystem the largest supported size of the pre-allocated buffer when no
>>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>>
>>> This patch also removes the requirement to provide two reserved memory
>>> regions for MFC v6+ devices in device tree. Now the driver is fully
>>> functional without them.
>>>
>> Great!
>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> ---
>> The patch looks good to me though and it works on my tests,
>> I've just one comment below.
>>
>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>
>>>   Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
>>>   drivers/media/platform/s5p-mfc/s5p_mfc.c            | 9 ++++++---
>>>   2 files changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>> index 2c901286d818..d3404b5d4d17 100644
>>> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>> @@ -28,7 +28,7 @@ Optional properties:
>>>     - memory-region : from reserved memory binding: phandles to two reserved
>>>       memory regions, first is for "left" mfc memory bus interfaces,
>>>       second if for the "right" mfc memory bus, used when no SYSMMU
>>> -    support is available
>>> +    support is available; used only by MFC v5 present in Exynos4 SoCs
>>>     Obsolete properties:
>>>     - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
>>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> index 8fc6fe4ba087..36f0aec2a1b3 100644
>>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev)
>>>   static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
>>>   {
>>>       struct device *dev = &mfc_dev->plat_dev->dev;
>>> -    unsigned long mem_size = SZ_8M;
>>> +    unsigned long mem_size = SZ_4M;
>>>       unsigned int bitmap_size;
>>>   +    if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev))
>>> +        mem_size = SZ_8M;
>>> +
>>>       if (mfc_mem_size)
>>>           mem_size = memparse(mfc_mem_size, NULL);
>>>
>> The driver allows the user to set mem_size > SZ_4M using the s5p_mfc.mem
>> parameter even when CMA ins't enabled and IOMMU isn't available. Maybe it
>> should fail early instead and notify the user what's missing?
> 
> It will notify user that driver failed to preallocate memory. 4M is the upper
> limit for standard kernel configuration, but afair there were some kconfig
> knobs to force kernel to use larger buckets for buddy allocator (what changes
> the limit). Frankly I would leave it as is.
> 
> If user wants to specify s5p-mfc.mem, he already has some knowledge how to
> configure the kernel. I don't think that driver should check all possible
> scenarios of failing and give detailed explanation what was configured
> wrong. You can also enable CMA and configure the 8MiB of the default global
> area. In such configuration preallocation of mfc firmware buffer will also
> fail. Should the driver care about it? IMO it is enough to tell user that
> preallocating of given megabytes failed.
> 

Right, it makes sense to leave it at is then indeed and let the users figure
out why the allocation failed with their specific kernel configuration.

> Best regards

Best regards,
Shuah Khan Feb. 23, 2017, 9:43 p.m. UTC | #4
On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> It turned out that all versions of MFC v6+ hardware doesn't have a strict
> requirement for ALL buffers to be allocated on higher addresses than the
> firmware base like it was documented for MFC v5. 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. Basing on this fact, the
> special DMA configuration based on two reserved memory regions is not
> really needed for MFC v6+ devices, because the memory requirements for the
> firmware, device and per-context buffers can be fulfilled by the simple
> probe-time pre-allocated block allocator instroduced in previous patch.
>
> This patch enables support for such pre-allocated block based allocator
> always for MFC v6+ devices. Due to the limitations of the memory management
> subsystem the largest supported size of the pre-allocated buffer when no
> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>
> This patch also removes the requirement to provide two reserved memory
> regions for MFC v6+ devices in device tree. Now the driver is fully
> functional without them.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

Hi Marek,

This patch breaks display manager. exynos_drm_gem_create() isn't happy.
dmesg and console are flooded with

odroid login: [  209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to allo.
[  212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.

I don't think this is an acceptable behavior. It is a regression.

thanks,
-- Shuah

> ---
>  Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc.c            | 9 ++++++---
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> index 2c901286d818..d3404b5d4d17 100644
> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> @@ -28,7 +28,7 @@ Optional properties:
>    - memory-region : from reserved memory binding: phandles to two reserved
>         memory regions, first is for "left" mfc memory bus interfaces,
>         second if for the "right" mfc memory bus, used when no SYSMMU
> -       support is available
> +       support is available; used only by MFC v5 present in Exynos4 SoCs
>
>  Obsolete properties:
>    - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 8fc6fe4ba087..36f0aec2a1b3 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev)
>  static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
>  {
>         struct device *dev = &mfc_dev->plat_dev->dev;
> -       unsigned long mem_size = SZ_8M;
> +       unsigned long mem_size = SZ_4M;
>         unsigned int bitmap_size;
>
> +       if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev))
> +               mem_size = SZ_8M;
> +
>         if (mfc_mem_size)
>                 mem_size = memparse(mfc_mem_size, NULL);
>
> @@ -1240,7 +1243,7 @@ static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev)
>  {
>         struct device *dev = &mfc_dev->plat_dev->dev;
>
> -       if (exynos_is_iommu_available(dev))
> +       if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev))
>                 return s5p_mfc_configure_common_memory(mfc_dev);
>         else
>                 return s5p_mfc_configure_2port_memory(mfc_dev);
> @@ -1251,7 +1254,7 @@ static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
>         struct device *dev = &mfc_dev->plat_dev->dev;
>
>         s5p_mfc_release_firmware(mfc_dev);
> -       if (exynos_is_iommu_available(dev))
> +       if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev))
>                 s5p_mfc_unconfigure_common_memory(mfc_dev);
>         else
>                 s5p_mfc_unconfigure_2port_memory(mfc_dev);
> --
> 1.9.1
>
--
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
Marek Szyprowski Feb. 24, 2017, 6:26 a.m. UTC | #5
Hi Shuah


On 2017-02-23 22:43, Shuah Khan wrote:
> On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>> requirement for ALL buffers to be allocated on higher addresses than the
>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the
>> special DMA configuration based on two reserved memory regions is not
>> really needed for MFC v6+ devices, because the memory requirements for the
>> firmware, device and per-context buffers can be fulfilled by the simple
>> probe-time pre-allocated block allocator instroduced in previous patch.
>>
>> This patch enables support for such pre-allocated block based allocator
>> always for MFC v6+ devices. Due to the limitations of the memory management
>> subsystem the largest supported size of the pre-allocated buffer when no
>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>
>> This patch also removes the requirement to provide two reserved memory
>> regions for MFC v6+ devices in device tree. Now the driver is fully
>> functional without them.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Hi Marek,
>
> This patch breaks display manager. exynos_drm_gem_create() isn't happy.
> dmesg and console are flooded with
>
> odroid login: [  209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to allo.
> [  212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
> [  298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
>
> I don't think this is an acceptable behavior. It is a regression.

This is a really poor bug report... Could you elaborate a bit how to 
reproduce
this? Could you provide your kernel config and information about test 
environment?

I suspect that you use CMA without IOMMU and you have too small global 
CMA region.
After this patch MFC driver uses global CMA region instead of the MFC's 
private
ones, so one has to ensure that the global region is large enough.

 > [...]

Best regards
Shuah Khan Feb. 24, 2017, 2:23 p.m. UTC | #6
Hi Marek,

On Thu, Feb 23, 2017 at 11:26 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Hi Shuah
>
>
>
> On 2017-02-23 22:43, Shuah Khan wrote:
>>
>> On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
>>>
>>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>>> requirement for ALL buffers to be allocated on higher addresses than the
>>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the
>>> special DMA configuration based on two reserved memory regions is not
>>> really needed for MFC v6+ devices, because the memory requirements for
>>> the
>>> firmware, device and per-context buffers can be fulfilled by the simple
>>> probe-time pre-allocated block allocator instroduced in previous patch.
>>>
>>> This patch enables support for such pre-allocated block based allocator
>>> always for MFC v6+ devices. Due to the limitations of the memory
>>> management
>>> subsystem the largest supported size of the pre-allocated buffer when no
>>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>>
>>> This patch also removes the requirement to provide two reserved memory
>>> regions for MFC v6+ devices in device tree. Now the driver is fully
>>> functional without them.
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> Hi Marek,
>>
>> This patch breaks display manager. exynos_drm_gem_create() isn't happy.
>> dmesg and console are flooded with
>>
>> odroid login: [  209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to
>> allo.
>> [  212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>>
>> I don't think this is an acceptable behavior. It is a regression.
>
>
> This is a really poor bug report... Could you elaborate a bit how to
> reproduce
> this? Could you provide your kernel config and information about test
> environment?

Yeah. I should have give you more information. My bad.

>
> I suspect that you use CMA without IOMMU and you have too small global CMA
> region.

Yes. I have CMA and using exynos_defconfig. Nothing fancy. I think
what's happening is s5p_mfc pre-allocates and there is nothing left
when disaply manager starts requestuing gem buffers. This failure
happens when systemd kicks off lightdm.

> After this patch MFC driver uses global CMA region instead of the MFC's
> private
> ones, so one has to ensure that the global region is large enough.

This is still a regression since it requires users to take some
action. I think we need some kind of checks to warn users there isn't
a large enough CMA region. This is the same config I have been using
forever and with this patch, it breaks.

Easy to reproduce on odroid-xu4 with HDMI display. You just have to
boot the system with exynos_defconfig. Display manager will fail when
it requests buffers.

thanks,
-- Shuah

>
>> [...]
>
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
--
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
Marek Szyprowski Feb. 27, 2017, 12:50 p.m. UTC | #7
Hi Shuah,

On 2017-02-24 15:23, Shuah Khan wrote:
> On Thu, Feb 23, 2017 at 11:26 PM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 2017-02-23 22:43, Shuah Khan wrote:
>>> On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski
>>> <m.szyprowski@samsung.com> wrote:
>>>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>>>> requirement for ALL buffers to be allocated on higher addresses than the
>>>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the
>>>> special DMA configuration based on two reserved memory regions is not
>>>> really needed for MFC v6+ devices, because the memory requirements for
>>>> the
>>>> firmware, device and per-context buffers can be fulfilled by the simple
>>>> probe-time pre-allocated block allocator instroduced in previous patch.
>>>>
>>>> This patch enables support for such pre-allocated block based allocator
>>>> always for MFC v6+ devices. Due to the limitations of the memory
>>>> management
>>>> subsystem the largest supported size of the pre-allocated buffer when no
>>>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>>>
>>>> This patch also removes the requirement to provide two reserved memory
>>>> regions for MFC v6+ devices in device tree. Now the driver is fully
>>>> functional without them.
>>>>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> Hi Marek,
>>>
>>> This patch breaks display manager. exynos_drm_gem_create() isn't happy.
>>> dmesg and console are flooded with
>>>
>>> odroid login: [  209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to
>>> allo.
>>> [  212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>> [  298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>> buffer.
>>>
>>> I don't think this is an acceptable behavior. It is a regression.
>>
>> This is a really poor bug report... Could you elaborate a bit how to
>> reproduce
>> this? Could you provide your kernel config and information about test
>> environment?
> Yeah. I should have give you more information. My bad.
>
>> I suspect that you use CMA without IOMMU and you have too small global CMA
>> region.
> Yes. I have CMA and using exynos_defconfig. Nothing fancy. I think
> what's happening is s5p_mfc pre-allocates and there is nothing left
> when disaply manager starts requestuing gem buffers. This failure
> happens when systemd kicks off lightdm.
>
>> After this patch MFC driver uses global CMA region instead of the MFC's
>> private
>> ones, so one has to ensure that the global region is large enough.
> This is still a regression since it requires users to take some
> action. I think we need some kind of checks to warn users there isn't
> a large enough CMA region. This is the same config I have been using
> forever and with this patch, it breaks.
>
> Easy to reproduce on odroid-xu4 with HDMI display. You just have to
> boot the system with exynos_defconfig. Display manager will fail when
> it requests buffers.

That is still a bit strange. MFC pre-allocates 8MiB buffer. The default CMA
global region size is 64MiB, which should be enough for a few display 
buffers.
It looks that your display manager consumes quite a lot of memory and it
already almost hits the limit from the exynos_defconfig.

It should be safe to increase default CMA region size to 80MiB or even 96MiB
in the exynos_defconfig to avoid such problem.

Best regards
Shuah Khan Feb. 28, 2017, 12:29 a.m. UTC | #8
On 02/27/2017 05:50 AM, Marek Szyprowski wrote:
> Hi Shuah,
> 
> On 2017-02-24 15:23, Shuah Khan wrote:
>> On Thu, Feb 23, 2017 at 11:26 PM, Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
>>> On 2017-02-23 22:43, Shuah Khan wrote:
>>>> On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski
>>>> <m.szyprowski@samsung.com> wrote:
>>>>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>>>>> requirement for ALL buffers to be allocated on higher addresses than the
>>>>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the
>>>>> special DMA configuration based on two reserved memory regions is not
>>>>> really needed for MFC v6+ devices, because the memory requirements for
>>>>> the
>>>>> firmware, device and per-context buffers can be fulfilled by the simple
>>>>> probe-time pre-allocated block allocator instroduced in previous patch.
>>>>>
>>>>> This patch enables support for such pre-allocated block based allocator
>>>>> always for MFC v6+ devices. Due to the limitations of the memory
>>>>> management
>>>>> subsystem the largest supported size of the pre-allocated buffer when no
>>>>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>>>>
>>>>> This patch also removes the requirement to provide two reserved memory
>>>>> regions for MFC v6+ devices in device tree. Now the driver is fully
>>>>> functional without them.
>>>>>
>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Hi Marek,
>>>>
>>>> This patch breaks display manager. exynos_drm_gem_create() isn't happy.
>>>> dmesg and console are flooded with
>>>>
>>>> odroid login: [  209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to
>>>> allo.
>>>> [  212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>>
>>>> I don't think this is an acceptable behavior. It is a regression.
>>>
>>> This is a really poor bug report... Could you elaborate a bit how to
>>> reproduce
>>> this? Could you provide your kernel config and information about test
>>> environment?
>> Yeah. I should have give you more information. My bad.
>>
>>> I suspect that you use CMA without IOMMU and you have too small global CMA
>>> region.
>> Yes. I have CMA and using exynos_defconfig. Nothing fancy. I think
>> what's happening is s5p_mfc pre-allocates and there is nothing left
>> when disaply manager starts requestuing gem buffers. This failure
>> happens when systemd kicks off lightdm.
>>
>>> After this patch MFC driver uses global CMA region instead of the MFC's
>>> private
>>> ones, so one has to ensure that the global region is large enough.
>> This is still a regression since it requires users to take some
>> action. I think we need some kind of checks to warn users there isn't
>> a large enough CMA region. This is the same config I have been using
>> forever and with this patch, it breaks.
>>
>> Easy to reproduce on odroid-xu4 with HDMI display. You just have to
>> boot the system with exynos_defconfig. Display manager will fail when
>> it requests buffers.
> 
> That is still a bit strange. MFC pre-allocates 8MiB buffer. The default CMA
> global region size is 64MiB, which should be enough for a few display buffers.
> It looks that your display manager consumes quite a lot of memory and it
> already almost hits the limit from the exynos_defconfig.
> 
> It should be safe to increase default CMA region size to 80MiB or even 96MiB
> in the exynos_defconfig to avoid such problem.

Increasing CONFIG_CMA_SIZE_MBYTES to 96 in exynos_defconfig worked for me.
No more gem buffer allocation errors. I sent in a patch to exynos_defconfig
with your Suggested-by

thanks,
-- Shuah
> 
> Best regards

--
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
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2c901286d818..d3404b5d4d17 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -28,7 +28,7 @@  Optional properties:
   - memory-region : from reserved memory binding: phandles to two reserved
 	memory regions, first is for "left" mfc memory bus interfaces,
 	second if for the "right" mfc memory bus, used when no SYSMMU
-	support is available
+	support is available; used only by MFC v5 present in Exynos4 SoCs
 
 Obsolete properties:
   - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8fc6fe4ba087..36f0aec2a1b3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1178,9 +1178,12 @@  static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev)
 static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
 {
 	struct device *dev = &mfc_dev->plat_dev->dev;
-	unsigned long mem_size = SZ_8M;
+	unsigned long mem_size = SZ_4M;
 	unsigned int bitmap_size;
 
+	if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev))
+		mem_size = SZ_8M;
+
 	if (mfc_mem_size)
 		mem_size = memparse(mfc_mem_size, NULL);
 
@@ -1240,7 +1243,7 @@  static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev)
 {
 	struct device *dev = &mfc_dev->plat_dev->dev;
 
-	if (exynos_is_iommu_available(dev))
+	if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev))
 		return s5p_mfc_configure_common_memory(mfc_dev);
 	else
 		return s5p_mfc_configure_2port_memory(mfc_dev);
@@ -1251,7 +1254,7 @@  static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
 	struct device *dev = &mfc_dev->plat_dev->dev;
 
 	s5p_mfc_release_firmware(mfc_dev);
-	if (exynos_is_iommu_available(dev))
+	if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev))
 		s5p_mfc_unconfigure_common_memory(mfc_dev);
 	else
 		s5p_mfc_unconfigure_2port_memory(mfc_dev);