[PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.

[Stephen Neuendorffer]

> -----Original Message-----
> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of
Grant Likely
> Sent: Monday, May 12, 2008 12:46 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev at ozlabs.org; git-dev
> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507
dvi core.
> 
> On Mon, May 12, 2008 at 1:10 PM, Stephen Neuendorffer
> <stephen.neuendorffer at xilinx.com> wrote:
> >
> >  The best possibility that I see is glopping the compatibility
> >  information about what cores are compatible with which drivers and
> >  generating something.  This is moderately better than blindly
treating
> >  all cores with the same major version as interface compatible, but
still
> >  has the potential to blindly declare that core versions are
compatible
> >  when they are not really compatible.
> 
> That's okay, the device tree conventions provide for that uncertainty.
>  If compatible includes both the *exact* version and the oldest known
> *compatible* version (the one the drivers know about) then we're in
> the situation where 99% of the time it just works.  For the 1% of the
> time when mistakes are made we still have the necessary information to
> write exceptions in the code to work around bad data.  This means code
> only needs to changes when mistakes are discovered, not for every IP
> core uprev.

My argument was that we should do this by truncating the major version,
which is also an established standard that cores *should* follow, but
you didn't like that. :)  It makes at least as much sense as expressing
the compatibility of the driver in the tree in terms of compatibility
with some other random driver.  In the case of the tft core in
particular, there *is* no other driver AFAIK.

> >  I *really* don't want to put this into the device tree generator on
a
> >  case-by-case basis, so unless there is something that can be
generated
> >  from whatever meta-information EDK has, I think we're going to have
to
> >  just have the explicit versions in the drivers for the time being.
> 
> Can we post process the generated device tree with a table of known
> compatibility strings (or regexps) for adding the older compatible
> values?  I don't expect the list will be particularly long or hard to
> maintain and the code to do so should be trivial.

Ug, that's just pushing the problem around.
This seems as much like an argument for putting wildcards in the
compatible bindings in the kernel as anything...

Steve