From: Kukjin Kim <kgene.kim@samsung.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-media@vger.kernel.org,
Kyungmin Park <kyungmin.park@samsung.com>,
Grant Likely <grant.likely@secretlab.ca>,
Tomasz Figa <t.figa@samsung.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Kamil Debski <k.debski@samsung.com>,
Sachin Kamat <sachin.kamat@linaro.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Rob Herring <robherring2@gmail.com>,
Olof Johansson <olof@lixom.net>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH 0/2] Exynos: MFC: clean up device tree bindings
Date: Tue, 06 Aug 2013 02:12:54 +0900 [thread overview]
Message-ID: <51FFDD16.80907@samsung.com> (raw)
In-Reply-To: <1375705610-12724-1-git-send-email-m.szyprowski@samsung.com>
On 08/05/13 21:26, Marek Szyprowski wrote:
> Hello,
>
Hi,
> This patch series are an attempt to cleanup the reserved memory device
> tree bindings for MFC device. MFC device has two memory ports (AXI
> masters), which are used to do DMA. Usually separate memory regions are
> being defined for each of those memory ports to improve performance.
> Some versions of MFC block have also significant limitation on the
> possible address range available for each of those memory ports/banks.
>
> In the board file era, there have been two additional platform devices
> defined for each of memory ports (named "s5p-mfc-l" and "s5p-mfc-r") to
> let the driver distinguish memory allocations done for each of them.
> Each of those platform devices might have special DMA ops assigned to
> fulfil specific memory requirements for a given memory port.
>
> Later, when device tree binding was added for MFC device, those memory
> ports were designed as two additional properties: "samsung,mfc-l" and
> "samsung,mfc-r" for codec node. This approach however has some
> significant limitation, so I propose to redesign it before the binding
> become considered as stable.
>
> The first problem with the proposed bindings is the fact that
> "samsung,mfc-r"/"samsung,mfc-l" properties are tied only to "base
> address + size" attributes of reserved memory and do not allow to assign
> any other attributes to those memory ports. This limits using those
> memory ports only to simple reserved memory.
>
> The second issue with those attributes is the fact that they are very
> specific to the MFC device, while reserved memory region is something
> more generic, which can be used for other devices as well. For example
> even on Exynos4 platform, similar reserved memory handling will be
> needed for the FIMC ISP device.
>
> For handling reserved memory regions and having a method to assign them
> to particular device I have posted the patches [1], which add device
> tree support to Contiguous Memory Allocator and simple reserved memory
> allocator based on dma_declare_coherent() function.
>
> This patch series is my proposal for replacing those custom bindings
> with generic approach, proposed in [1]. To get it working we need
> separate device node for each memory port, what has been achieved by
> adding "simple-bus" compatibility entry to the main MFC device node and
> adding two child nodes, which represent each memory port. Those child
> nodes have compatible property set to "samsung,memport".
>
> With such a structure "dma-memory-region" property with a phandle to
> respective reserved region can be easily added to the child nodes of MFC
> device. The advantage of such approach is the fact that those child
> nodes can be also used for adding properties for IOMMU (SYSMMU)
> controllers. This way also bindings for SYSMMU and the code, which
> handles it can be simplified, because respective device tree part better
> matches physical hardware design.
>
> Best regards
> Marek Szyprowski
> Samsung R&D Institute Poland
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/257615/
>
>
> Patch summary:
>
> Marek Szyprowski (2):
> ARM: Exynos: replace custom MFC reserved memory handling with generic
> code
> media: s5p-mfc: remove DT hacks and simplify initialization code
>
> .../devicetree/bindings/media/s5p-mfc.txt | 63 +++++++++++++---
> arch/arm/boot/dts/exynos4.dtsi | 10 ++-
> arch/arm/boot/dts/exynos4210-origen.dts | 25 ++++++-
> arch/arm/boot/dts/exynos4210-smdkv310.dts | 25 ++++++-
> arch/arm/boot/dts/exynos4412-origen.dts | 25 ++++++-
> arch/arm/boot/dts/exynos4412-smdk4412.dts | 25 ++++++-
> arch/arm/boot/dts/exynos5250-arndale.dts | 26 ++++++-
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 26 ++++++-
> arch/arm/boot/dts/exynos5250.dtsi | 10 ++-
> arch/arm/mach-exynos/mach-exynos4-dt.c | 16 -----
> arch/arm/mach-exynos/mach-exynos5-dt.c | 17 -----
> arch/arm/plat-samsung/include/plat/mfc.h | 11 ---
> arch/arm/plat-samsung/s5p-dev-mfc.c | 32 ---------
> drivers/media/platform/s5p-mfc/s5p_mfc.c | 75 ++++----------------
> 14 files changed, 227 insertions(+), 159 deletions(-)
>
Nice cleanup MFC dt bindings, BTW, IMHO, how about keeping the reserved
memory in exynos4.dtsi instead of adding them in each board dts files,
it depends on board though...
Kamil, if you're OK on the 2nd patch, please let me know so that this
could be merged into samsung tree for v3.12..
Thanks,
Kukjin
WARNING: multiple messages have this Message-ID (diff)
From: kgene.kim@samsung.com (Kukjin Kim)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] Exynos: MFC: clean up device tree bindings
Date: Tue, 06 Aug 2013 02:12:54 +0900 [thread overview]
Message-ID: <51FFDD16.80907@samsung.com> (raw)
In-Reply-To: <1375705610-12724-1-git-send-email-m.szyprowski@samsung.com>
On 08/05/13 21:26, Marek Szyprowski wrote:
> Hello,
>
Hi,
> This patch series are an attempt to cleanup the reserved memory device
> tree bindings for MFC device. MFC device has two memory ports (AXI
> masters), which are used to do DMA. Usually separate memory regions are
> being defined for each of those memory ports to improve performance.
> Some versions of MFC block have also significant limitation on the
> possible address range available for each of those memory ports/banks.
>
> In the board file era, there have been two additional platform devices
> defined for each of memory ports (named "s5p-mfc-l" and "s5p-mfc-r") to
> let the driver distinguish memory allocations done for each of them.
> Each of those platform devices might have special DMA ops assigned to
> fulfil specific memory requirements for a given memory port.
>
> Later, when device tree binding was added for MFC device, those memory
> ports were designed as two additional properties: "samsung,mfc-l" and
> "samsung,mfc-r" for codec node. This approach however has some
> significant limitation, so I propose to redesign it before the binding
> become considered as stable.
>
> The first problem with the proposed bindings is the fact that
> "samsung,mfc-r"/"samsung,mfc-l" properties are tied only to "base
> address + size" attributes of reserved memory and do not allow to assign
> any other attributes to those memory ports. This limits using those
> memory ports only to simple reserved memory.
>
> The second issue with those attributes is the fact that they are very
> specific to the MFC device, while reserved memory region is something
> more generic, which can be used for other devices as well. For example
> even on Exynos4 platform, similar reserved memory handling will be
> needed for the FIMC ISP device.
>
> For handling reserved memory regions and having a method to assign them
> to particular device I have posted the patches [1], which add device
> tree support to Contiguous Memory Allocator and simple reserved memory
> allocator based on dma_declare_coherent() function.
>
> This patch series is my proposal for replacing those custom bindings
> with generic approach, proposed in [1]. To get it working we need
> separate device node for each memory port, what has been achieved by
> adding "simple-bus" compatibility entry to the main MFC device node and
> adding two child nodes, which represent each memory port. Those child
> nodes have compatible property set to "samsung,memport".
>
> With such a structure "dma-memory-region" property with a phandle to
> respective reserved region can be easily added to the child nodes of MFC
> device. The advantage of such approach is the fact that those child
> nodes can be also used for adding properties for IOMMU (SYSMMU)
> controllers. This way also bindings for SYSMMU and the code, which
> handles it can be simplified, because respective device tree part better
> matches physical hardware design.
>
> Best regards
> Marek Szyprowski
> Samsung R&D Institute Poland
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/257615/
>
>
> Patch summary:
>
> Marek Szyprowski (2):
> ARM: Exynos: replace custom MFC reserved memory handling with generic
> code
> media: s5p-mfc: remove DT hacks and simplify initialization code
>
> .../devicetree/bindings/media/s5p-mfc.txt | 63 +++++++++++++---
> arch/arm/boot/dts/exynos4.dtsi | 10 ++-
> arch/arm/boot/dts/exynos4210-origen.dts | 25 ++++++-
> arch/arm/boot/dts/exynos4210-smdkv310.dts | 25 ++++++-
> arch/arm/boot/dts/exynos4412-origen.dts | 25 ++++++-
> arch/arm/boot/dts/exynos4412-smdk4412.dts | 25 ++++++-
> arch/arm/boot/dts/exynos5250-arndale.dts | 26 ++++++-
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 26 ++++++-
> arch/arm/boot/dts/exynos5250.dtsi | 10 ++-
> arch/arm/mach-exynos/mach-exynos4-dt.c | 16 -----
> arch/arm/mach-exynos/mach-exynos5-dt.c | 17 -----
> arch/arm/plat-samsung/include/plat/mfc.h | 11 ---
> arch/arm/plat-samsung/s5p-dev-mfc.c | 32 ---------
> drivers/media/platform/s5p-mfc/s5p_mfc.c | 75 ++++----------------
> 14 files changed, 227 insertions(+), 159 deletions(-)
>
Nice cleanup MFC dt bindings, BTW, IMHO, how about keeping the reserved
memory in exynos4.dtsi instead of adding them in each board dts files,
it depends on board though...
Kamil, if you're OK on the 2nd patch, please let me know so that this
could be merged into samsung tree for v3.12..
Thanks,
Kukjin
next prev parent reply other threads:[~2013-08-05 17:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 12:26 [PATCH 0/2] Exynos: MFC: clean up device tree bindings Marek Szyprowski
2013-08-05 12:26 ` Marek Szyprowski
2013-08-05 12:26 ` [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code Marek Szyprowski
2013-08-05 12:26 ` Marek Szyprowski
2013-08-08 21:00 ` Stephen Warren
2013-08-08 21:00 ` Stephen Warren
2013-08-08 21:19 ` Tomasz Figa
2013-08-08 21:19 ` Tomasz Figa
2013-08-08 21:47 ` Stephen Warren
2013-08-08 21:47 ` Stephen Warren
2013-08-08 22:10 ` Tomasz Figa
2013-08-08 22:10 ` Tomasz Figa
2013-08-08 22:48 ` Stephen Warren
2013-08-08 22:48 ` Stephen Warren
2013-08-05 12:26 ` [PATCH 2/2] media: s5p-mfc: remove DT hacks and simplify initialization code Marek Szyprowski
2013-08-05 12:26 ` Marek Szyprowski
2013-08-06 10:22 ` Kamil Debski
2013-08-06 10:22 ` Kamil Debski
2013-08-06 22:13 ` Kukjin Kim
2013-08-06 22:13 ` Kukjin Kim
2013-08-06 22:17 ` Tomasz Figa
2013-08-06 22:17 ` Tomasz Figa
2013-08-05 17:12 ` Kukjin Kim [this message]
2013-08-05 17:12 ` [PATCH 0/2] Exynos: MFC: clean up device tree bindings Kukjin Kim
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=51FFDD16.80907@samsung.com \
--to=kgene.kim@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@secretlab.ca \
--cc=ian.campbell@citrix.com \
--cc=k.debski@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=olof@lixom.net \
--cc=pawel.moll@arm.com \
--cc=robherring2@gmail.com \
--cc=s.nawrocki@samsung.com \
--cc=sachin.kamat@linaro.org \
--cc=swarren@wwwdotorg.org \
--cc=t.figa@samsung.com \
/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.