From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound7-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 0BB5BDDDED for ; Mon, 17 Dec 2007 15:51:53 +1100 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84068.87B3AB1C" Subject: RE: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of. Date: Sun, 16 Dec 2007 20:48:59 -0800 References: <1197589413-5965-1-git-send-email-stephen.neuendorffer@xilinx.com><1197589413-5965-2-git-send-email-stephen.neuendorffer@xilinx.com><1197589413-5965-3-git-send-email-stephen.neuendorffer@xilinx.com><1197589413-5965-4-git-send-email-stephen.neuendorffer@xilinx.com><1197589413-5965-5-git-send-email-stephen.neuendorffer@xilinx.com><1197589413-5965-6-git-send-email-stephen.neuendorffer@xilinx.com><20071213234151.D0B3DE80061@mail20-sin.bigfish.com><20071217041455.GA3477@localhost.localdomain> From: "Stephen Neuendorffer" To: "Grant Likely" , , , Message-Id: <20071217045149.286161758054@mail101-blu.bigfish.com> List-Id: Linux on 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_01C84068.87B3AB1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Compound devices that actually have their own shared registers should do = something different. Likely they'll need some sort of data = synchronization anyway. It seems that by far the common case here is to = going to be to just have aggregation, and I don't see any reason that = can't be handled by a common 'pseudo-bus'. Steve -----Original Message----- From: glikely@secretlab.ca on behalf of Grant Likely Sent: Sun 12/16/2007 8:30 PM To: Stephen Neuendorffer; grant.likely@secretlab.ca; = simekm2@fel.cvut.cz; jwilliams@itee.uq.edu.au; linuxppc-dev@ozlabs.org Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of. =20 On 12/16/07, David Gibson wrote: > On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote: > > This now better describes what the UBoot device tree generator = actually does. In particular: > > > > 1) Nodes have a label derived from the device name, and a node name > > derived from the device type. > > 2) Usage of compound nodes (representing more than one device in the = same IP) which actually works. This requires having a valid compatible = node, and all the other things that a bus normally has. I've chosen = 'xlnx,compound' as the bus name to describe these compound nodes. > > I'm not sure I like this xlnx,compound business, although maybe it's > the best you can do. I'd prefer something like "xlnx,-group". "xlnx,compound" is a very bad idea because it will be reused for very different types of devices. What happens when a device appears that has both per-instance properties and 'top level' registers accessed by both devices? ------_=_NextPart_001_01C84068.87B3AB1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PATCH 7/7] [POWERPC] Xilinx: Update = booting-without-of.

Compound devices that actually have their own shared = registers should do something different.  Likely they'll need some = sort of data synchronization anyway.  It seems that by far the = common case here is to going to be to just have aggregation, and I don't = see any reason that can't be handled by a common 'pseudo-bus'.


Steve

-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Sun 12/16/2007 8:30 PM
To: Stephen Neuendorffer; grant.likely@secretlab.ca; = simekm2@fel.cvut.cz; jwilliams@itee.uq.edu.au; = linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update = booting-without-of.

On 12/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer = wrote:
> > This now better describes what the UBoot device tree generator = actually does.  In particular:
> >
> > 1) Nodes have a label derived from the device name, and a node = name
> > derived from the device type.
> > 2) Usage of compound nodes (representing more than one device = in the same IP) which actually works.  This requires having a valid = compatible node, and all the other things that a bus normally has.  = I've chosen 'xlnx,compound' as the bus name to describe these compound = nodes.
>
> I'm not sure I like this xlnx,compound business, although maybe = it's
> the best you can do.

I'd prefer something like "xlnx,<ip-name>-group".  = "xlnx,compound" is
a very bad idea because it will be reused for very different types = of
devices.  What happens when a device appears that has both
per-instance properties and 'top level' registers accessed by both
devices?

------_=_NextPart_001_01C84068.87B3AB1C--