[PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.

[Scott Wood]

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