All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Javier Martinez Canillas <javier@osg.samsung.com>,
	linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org
Cc: devicetree@vger.kernel.org,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Kamil Debski <k.debski@samsung.com>,
	Kukjin Kim <kgene@kernel.org>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Uli Middelberg <uli@middelberg.de>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH v4 6/7] ARM: dts: exynos: convert MFC device to generic reserved memory bindings
Date: Fri, 27 May 2016 13:32:57 +0200	[thread overview]
Message-ID: <f0148d4b-a69c-c84b-4a5e-4ff6bb9fde6f@samsung.com> (raw)
In-Reply-To: <0158bb7a-02cf-bbb3-f903-d99c7351dfc4@osg.samsung.com>

Hello,


On 2016-05-25 19:11, Javier Martinez Canillas wrote:
> Hello Marek,
>
> On 05/24/2016 09:31 AM, Marek Szyprowski wrote:
>> This patch replaces custom properties for defining reserved memory
>> regions with generic reserved memory bindings for MFC video codec
>> device.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
> [snip]
>
>> +
>> +/ {
>> +	reserved-memory {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		mfc_left: region@51000000 {
>> +			compatible = "shared-dma-pool";
>> +			no-map;
>> +			reg = <0x51000000 0x800000>;
>> +		};
>> +
>> +		mfc_right: region@43000000 {
>> +			compatible = "shared-dma-pool";
>> +			no-map;
>> +			reg = <0x43000000 0x800000>;
>> +		};
>> +	};
> I've a question probably for a follow up patch, but do you know what's a
> sane default size for these? I needed to bump the mfc_left size from 8 MiB
> to 16 MiB in order to decode a 480p H264 video using GStramer. So clearly
> the default sizes are not that useful.

Right, the default size for the 'left' region can be increased. Frankly, 
those
values (8MiB/0x43000000+ 8MiB/0x51000000) comes from my initial patches
prepared for some demo and don't have much with any real requirements. They
were copied (blindly...) by various developers without any deeper 
understanding.
Probably the most sane would be to use something like this:

mfc_left: region_mfc_left {
          compatible = "shared-dma-pool";
          no-map;
          size = <0x1000000>;
          alignment = <0x100000>;
};

mfc_right: region_mfc_right {
          compatible = "shared-dma-pool";
          no-map;
          size = <0x800000>;
          alignment = <0x100000>;
};

So the region will be allocated automatically from the available memory. 
This way
another nice feature of the generic reserved memory regions can be used.

The only platform which really requires MFC regions to be placed at 
certain memory
offsets is Samsung S5PV210/S5PC110 (sometimes called exynos3), where 
there is no
memory address interleaving and MFC device has limited memory interface, 
which cannot
do 2 transactions to the same physical memory bank. However 
S5PV210/S5PC110 machine
code lost support for MFC during conversion to device tree, so it is not 
a problem
here.

All newer platforms (Exynos4, Exynos3250, Exynos5+) use memory 
interleaving, so the
actual offset of memory bank has no influence on the physical memory bank.

>> +};
>> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
>> index ad7394c..f5e4eb2 100644
>> --- a/arch/arm/boot/dts/exynos4210-origen.dts
>> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
>> @@ -18,6 +18,7 @@
>>   #include "exynos4210.dtsi"
>>   #include <dt-bindings/gpio/gpio.h>
>>   #include <dt-bindings/input/input.h>
>> +#include "exynos-mfc-reserved-memory.dtsi"
>>   
>>   / {
>>   	model = "Insignal Origen evaluation board based on Exynos4210";
>> @@ -288,8 +289,7 @@
>>   };
>>   
>>   &mfc {
>> -	samsung,mfc-r = <0x43000000 0x800000>;
>> -	samsung,mfc-l = <0x51000000 0x800000>;
>> +	memory-region = <&mfc_left>, <&mfc_right>;
>>   	status = "okay";
> I wonder if shouldn't be better to include the exynos-mfc-reserved-memory.dtsi
> on each SoC dtsi and set the memory-regions in the MFC node instead of doing
> it on each DTS, and let DTS to just replace with its own memory regions if the
> default sizes are not suitable for them.

I don't have strong opinion on this. Maybe it would make more sense to 
move the
following entry:

&mfc {
         memory-region = <&mfc_left>, <&mfc_right>;
};

also to the exynos-mfc-reserved-memory.dtsi ? So board will just include 
it if
it want to use MFC device with reserved memory regions.

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

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

  reply	other threads:[~2016-05-27 11:32 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-24 13:31 [PATCH v4 0/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support Marek Szyprowski
2016-05-24 13:31 ` [PATCH v4 1/7] of: reserved_mem: add support for using more than one region for given device Marek Szyprowski
2016-05-26 19:08   ` Rob Herring
2016-05-24 13:31 ` [PATCH v4 2/7] media: s5p-mfc: use generic reserved memory bindings Marek Szyprowski
2016-05-25 15:18   ` Javier Martinez Canillas
2016-05-25 17:36     ` Rob Herring
2016-05-27  6:37       ` Marek Szyprowski
2016-05-27 20:41         ` Javier Martinez Canillas
2016-05-25 17:39   ` Rob Herring
2016-05-27  6:19   ` Krzysztof Kozlowski
2016-05-24 13:31 ` [PATCH v4 3/7] media: s5p-mfc: replace custom reserved memory handling code with generic one Marek Szyprowski
2016-05-25 15:42   ` Javier Martinez Canillas
2016-05-25 16:51     ` Javier Martinez Canillas
     [not found]   ` <1464096690-23605-4-git-send-email-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-06-08 10:36     ` Liviu Dudau
2016-06-08 10:36       ` Liviu Dudau
2016-06-08 11:33       ` [PATCH] media: s5p-mfc: fix error path in driver probe Marek Szyprowski
2016-06-08 14:35         ` Liviu Dudau
2016-06-08 21:44           ` Shuah Khan
     [not found] ` <1464096690-23605-1-git-send-email-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-05-24 13:31   ` [PATCH v4 4/7] media: s5p-mfc: add iommu support Marek Szyprowski
2016-05-24 13:31     ` Marek Szyprowski
2016-05-25 15:55     ` Javier Martinez Canillas
2016-05-24 13:31 ` [PATCH v4 5/7] ARM: Exynos: remove code for MFC custom reserved memory handling Marek Szyprowski
2016-05-25 15:57   ` Javier Martinez Canillas
2016-05-30  7:28   ` Krzysztof Kozlowski
2016-06-02 15:20     ` Javier Martinez Canillas
2016-06-02 16:31       ` Krzysztof Kozlowski
2016-06-02 17:25         ` Javier Martinez Canillas
2016-06-03  6:57           ` Krzysztof Kozlowski
2016-06-03  9:59             ` [ATTN] " Sylwester Nawrocki
2016-06-06  7:24               ` Krzysztof Kozlowski
2016-06-06  7:40             ` Krzysztof Kozlowski
2016-05-24 13:31 ` [PATCH v4 6/7] ARM: dts: exynos: convert MFC device to generic reserved memory bindings Marek Szyprowski
2016-05-25 11:13   ` Krzysztof Kozlowski
2016-05-25 17:11   ` Javier Martinez Canillas
2016-05-27 11:32     ` Marek Szyprowski [this message]
2016-05-27 20:54       ` Javier Martinez Canillas
2016-06-07 12:03         ` [PATCH 1/3] ARM: dts: exynos: replace hardcoded reserved memory ranges with auto-allocated ones Marek Szyprowski
2016-06-07 12:03           ` [PATCH 2/3] ARM: dts: exynos: move MFC reserved memory regions from boards to .dtsi Marek Szyprowski
2016-06-07 22:34             ` Javier Martinez Canillas
2016-06-07 12:03           ` [PATCH 3/3] ARM: dts: exynos: enable MFC device for all boards Marek Szyprowski
2016-06-07 22:34             ` Javier Martinez Canillas
2016-06-07 22:32           ` [PATCH 1/3] ARM: dts: exynos: replace hardcoded reserved memory ranges with auto-allocated ones Javier Martinez Canillas
2016-06-08  7:48           ` Krzysztof Kozlowski
2016-05-24 13:31 ` [PATCH v4 7/7] ARM: dts: exynos4412-odroid*: enable MFC device Marek Szyprowski
     [not found]   ` <1464096690-23605-8-git-send-email-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-05-25 17:13     ` Javier Martinez Canillas
2016-05-25 17:13       ` Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f0148d4b-a69c-c84b-4a5e-4ff6bb9fde6f@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=javier@osg.samsung.com \
    --cc=k.debski@samsung.com \
    --cc=k.kozlowski@samsung.com \
    --cc=kgene@kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=s.nawrocki@samsung.com \
    --cc=uli@middelberg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.