Laurent Pinchart wrote:

On Friday 28 March 2008 18:11, Scott Wood wrote:

quoted

Laurent Pinchart wrote:

quoted

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.

quoted

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