On Sun, Nov 25, 2007 at 03:47:12PM -0700, Grant Likely wrote:
> On 11/24/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
[snip]
> > So: the mpmc generates a 'memory' node, corresponding to it's memory
> > interface. It also gets a separate entry which contains the (optional, not
> > present in this example) slave management interface (for ECC and performance
> > information), and any sdma ports. In this case, this node is [EMAIL
> > PROTECTED],
> > because there is no management interface. If a management interface was
> > present, then it would be @ the management address.
>
> I don't think this is right; but I'm not sure. I don't know what the
> best naming convention is for the case of no management interface, but
> [EMAIL PROTECTED] doesn't feel right.
>
> Segher, David; what's your opinion?
If a node is present, but has no reg property, then it should not have
a unit address either. AFAICT what you're doing here is having one
node to represent the actual memory space (/[EMAIL PROTECTED], as it should
be) and another to represent the memory controller's control
interface. That's reasonable, but the unit address of the control
interface should be the address of the control registers, not the
address of the memory. If there is no control interface, there should
be no node for it at all.
[snip]
> > The temac works similarly, although the temac itself doesn't have a slave
> > interface, so no compatible node for it. The sub nodes get the compatible
> > string for the ll_temac driver. In this case, there is only one temac port
> > active. Some of the parameters are specific to port 0, in which case the
> > parameter names (e.g. phyaddr) are generated by stripping off the complete
> > C_TEMAC0 prefix. Other parameters (e.g. phy-type) are common to both sub
> > nodes, but are duplicated to make it easier for the driver to get the
> > information out. At runtime, the driver has to follow the llink-connected
> > path to find what it is connected to, and use the dma code, or the fifo
> > code.
> >
> > the xps-ll-fifo structure is a bit simpler, with llink-connected pointing
> > to the fifo, which looks like a 'normal' peripheral.
> >
> > Points for comment:
> > 1) I don't like the "PIM3" label, which is artificial (i.e. it doesn't
> > correspond to a name in the .mhs) and not guaranteed to be unique. However,
> > in the BSP generator it seems awkward to generate path references easily in
> > a single pass. What I'd might prefer is:
> > DDR2_SDRAM: [EMAIL PROTECTED] {
> > [EMAIL PROTECTED] {
> >
> > and refer to the sdma port using something like <&DDR2_SDRAM/[EMAIL
> > PROTECTED]>, but I
> > don't think you can do that in dtc?
>
> If not, it is possible to extend the dtc syntax. Jon, David? Thoughts?
&label/relative/path is not currently allowable in dtc. I suppose
it's possible to add it, but there are complications. I'm already
making some patches to deal with lexical ambiguities in the
&/full/path syntax, and the new syntax would make things more
complicated to deal with. I'll think about it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
