From: Scott Wood <scottwood@freescale.com>
To: Laurent Pinchart <laurentp@cse-semaphore.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
Date: Fri, 28 Mar 2008 13:07:56 -0500 [thread overview]
Message-ID: <47ED33FC.3020107@freescale.com> (raw)
In-Reply-To: <200803281854.28595.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> On Friday 28 March 2008 18:11, Scott Wood wrote:
>> Laurent Pinchart wrote:
>>> Locating the end of the muram isn't as straightforward as it
>>> could be. As the current code already uses the beginning of the
>>> muram to store the BDs and data buffers, should I really bother
>>> locating the end or can I store the SMC parameter ram at the
>>> beginning as well ?
>> Maybe, but the end would be safer. What's the problem with finding
>> the end?
>
> That requires manual parsing of all the cells in the reg property.
> The device-tree API doesn't provide a way to get the length of a
> property,
Sure it does. Do a getprop with an insufficiently large buffer, and it
tells you how much you really need. :-)
> so I'll have to use a big enough pre-allocated buffer. I'm also not
> sure if resources are guaranteed to be sorted in increasing order.
Ah, good point.
> This doesn't make finding the end of the muram really difficult. I
> was just wondering if the increased code complexity was worth it,
> especially seeing how the cpm_serial code in the boot wrapper seem
> quite unstable.
Unstable in what way?
> I'm not familiar with the boot wrapper code so I'm sometimes not very
> confident in my assumptions, but isn't the handling of the
> virtual-reg property in cpm_console_init broken ?
Not as far as I can see.
> If I'm not mistaken, getprop will return the address and size of the
> first resource and not the addresses of the first two resources.
No, it'll get as much of the virtual-reg property as will fit in the
buffer. There's no size in virtual-reg.
> What is virtual-reg used for ? To report the virtual address without
> requiring a device tree walk ? Does it provide any information that
> dt_xlate_reg can't find ?
Yes, it tells you the virtual address when it's not an identity mapping.
It's not currently used on CPM platforms, but might be used down the
road with a QE device on 85xx.
>> Even the end of the first reg resource would be OK.
>
> If I use the end of the first resource, can I assume it spans 0x0000
> - 0x8000 to set the default tx BD address in Kconfig ?
No, especially seeing as it doesn't on any existing boards. :-)
You could set the default to just before 0x2000 with board-specific
exceptions, though.
-Scott
next prev parent reply other threads:[~2008-03-28 18:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-26 11:17 [PATCHv2 0/3] cpm2: Reset the CPM at startup and fix the cpm_uart driver accordingly Laurent Pinchart
2008-03-26 11:19 ` [PATCHv2 1/3] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms Laurent Pinchart
2008-03-26 11:20 ` [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree Laurent Pinchart
2008-03-26 15:57 ` Scott Wood
2008-03-27 9:07 ` Laurent Pinchart
2008-03-26 16:59 ` Scott Wood
2008-03-27 9:10 ` Laurent Pinchart
2008-03-27 15:39 ` Scott Wood
2008-03-28 13:58 ` Laurent Pinchart
2008-03-28 14:06 ` Laurent Pinchart
2008-03-28 15:22 ` Scott Wood
2008-03-28 16:26 ` Laurent Pinchart
2008-03-28 17:11 ` Scott Wood
2008-03-28 17:54 ` Laurent Pinchart
2008-03-28 18:07 ` Scott Wood [this message]
2008-03-31 9:08 ` Laurent Pinchart
2008-03-31 15:33 ` Scott Wood
2008-03-31 17:38 ` [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in thedevice tree Rune Torgersen
2008-03-31 17:42 ` Scott Wood
2008-03-31 17:45 ` Rune Torgersen
2008-03-26 11:21 ` [PATCHv2 0/3] cpm2: Reset the CPM when early debugging is not enabled Laurent Pinchart
2008-03-26 11:22 ` Laurent Pinchart
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=47ED33FC.3020107@freescale.com \
--to=scottwood@freescale.com \
--cc=laurentp@cse-semaphore.com \
--cc=linuxppc-dev@ozlabs.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).