<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: Xilinx devicetrees</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>
<BR>
<P><FONT SIZE=2>-----Original Message-----<BR>
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Grant Likely<BR>
Sent: Sat 11/24/2007 9:12 AM<BR>
To: David H. Lynch Jr.<BR>
Cc: linuxppc-embedded<BR>
Subject: Re: Xilinx devicetrees<BR>
<BR>
On 11/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:<BR>
<BR>
>> I am having some difficulty grasping the significant advantages to<BR>
>> this.<BR>
>> If the firmware for a given target is not fairly static - and I load<BR>
>> different firmware depending on what I am doing all the time, then I<BR>
>> know have to manage both a bit file for the firmware, and a devicetree<BR>
>> file describing it to the kernel.<BR>
<BR>
The device tree file is meta-information about your bitfile. Think of it as 'part of the firmware'. In the (hopefully short) future, it won't even have to be managed, it will just be one of the things that is generated by the EDK flow.<BR>
<BR>
> That being said, using the device tree does not preclude using<BR>
> platform code to setup devices *where it makes sense to do so*. Many<BR>
> things are one-off board specific things that are not well described<BR>
> with the device tree. For example, we've been debating how to handle<BR>
> on board sound which use common codec chips, but have custom wireup.<BR>
> The codec chip can use a common driver, but the wireup is handled with<BR>
> an ALSA 'fabric' driver that is pretty much a one-off for the board.<BR>
> It probably makes more sense for the fabric driver to be instantiated<BR>
> by the platform code rather than trying to do a full device tree<BR>
> representation.<BR>
<BR>
Actually, even this is still driven by the device tree, because the platform code binds to the toplevel 'compatible' property... It's just 'different' from a standard device driver. <BR>
<BR>
>><BR>
>> What am missing about devicetrees that would make me more<BR>
>> interested in them ?<BR>
<BR>
You won't have to write a bunch of code that deciphers which fpga firmware you are running on.. That information will be found with the firmware and can be dealt with in a generic way. If you already HAVE that code, you can keep using it, but maintaining that kind of code is probably not where you want to spend your time.<BR>
<BR>
Steve</FONT>
</P>
</BODY>
</HTML>