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

[Stephen Neuendorffer]

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.

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.

Steve 

> -----Original Message-----
> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of
Grant Likely
> Sent: Monday, May 12, 2008 11:30 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev at ozlabs.org
> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507
dvi core.
> 
> On Mon, May 12, 2008 at 11:31 AM, Stephen Neuendorffer
> <stephen.neuendorffer at xilinx.com> wrote:
> >
> >  Not easily.  As we discussed before, there is nowhere that really
> >  specifies this information.  In some cases I've modified the device
tree
> >  generator to understand what is backward compatible, as with
ns16550,
> >  but for other cores it makes more sense to me to put this
compatibility
> >  information with the driver if it has to be anywhere.
> 
> The main concern is that the driver will balloon with data which
> impacts the load size for all builds that compile it in.  It also
> reduces the impact of minor modifications of the IP cores (ie. the
> kernel still works when I've up-revved an ip core from 1.00a to
> 1.00b.)
> 
> I understand that it is hard within the EDK TCL scripts context, but
> this is exactly what compatible is designed for and I don't think
> continually adding more versions to the list is sustainable in the
> long term.  The more I think about it, the more I'm uneasy about this
> approach.
> 
> For the time being, I'm going to resist merging this change into my
> tree, but I'll keep it in my "don't forget about this" list.  It's not
> going into .26 anyway, so there is no time pressure.  Later, when
> we're closer to the .27 merge window, I'll look at it again, but I
> really would prefer to find a way to add to the compatible list.
> 
> Cheers,
> g.
> 
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.