Xilinx EDK BSP generation of device trees for microblaze and PowerPC

Xilinx EDK BSP generation of device trees for microblaze and PowerPC

[Stephen Neuendorffer]

=09
I've updated some code from Michel Simek to generate Flat Device Trees
from Xilinx EDK projects.  This code is now hosted at:
git://git.xilinx.com/gen-mhs-devtree.git

This has one major advantage over the gen-mhs-devtree.py approach:
default IP core parameters that are not specified in the mhs file can
now be generated, since EDK pulls these in from the core .mpd file.
I've also managed to incorporate a few more improvements from the
previous review, so the BSP generator should include at least as much
information as gen-mhs-devtree.py

The next major order of business is to represent the DMA engines in the
MPMC and locallink connections to the lltemac.

Steve

RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC

[Stephen Neuendorffer]

[-- Attachment #1: Type: text/plain, Size: 5054 bytes --]


Here's what I've gotten so far:

		Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
			#address-cells = <1>;
			#size-cells = <1>;
			network@81c00000 {
				compatible = "xlnx,xps-ll-temac-1.00.a", "xlnx,xps-ll-temac";
				interrupt-parent = <&xps_intc_0>;
				interrupts = < 3 0 >;
				llink-connected = <&PIM3>;
				reg = < 81c00000 40 >;
				xlnx,bus2core-clk-ratio = <1>;
				xlnx,phy-type = <1>;
				xlnx,phyaddr = <1>;
				xlnx,rxcsum = <0>;
				xlnx,rxfifo = <1000>;
				xlnx,temac-type = <0>;
				xlnx,txcsum = <0>;
				xlnx,txfifo = <1000>;
			} ;
		} ;
		mpmc@90000000 {
			#address-cells = <1>;
			#size-cells = <1>;
			compatible = "xlnx,mpmc-3.00.a", "xlnx,mpmc";
			PIM3: sdma@84600180 {
				compatible = "xlnx,ll-dma-1.00a", "xlnx,ll-dma";
				interrupt-parent = <&xps_intc_0>;
				interrupts = < 1 0 0 0 >;
				reg = < 84600180 80 >;
			} ;
		} ;
	DDR2_SDRAM: memory@90000000 {
		device_type = "memory";
		reg = < 90000000 10000000 >;
	} ;

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 mpmc@90000000, because there is no management interface.  If a management interface was present, then it would be @ the management address.
The mpmc gets a compatible string that describes its management interface.
The sdma port has information about the tx and rx interrupts and the slave management interface.  Note that the slave management interface has the correct baseaddress for port3, generated from the base SDMA_CTRL_ address from the mpmc + the port 3 offset.  Note that sdma has an artificial compatible name.  I'm not sure whether the ll_dma driver can be easily convinced to bind to this, or whether the ll_temac driver will just traverse the device tree and then do a match against this.

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: mpmc@90000000 {
			sdma@3 {

and refer to the sdma port using something like <&DDR2_SDRAM/sdma@3>, but I don't think you can do that in dtc?

2) Not sure whether this is really simpler than just having a 'simple' node with both temacs and letting the driver sort everything out.  In particular, I'm concerned about maintaining a bunch of semantic information about the ll_temac driver outside of the driver itself.

3) All of this is very different in structure from the way that the xparameters are organized.  The ll_temac BSP code copies the xparameters out of the MPMC and they are simply other parameters of the ll_temac driver.  Although the above structure better represents the actual system, there is another organization for people to be confused about.

Steve

-----Original Message-----
From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org on behalf of Stephen Neuendorffer
Sent: Tue 11/20/2007 11:44 AM
To: microblaze-uclinux@itee.uq.edu.au; linuxppc-dev@ozlabs.org; Grant Likely; Michal Simek
Subject: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
 

	
I've updated some code from Michel Simek to generate Flat Device Trees
from Xilinx EDK projects.  This code is now hosted at:
git://git.xilinx.com/gen-mhs-devtree.git

This has one major advantage over the gen-mhs-devtree.py approach:
default IP core parameters that are not specified in the mhs file can
now be generated, since EDK pulls these in from the core .mpd file.
I've also managed to incorporate a few more improvements from the
previous review, so the BSP generator should include at least as much
information as gen-mhs-devtree.py

The next major order of business is to represent the DMA engines in the
MPMC and locallink connections to the lltemac.

Steve

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[-- Attachment #2: Type: text/html, Size: 11019 bytes --]

Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC

[Grant Likely]

On 11/24/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>

Thanks for all this work; comments below.

>
> Here's what I've gotten so far:
>
>                  Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
>                          #address-cells = <1>;
>                          #size-cells = <1>;
>                          network@81c00000 {
>                                  compatible = "xlnx,xps-ll-temac-1.00.a",
> "xlnx,xps-ll-temac";

Drop "xlnx,xps-ll-temac"; it's 100% made up.  This should be simply:
      compatible = "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
      compatible =
"xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
version if it maintains register level compatibility.

"xlnx,xps-ll-temac" is far to ambiguous.

>                                  interrupt-parent = <&xps_intc_0>;
>                                  interrupts = < 3 0 >;
>                                  llink-connected = <&PIM3>;

What's this property for?

>                                  reg = < 81c00000 40 >;

If these registers are addressable, then the parent needs a 'ranges' property.

>                                  xlnx,bus2core-clk-ratio = <1>;
>                                  xlnx,phy-type = <1>;
>                                  xlnx,phyaddr = <1>;
>                                  xlnx,rxcsum = <0>;
>                                  xlnx,rxfifo = <1000>;
>                                  xlnx,temac-type = <0>;
>                                  xlnx,txcsum = <0>;
>                                  xlnx,txfifo = <1000>;

Would be nice to have a 'phy-handle' property as that is what is being
used on other platforms; but that's not something that EDK knows
about.  It would be nice to have a way to tell EDK what PHY device is
on the board so it could generate the appropriate mdio and phy nodes.

>                          } ;
>                  } ;
>                  mpmc@90000000 {
>                          #address-cells = <1>;
>                          #size-cells = <1>;
>                          compatible = "xlnx,mpmc-3.00.a", "xlnx,mpmc";

Drop 'xlns,mpmc'

>                          PIM3: sdma@84600180 {
>                                  compatible = "xlnx,ll-dma-1.00a",
> "xlnx,ll-dma";
>                                  interrupt-parent = <&xps_intc_0>;
>                                  interrupts = < 1 0 0 0 >;
>                                  reg = < 84600180 80 >;

Are these directly addressable registers from the CPU?  If so, the
parent node needs a 'ranges' property.

>                          } ;
>                  } ;
>          DDR2_SDRAM: memory@90000000 {
>                  device_type = "memory";
>                  reg = < 90000000 10000000 >;
>          } ;
>
>  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 mpmc@90000000,
> 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
mpmc@90000000 doesn't feel right.

Segher, David; what's your opinion?

>  The mpmc gets a compatible string that describes its management interface.
>  The sdma port has information about the tx and rx interrupts and the slave
> management interface.  Note that the slave management interface has the
> correct baseaddress for port3, generated from the base SDMA_CTRL_ address
> from the mpmc + the port 3 offset.  Note that sdma has an artificial
> compatible name.  I'm not sure whether the ll_dma driver can be easily
> convinced to bind to this, or whether the ll_temac driver will just traverse
> the device tree and then do a match against this.

Don't worry about having a too-sparse compatible property.  Be
specific and we can always add entries to the bind list.  For the IP
cores, always specify specific device versions in the compatible
entries.

