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

[Laurent Pinchart]

On Friday 28 March 2008 19:07, Scott Wood wrote:
> 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. :-)

Ok thanks.

> > 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 was refering to the virtual-reg (non-)issue I mentionned below.

> > 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.

Ah right. Sorry about the misunderstanding.

> > 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.

Will the virtual-reg property on the muram node list the addresses of all 
muram chunks or the address of the first chunk only ?

> >> 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. :-)

I still need a default value :-) It obviously won't work for all boards.

> You could set the default to just before 0x2000 with board-specific 
> exceptions, though.

We're getting a bit lost. I'll try to summarize the discussion.

- The muram node has a reg property that lists the offsets and sizes of all 
muram chunks, and an optional virtual-reg property that lists the virtual 
address of all chunks/the first chunk only.

- From the above information I can locate a section of muram at the end of the 
first chunk (easy) or at the end of the muram (not really difficult, just a 
bit more complex, especially if chunks are not sorted by their start 
address).

- Kconfig needs a default address for the tx BD. This depends on the 
allocation strategy (end of first chunk vs. end of last chunk). Is there some 
consistent default across QE devices ?

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080331/e941a3bf/attachment.pgp>