All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David H. Lynch Jr." <dhlii@dlasystems.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "Koss, Mike \(Mission Systems\)" <mike.koss@ngc.com>,
	Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>,
	linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: Xilinx devicetrees
Date: Mon, 26 Nov 2007 15:28:06 -0500	[thread overview]
Message-ID: <474B2C56.5040008@dlasystems.com> (raw)
In-Reply-To: <fa686aa40711260830y46aeb64cy8b662cad7196af8d@mail.gmail.com>

Grant Likely wrote:
> On 11/26/07, Koss, Mike (Mission Systems) <mike.koss@ngc.com> wrote:
>   
>> DL>    And once again a plea to ALWAYS make version/capabilities registers
>> DL> atleast an optional part of every design.
>> DL>    Embeddeding a device tree into a design might be fairly expensive. a
>> DL> pair of read only 32 bit registers is damn near free - basically the
>> DL> FPGA equivalent of atmost 64 diodes or resistors.
>>
>> SN> Actually, device trees actually seem to be cheaper (in the whole system
>> sense) than such registers.  Unless there is something I don't understand?
>>     
    First the decoding for the register is almost certainly already
present for the other registers for the device.
    After that - assuming that an FPGA can impliment a read only
register as easily as discrete logic -  it should be damn near the
    most trivial peice of hardware imaginable. It is simpler than 64
bits of RAM. It can be simpler than 64bits of ROM.
    I do not think there is a way in the world that devicetrees can more
cheaply provide the same information.
    They might me more flexible, or powerful, but 2 64bit read only
registers.

    Anyway I am not arguing that you should not do devicetrees. Just
that you should do version/capabilities registers - atleast as a IP
option always.
    Every OS does nto support devicetree's. Every application of an FPGA
not going to have that as an option. But every peice of software that
can access and I/O device can access its version and capabilities registers.


> *If* edk is generating our device tree(s) for us, *then* version
> registers are not needed by Linux.
>   
    I want both. I want version registers - because they are ALWAYS
available.
    They are available to software running on the FPGA that has no clue
what bit file it is running on,how it got to be running.
    Devicetrees may provide a great deal more information bit it is not
hard to come up with scenarios where that information might not
    be present. It is like the security arguments about biometric
identification. I can forget my key card, my password, ... But I am
unlikely to forget my thumbprint or retina.
   

-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

  reply	other threads:[~2007-11-26 20:34 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
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. [this message]
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=474B2C56.5040008@dlasystems.com \
    --to=dhlii@dlasystems.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=mike.koss@ngc.com \
    --cc=stephen.neuendorffer@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.