>
>  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: mpmc@90000000 {
>                          sdma@3 {
>
>  and refer to the sdma port using something like <&DDR2_SDRAM/sdma@3>, but I
> don't think you can do that in dtc?

If not, it is possible to extend the dtc syntax.  Jon, David?  Thoughts?

>
>  2) Not sure whether this is really simpler than just having a 'simple' node
> with both temacs and letting the driver sort everything out.  In particular,
> I'm concerned about maintaining a bunch of semantic information about the
> ll_temac driver outside of the driver itself.

I wouldn't recommend it.  It is better for probing to have one node
per logical device.

However, you could either have the network nodes as children of the
xps-ll-temac node, or they could be children of their addressable bus
and have phandles to the xps-ll-temac node...
In fact, if the network nodes are children of the xps-ll-temac node,
then the xps-ll-temac node should itself be a child of the addressable
bus (be it PLB or OPB).

Cheers,
g.



>
>  3) All of this is very different in structure from the way that the
> xparameters are organized.  The ll_temac BSP code copies the xparameters out
> of the MPMC and they are simply other parameters of the ll_temac driver.
> Although the above structure better represents the actual system, there is
> another organization for people to be confused about.
>
>  Steve
>
>
>  -----Original Message-----
>  From:
> linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org
> on behalf of Stephen Neuendorffer
>  Sent: Tue 11/20/2007 11:44 AM
>  To: microblaze-uclinux@itee.uq.edu.au;
> linuxppc-dev@ozlabs.org; Grant Likely; Michal Simek
>  Subject: Xilinx EDK BSP generation of device trees for microblaze and
> PowerPC
>
>
>
>  I've updated some code from Michel Simek to generate Flat Device Trees
>  from Xilinx EDK projects.  This code is now hosted at:
>  git://git.xilinx.com/gen-mhs-devtree.git
>
>  This has one major advantage over the gen-mhs-devtree.py approach:
>  default IP core parameters that are not specified in the mhs file can
>  now be generated, since EDK pulls these in from the core .mpd file.
>  I've also managed to incorporate a few more improvements from the
>  previous review, so the BSP generator should include at least as much
>  information as gen-mhs-devtree.py
>
>  The next major order of business is to represent the DMA engines in the
>  MPMC and locallink connections to the lltemac.
>
>  Steve
>
>  _______________________________________________
>  Linuxppc-dev mailing list
>  Linuxppc-dev@ozlabs.org
>  https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
>
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC

[Stephen Neuendorffer]

=20
I've pushed the current state up to
git://git.xilinx.com/gen-mhs-devtree.git for your perusing.  Comments
below.

> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Sunday, November 25, 2007 2:47 PM
> To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;=20
> Jon Loeliger
> Cc: microblaze-uclinux@itee.uq.edu.au;=20
> linuxppc-dev@ozlabs.org; Michal Simek; git
> Subject: Re: Xilinx EDK BSP generation of device trees for=20
> microblaze and PowerPC
>=20
> On 11/24/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
>=20
> Thanks for all this work; comments below.
>=20
> >
> > Here's what I've gotten so far:
> >
> >                  Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> >                          #address-cells =3D <1>;
> >                          #size-cells =3D <1>;
> >                          network@81c00000 {
> >                                  compatible =3D=20
> "xlnx,xps-ll-temac-1.00.a",
> > "xlnx,xps-ll-temac";
>=20
> Drop "xlnx,xps-ll-temac"; it's 100% made up.  This should be simply:
>       compatible =3D "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
>       compatible =3D
> "xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
> version if it maintains register level compatibility.
>=20
> "xlnx,xps-ll-temac" is far to ambiguous.

What if it was: compatible =3D "xlnx,xps-ll-temac-1.00.a",
"xlnx,xps-ll-temac-1"?

Basically, I don't want to be responsible for declaring what versions of
IP are backward compatible with ll-temac-1.00.a, and I think it's bad
software design to put that list into the dts generator anyway.  In
theory, at least, all ip with the same major version should be
compatible.

> >                                  interrupt-parent =3D <&xps_intc_0>;
> >                                  interrupts =3D < 3 0 >;
> >                                  llink-connected =3D <&PIM3>;
>=20
> What's this property for?

So that the ll_temac knows whether to use dma or fifo code and where the
dma or fifo control/interrupts are.

>=20
> >                                  reg =3D < 81c00000 40 >;
>=20
> If these registers are addressable, then the parent needs a=20
> 'ranges' property.

I thought ranges weren't necessary in a 1:1 mapping?

> >                                  xlnx,bus2core-clk-ratio =3D <1>;
> >                                  xlnx,phy-type =3D <1>;
> >                                  xlnx,phyaddr =3D <1>;
> >                                  xlnx,rxcsum =3D <0>;
> >                                  xlnx,rxfifo =3D <1000>;
> >                                  xlnx,temac-type =3D <0>;
> >                                  xlnx,txcsum =3D <0>;
> >                                  xlnx,txfifo =3D <1000>;
>=20
> Would be nice to have a 'phy-handle' property as that is what is being
> used on other platforms; but that's not something that EDK knows
> about.  It would be nice to have a way to tell EDK what PHY device is
> on the board so it could generate the appropriate mdio and phy nodes.

Yeah, this is going to be a big issue, I think...

Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC

[David Gibson]

On Mon, Nov 26, 2007 at 01:44:02PM -0800, Stephen Neuendorffer wrote:
[snip]
> > >                                  reg = < 81c00000 40 >;
> > 
> > If these registers are addressable, then the parent needs a 
> > 'ranges' property.
> 
> I thought ranges weren't necessary in a 1:1 mapping?

You were misinformed.  If there is no ranges property, the child nodes
are not directly addressable from the bus above.  If the ranges
property is present, but empty, then there is an identity mapping
between parent and child bus addresses.  So you probably want to add
	ranges;
to the parent node.

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

Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC

[David Gibson]

On Sun, Nov 25, 2007 at 03:47:12PM -0700, Grant Likely wrote:
> On 11/24/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> 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 mpmc@90000000,
> > 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
> mpmc@90000000 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 (/memory@XXX, 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: mpmc@90000000 {
> >                          sdma@3 {
> >
> >  and refer to the sdma port using something like <&DDR2_SDRAM/sdma@3>, 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

Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC

[Grant Likely]

Bah; I wrote this email about a week ago, but never sent it.  Sorry.

g.

On 11/26/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> I've pushed the current state up to
> git://git.xilinx.com/gen-mhs-devtree.git for your perusing.  Comments
> below.
>
> > -----Original Message-----
> > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > Behalf Of Grant Likely
> > Sent: Sunday, November 25, 2007 2:47 PM
> > To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;
> > Jon Loeliger
> > Cc: microblaze-uclinux@itee.uq.edu.au;
> > linuxppc-dev@ozlabs.org; Michal Simek; git
> > Subject: Re: Xilinx EDK BSP generation of device trees for
> > microblaze and PowerPC
> >
> > On 11/24/07, Stephen Neuendorffer
> > <stephen.neuendorffer@xilinx.com> wrote:
> > >
> >
> > Thanks for all this work; comments below.
> >
> > >
> > > Here's what I've gotten so far:
> > >
> > >                  Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> > >                          #address-cells = <1>;
> > >                          #size-cells = <1>;
> > >                          network@81c00000 {
> > >                                  compatible =
> > "xlnx,xps-ll-temac-1.00.a",
> > > "xlnx,xps-ll-temac";
> >
> > Drop "xlnx,xps-ll-temac"; it's 100% made up.  This should be simply:
> >       compatible = "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
> >       compatible =
> > "xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
> > version if it maintains register level compatibility.
> >
> > "xlnx,xps-ll-temac" is far to ambiguous.
>
> What if it was: compatible = "xlnx,xps-ll-temac-1.00.a",
> "xlnx,xps-ll-temac-1"?

Here's what I've learned: There is no such thing as a perfect device
tree.  Either hardware bugs will be discovered at a later date which
make compatible inaccurate, or a better understanding of the device
will come along which will change the understood best practices for
describing the device.

My opinion is the best strategy against claiming something that's not
true, or won't be true in the fucture, is to strive for uniqueness and
describe only what you are certain of.  Be conservative instead of
liberal in the compatible case; ie. it's easier to teach the driver
about other versions it can bind against than it is to teach it about
exceptions to certain versions of the hardware (when binding).

In this particular case the problem still stands that the VHDL
engineer may make a non backward compatible change in version
xlnx,xps-ll-temac-1.00.c or -1.03.c.  You just don't know until it
happens.  Stick with what is known and don't try to extrapolate to a
'generic' version when there is no guarantee that it will remain
generic.

When sticking with real version numbers, it is quite safe to claim
compatibility with an older version number because you've probably
tested it; something which isn't so safe when you attempt to make up
generic versions.

>
> Basically, I don't want to be responsible for declaring what versions of
> IP are backward compatible with ll-temac-1.00.a, and I think it's bad
> software design to put that list into the dts generator anyway.  In
> theory, at least, all ip with the same major version should be
> compatible.

Yes, but at the point of releasing, you've probably tested it so the
risk is very low.

>
> > >                                  interrupt-parent = <&xps_intc_0>;
> > >                                  interrupts = < 3 0 >;
> > >                                  llink-connected = <&PIM3>;
> >
> > What's this property for?
>
> So that the ll_temac knows whether to use dma or fifo code and where the
> dma or fifo control/interrupts are.
>
> >
> > >                                  reg = < 81c00000 40 >;
> >
> > If these registers are addressable, then the parent needs a
> > 'ranges' property.
>
> I thought ranges weren't necessary in a 1:1 mapping?

At the very least there needs to be an empty 'ranges' property in
order for it to work

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC

[Stephen Neuendorffer]

=20
> > > -----Original Message-----
> > > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > > Behalf Of Grant Likely
> > > Sent: Sunday, November 25, 2007 2:47 PM
> > > To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;
> > > Jon Loeliger
> > > Cc: microblaze-uclinux@itee.uq.edu.au;
> > > linuxppc-dev@ozlabs.org; Michal Simek; git
> > > Subject: Re: Xilinx EDK BSP generation of device trees for
> > > microblaze and PowerPC
> > >
> > > On 11/24/07, Stephen Neuendorffer
> > > <stephen.neuendorffer@xilinx.com> wrote:
> > > >
> > >
> > > Thanks for all this work; comments below.
> > >
> > > >
> > > > Here's what I've gotten so far:
> > > >
> > > >                  Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> > > >                          #address-cells =3D <1>;
> > > >                          #size-cells =3D <1>;
> > > >                          network@81c00000 {
> > > >                                  compatible =3D
> > > "xlnx,xps-ll-temac-1.00.a",
> > > > "xlnx,xps-ll-temac";
> > >
> > > Drop "xlnx,xps-ll-temac"; it's 100% made up.  This should=20
> be simply:
> > >       compatible =3D "xlnx,xps-ll-temac-1.00.a" for version=20
> 1.00.a and
> > >       compatible =3D
> > > "xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a"=20
> for a future
> > > version if it maintains register level compatibility.
> > >
> > > "xlnx,xps-ll-temac" is far to ambiguous.
> >
> > What if it was: compatible =3D "xlnx,xps-ll-temac-1.00.a",
> > "xlnx,xps-ll-temac-1"?
>=20
> Here's what I've learned: There is no such thing as a perfect device
> tree.  Either hardware bugs will be discovered at a later date which
> make compatible inaccurate, or a better understanding of the device
> will come along which will change the understood best practices for
> describing the device.
>=20
> My opinion is the best strategy against claiming something that's not
> true, or won't be true in the fucture, is to strive for uniqueness and
> describe only what you are certain of.  Be conservative instead of
> liberal in the compatible case; ie. it's easier to teach the driver
> about other versions it can bind against than it is to teach it about
> exceptions to certain versions of the hardware (when binding).
>=20
> In this particular case the problem still stands that the VHDL
> engineer may make a non backward compatible change in version
> xlnx,xps-ll-temac-1.00.c or -1.03.c.  You just don't know until it
> happens.  Stick with what is known and don't try to extrapolate to a
> 'generic' version when there is no guarantee that it will remain
> generic.
>=20
> When sticking with real version numbers, it is quite safe to claim
> compatibility with an older version number because you've probably
> tested it; something which isn't so safe when you attempt to make up
> generic versions.

I think you've convinced me... :)  I think the only reason to ever put
more than one thing in the compatible list, is if you want to declare
that you are compatible with an established, standard driver and you
don't have control over the driver.  ns16550 is a great example of this,
where it is so ubiquitous that the driver is likely to be much more
stable over time than any particular hardware.

I did some quick scripting around in various versions of EDK.  For the
record, Xilinx shipped about 369 distinct versions of processor IP with
the EDK, since EDK 6.3:
    369     /home/stephenn/iplist_combined

And there's obviously alot of overlap between the different versions:
    202     EDK 6.3
    227     EDK 7.1
    268     EDK 8.2
    297     EDK 9.2

But the total number of drivers is much smaller:
     87      EDK 6.3
     91      EDK 7.1
     86      EDK 8.2
    112      EDK 9.2

And it appears that there are a relatively small number of changes which
the drivers claim are not forwards compatible (not to say that there
aren't other incompatibilities, but this is the compatibility that we
can infer based on what the drivers claim).

opb_ethernet_v1_01_a -> opb_ethernet_v1_02_a -> opb_ethernet_v1_04_[a-z]
opb_ethernetlite_v1_00_a -> opb_ethernetlite_v1_01_a
opb_pci_v1_00_c -> opb_pci_v1_01_a
plb_temac_v2_00_a -> plb_temac_v3_00_a
opb_deltasigma_dac_v1_00_a -> opb_deltasigma_dac_v1_01_a
opb_deltasigma_adc_v1_01_a -> opb_deltasigma_dac_v1_01_a
opb_hwicap_v1_00_b -> opb_hwicap_v1_10_a

In any event, my plan is to put only the exact version name in the
device tree and list all the compatible versions in the driver match.

Steve