From: Karol Lewandowski <k.lewandowsk@samsung.com>
To: Arun Kumar K <arun.kk@samsung.com>,
Thomas Abraham <thomas.abraham@linaro.org>
Cc: linux-samsung-soc@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, kgene.kim@samsung.com,
k.debski@samsung.com, jtp.park@samsung.com,
ch.naveen@samsung.com, joshi@samsung.com
Subject: Re: [PATCH] ARM: EXYNOS: Add MFC device tree support
Date: Mon, 20 Aug 2012 15:17:23 +0900 [thread overview]
Message-ID: <5031D673.6060104@samsung.com> (raw)
In-Reply-To: <1345120273-22913-2-git-send-email-arun.kk@samsung.com>
On 08/16/2012 08:42 PM, Thomas Abraham wrote:
> On 16 August 2012 18:01, Arun Kumar K <arun.kk ... @public.gmane.org> wrote:
>> + - interrupts : MFC interupt number to the CPU.
>> +
>> + - samsung,mfc-r : Base address of the first memory bank used by MFC
>> + for DMA contiguous memory allocation.
>> +
>> + - samsung,mfc-r-size : Size of the first memory bank.
>
> It is not allowed to pass buffer base address and size from device
> tree. Device tree node should describe only the MFC controller
> hardware. Any memory management related information should be handled
> outside of device tree. This helps the bindings to be reusable across
> multiple operating systems.
The question is where elsewhere this should be described as this is strictly
board-dependent option (number and size of RAM banks are important here).
I agree that base addresses are bad, but I'm not aware of any functionality
that would allow driver (actually, its platform dependent part in
exynosN_reserve() function) to enumerate available memory banks and grab
memory chunks from two distinct banks.
My (lack of) knowledge ARM might be to blame here but I simply don't know
how to achieve this. Any suggestions?
On 08/16/2012 09:31 PM, Arun Kumar K wrote:
> +static void s5p_mfc_reserve_mem(phys_addr_t rbase, unsigned int rsize,
> + phys_addr_t lbase, unsigned int lsize) {
> +
> + if (memblock_remove(lbase, lsize)) {
> + pr_err("Failed to reserve bank1 memory for MFC device\n");
> + WARN_ON(1);
> + }
> +
> + if (memblock_remove(rbase, rsize)) {
> + pr_err("Failed to reserve bank2 memory for MFC device\n");
> + WARN_ON(1);
> + }
> +}
non-static function with the same name is already defined in
arch/arm/plat-samsung/s5p-dev-mfc.c. Please don't duplicate it,
especially that you seem to be trying to do that twice!
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index ef770bc..898d2de 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
...
> +static void s5p_mfc_reserve_mem(phys_addr_t rbase, unsigned int rsize,
> + phys_addr_t lbase, unsigned int lsize) {
> +
> + if (memblock_remove(lbase, lsize)) {
> + pr_err("Failed to reserve bank1 memory for MFC device\n");
> + WARN_ON(1);
> + }
> +
> + if (memblock_remove(rbase, rsize)) {
> + pr_err("Failed to reserve bank2 memory for MFC device\n");
> + WARN_ON(1);
> + }
> +}
See above.
> +
> +static void __init exynos5_reserve(void)
> +{
> + s5p_mfc_reserve_mem(0x43000000, 8 << 20, 0x51000000, 8 << 20);
I think it would make sense to make this memory reservation dependent
on "mfc*" node being present in DTS. It's to early to use of_* functions
(because tree is not populated at this stage) but fdt_* family of functions
work just fine.
Regards,
--
Karol Lewandowski | Samsung Poland R&D Center | Linux/Platform
next prev parent reply other threads:[~2012-08-20 6:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 12:31 [PATCH] Add MFC device tree support Arun Kumar K
2012-08-16 12:31 ` [PATCH] ARM: EXYNOS: " Arun Kumar K
[not found] ` <1345120273-22913-2-git-send-email-arun.kk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2012-08-16 11:42 ` Thomas Abraham
2012-08-20 6:17 ` Karol Lewandowski [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-08-17 4:50 Arun Kumar K
2012-08-23 8:16 ` Kukjin Kim
2012-08-27 11:37 Arun Kumar K
2012-08-28 10:08 Arun Kumar K
2012-09-05 2:42 ` Karol Lewandowski
2012-09-05 9:15 Arun Kumar K
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=5031D673.6060104@samsung.com \
--to=k.lewandowsk@samsung.com \
--cc=arun.kk@samsung.com \
--cc=ch.naveen@samsung.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=joshi@samsung.com \
--cc=jtp.park@samsung.com \
--cc=k.debski@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=thomas.abraham@linaro.org \
/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.