From: Arun Kumar K <arun.kk@samsung.com>
To: Karol Lewandowski <k.lewandowsk@samsung.com>
Cc: Thomas Abraham <thomas.abraham@linaro.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Kamil Debski <k.debski@samsung.com>,
Jeongtae Park <jtp.park@samsung.com>,
NAVEEN KRISHNA CHATRADHI <ch.naveen@samsung.com>,
SUNIL JOSHI <joshi@samsung.com>
Subject: Re: [PATCH] ARM: EXYNOS: Add MFC device tree support
Date: Wed, 05 Sep 2012 09:15:21 +0000 (GMT) [thread overview]
Message-ID: <15525795.211061346836521012.JavaMail.weblogic@epml27> (raw)
Hi Karol,
Thank you very much for the detailed explanation.
Its indeed very well explained and seems like a great approach
to remove the hard codings.
I will go ahead with this implementation and post the updated patch.
Regards
Arun
On Wed, Sep 5, 2012 at 8:12 AM, Karol Lewandowski <k.lewandowsk@samsung.com> wrote:
> On 08/28/2012 07:08 PM, Arun Kumar K wrote:
>
>> Hi Karol,
>> Thanks for your comments.
>> Please find my response inline.
>
> Hi... and sorry for so much delayed response.
>
>>>> +
>>>> +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.
>>>
>>
>> As I can see the fdt_* functions are not used in any of the ARM based SoC
>> init codes. Though I can see some references in powerpc.
>> The implementation and includes are present in arch/arm/boot/compressed/
>> which I think cannot be used directly in mach-exynos unless we make some
>> comon makefile changes.
>
>
> It looks like I was writing from memory, and I actually mixed things
> up. To be clear this time - we can't use regular device tree handling
> functions in reserve() as it's too early. Namely, flattened device tree
> is not yet converted to kernel's-natural representation. However,
> I think we can scan fdt just fine. To do so one just needs to use
> functions declared here
>
> #include <linux/of_fdt.h>
>
> Actual architecture-independent code is in drivers/of/fdt.c. This
> provides of_fdt_ family of functions. Please see below for example.
>
>
>> Please clarify whether its ok to use fdt_* functions to parse the dts in
>> exynos machine init or please point me to some sample implementations
>> which I can refer to.
>
>
> It should be ok to use anything that works on flattened device tree
> rather than its uncompressed version. I've experimented a bit and
> something like this worked for me just fine (it was around 3.3-kernel
> timeframe, but I don't think that fdt api has changed):
>
> [mach-exynos4-dt.c]
>
> #include <linux/of_fdt.h>
>
> int fdt_find_compat(unsigned long node, const char *uname, int depth, void *data)
> {
> if (of_flat_dt_is_compatible(node, (char *)data))
> return 1;
>
> return 0;
> }
>
> static void __init exynos4210_dt_reserve(void)
> {
> /* Reserve memory for MFC only if it's available */
> if (of_scan_flat_dt(fdt_find_compat, "samsung,s5pv210-mfc")) {
> printk(KERN_NOTICE "exynos4-dt: mfc device node found - setting up memory area for dma\n");
> s5p_mfc_reserve_mem(0x43000000, 8 << 20, 0x51000000, 8 << 20);
> }
> }
>
> [.dts]
>
> codec@some-addr {
> compatible = "samsung,s5pv210-mfc";
> };
>
>
> So, in above code fragment I just check if mfc was defined in dts.
> This could probably stay as it is.
>
> Then I allocate _predefined_ region - and this part should be fixed.
>
> If you have nodes like "mfc-r-size"/offset, then you could just get
> this information directly from (f)dt rather than hardcoding it in the code.
> Precisely, after we find compatible node we could do something like
> following (untested):
>
> unsigned long lsize, loff, rsize, roff len;
> __be32 *prop;
>
> prop = of_get_flat_dt_prop(node, "samsung,mfc-l-size", &len);
> if (!prop)
> return;
> lsize = of_read_ulong(prop, len/4);
> ...
>
> Regards,
> --
> Karol Lewandowski | Samsung Poland R&D Center | Linux/Platform
> --
> 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
next reply other threads:[~2012-09-05 9:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-05 9:15 Arun Kumar K [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-08-28 10:08 [PATCH] ARM: EXYNOS: Add MFC device tree support Arun Kumar K
2012-09-05 2:42 ` Karol Lewandowski
2012-08-27 11:37 Arun Kumar K
2012-08-17 4:50 Arun Kumar K
2012-08-23 8:16 ` Kukjin Kim
2012-08-16 12:31 [PATCH] " 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
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=15525795.211061346836521012.JavaMail.weblogic@epml27 \
--to=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=k.lewandowsk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).