From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound1-blu-R.bigfish.com (outbound-blu.frontbridge.com [65.55.251.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.bigfish.com", Issuer "*.bigfish.com" (not verified)) by ozlabs.org (Postfix) with ESMTP id 0D415DDECA for ; Sun, 25 Nov 2007 16:25:04 +1100 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82F23.851F4916" Subject: RE: Xilinx devicetrees Date: Sat, 24 Nov 2007 21:24:58 -0800 References: <47480CF0.7090105@dlasys.net> From: "Stephen Neuendorffer" To: "Grant Likely" , "David H. Lynch Jr." Message-Id: <20071125052459.DA8B1EE805F@mail70-blu.bigfish.com> Cc: linuxppc-embedded List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C82F23.851F4916 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org = on behalf of Grant Likely Sent: Sat 11/24/2007 9:12 AM To: David H. Lynch Jr. Cc: linuxppc-embedded Subject: Re: Xilinx devicetrees =20 On 11/24/07, David H. Lynch Jr. wrote: >> I am having some difficulty grasping the significant advantages = to >> this. >> If the firmware for a given target is not fairly static - and I = load >> different firmware depending on what I am doing all the time, then I >> know have to manage both a bit file for the firmware, and a = devicetree >> file describing it to the kernel. 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. > That being said, using the device tree does not preclude using > platform code to setup devices *where it makes sense to do so*. Many > things are one-off board specific things that are not well described > with the device tree. For example, we've been debating how to handle > on board sound which use common codec chips, but have custom wireup. > The codec chip can use a common driver, but the wireup is handled with > an ALSA 'fabric' driver that is pretty much a one-off for the board. > It probably makes more sense for the fabric driver to be instantiated > by the platform code rather than trying to do a full device tree > representation. 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. =20 >> >> What am missing about devicetrees that would make me more >> interested in them ? 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. Steve ------_=_NextPart_001_01C82F23.851F4916 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Xilinx devicetrees


-----Original Message-----
From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org = on behalf of Grant Likely
Sent: Sat 11/24/2007 9:12 AM
To: David H. Lynch Jr.
Cc: linuxppc-embedded
Subject: Re: Xilinx devicetrees

On 11/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:

>>     I am having some difficulty grasping = the significant advantages to
>> this.
>>     If the firmware for a given target is = not fairly static - and I load
>> different firmware depending on what I am doing all the time, = then I
>> know have to manage both a bit file for the firmware, and a = devicetree
>> file describing it to the kernel.

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.

> That being said, using the device tree does not preclude using
> platform code to setup devices *where it makes sense to do = so*.  Many
> things are one-off board specific things that are not well = described
> with the device tree.  For example, we've been debating how to = handle
> on board sound which use common codec chips, but have custom = wireup.
> The codec chip can use a common driver, but the wireup is handled = with
> an ALSA 'fabric' driver that is pretty much a one-off for the = board.
> It probably makes more sense for the fabric driver to be = instantiated
> by the platform code rather than trying to do a full device = tree
> representation.

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. 

>>
>>     What am  missing about devicetrees = that would make me more
>> interested in them ?

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.

Steve

------_=_NextPart_001_01C82F23.851F4916--