From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx•com>
To: "Grant Likely" <grant.likely@secretlab•ca>,
"David H. Lynch Jr." <dhlii@dlasys•net>
Cc: linuxppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: RE: Xilinx devicetrees
Date: Sat, 24 Nov 2007 21:24:58 -0800 [thread overview]
Message-ID: <20071125052459.DA8B1EE805F@mail70-blu.bigfish.com> (raw)
In-Reply-To: fa686aa40711240912r192aba72o2cbdb798370e7b7c@mail.gmail.com
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.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
[-- Attachment #2: Type: text/html, Size: 2897 bytes --]
next prev parent reply other threads:[~2007-11-25 5:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-24 11:37 Xilinx devicetrees David H. Lynch Jr.
2007-11-24 17:12 ` Grant Likely
2007-11-25 5:24 ` Stephen Neuendorffer [this message]
2007-11-25 9:37 ` David H. Lynch Jr.
2007-11-25 18:15 ` Stephen Neuendorffer
2007-11-27 23:55 ` John Williams
2007-11-28 0:27 ` Grant Likely
2007-11-28 0:28 ` Stephen Neuendorffer
2007-11-28 0:52 ` John Williams
2007-11-28 14:33 ` Jon Loeliger
2007-11-28 17:28 ` Stephen Neuendorffer
2007-11-28 18:12 ` Grant Likely
2007-11-29 10:56 ` David H. Lynch Jr.
2007-11-25 9:15 ` David H. Lynch Jr.
2007-11-25 22:21 ` Grant Likely
2007-11-25 22:55 ` David H. Lynch Jr.
2007-11-25 23:58 ` Stephen Neuendorffer
2007-11-26 21:36 ` David H. Lynch Jr.
2007-12-13 2:40 ` Koss, Mike (Mission Systems)
2007-11-26 16:30 ` Grant Likely
2007-11-26 20:28 ` David H. Lynch Jr.
2007-11-26 21:16 ` David H. Lynch Jr.
2007-11-26 21:55 ` Stephen Neuendorffer
2007-11-26 22:09 ` Grant Likely
2007-11-26 22:19 ` Koss, Mike (Mission Systems)
2007-12-13 4:52 ` Stephen Neuendorffer
2007-12-13 13:49 ` Koss, Mike (Mission Systems)
2007-12-13 17:36 ` Stephen Neuendorffer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071125052459.DA8B1EE805F@mail70-blu.bigfish.com \
--to=stephen.neuendorffer@xilinx$(echo .)com \
--cc=dhlii@dlasys$(echo .)net \
--cc=grant.likely@secretlab$(echo .)ca \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox