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

["Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>]

=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