From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound4-wa4-R.bigfish.com (outbound-wa4.frontbridge.com [216.32.181.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 ESMTPS id 629E5DDF17 for ; Thu, 8 May 2008 14:46:56 +1000 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B0C6.881F3D46" Subject: RE: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Usedcrinfrastructure. Date: Wed, 7 May 2008 21:46:51 -0700 References: <20080421080353.5d2b3bb9@zod.rchland.ibm.com> <1210010201-28436-1-git-send-email-stephen.neuendorffer@xilinx.com> <1210010201-28436-2-git-send-email-stephen.neuendorffer@xilinx.com> <1210010201-28436-3-git-send-email-stephen.neuendorffer@xilinx.com> <1210010201-28436-4-git-send-email-stephen.neuendorffer@xilinx.com> <20080505175647.4F3AC1C9004A@mail57-sin.bigfish.com> <20080506061444.GB17798@yookeroo.seuss> <20080506174352.52C857D805C@mail62-va3.bigfish.com> <20080508015948.GG5156@yookeroo.seuss> From: "Stephen Neuendorffer" To: "David Gibson" Message-Id: <20080508044652.98467AA8064@mail133-wa4.bigfish.com> Cc: linuxppc-dev@ozlabs.org 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_01C8B0C6.881F3D46 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that the tft driver currently in mainline assumes that = the dcr control registers are accessed through mmio, and probes for a reg=3D<> property. Since = the device is actually a dcr device, it can be connected via mmio through a bride, or to the native dcr bus = of the processor. For the time being, I'd like to generate device trees compatible with either mechanism. so, the problem is that the tree-parents of the tft node all have = ranges, and if the dcr-parent of the node is a bridge, then it has a = reg=3D<> property, But if the dcr-parent is also a tree-parent, then it has to have ranges; = and a reg=3D<> property, which seems very strange, and not something I = think is a good thing to do. Steve -----Original Message----- From: David Gibson [mailto:david@gibson.dropbear.id.au] Sent: Wed 5/7/2008 6:59 PM To: Stephen Neuendorffer Cc: Grant Likely; linuxppc-dev@ozlabs.org Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: = Usedcrinfrastructure. =20 On Tue, May 06, 2008 at 10:43:50AM -0700, Stephen Neuendorffer wrote: [snip] > > > Hmmm, something doesn't quite feel right about this. The node > > > describing the tft device is a child of the dcr@0 node which is = the > > > dcr bus. However, dcr bindings use dcr-bus and dcr-reg instead of > > > parent-child relationship to specify how to access the dcr > registers. > > > So, in this example; if the device is described by tft@80, and the > dcr > > > bus is described by opb2dcr-bridge@40700000, then what does dcr@0 > > > describe? (I do understand what they really describe in EDK = terms; > > > but I'm looking at it through device tree glasses). > > > > > > I don't think the presence of a dcr@0 node is a problem, but in = this > > > case #size/address-cells doesn't have any meaning (the child = doesn't > > > have a reg property) and it looks like it should be a child of the > > > opb2dcr-bridge node (otherwise, what is it attached to?). > >=20 > > Yes, indeed. If dcr@0 is representing the DCR bus / interface it > > should really have the dcr-access-method property and have all the > > dcr-parent handles point at it. >=20 > Hmm, I tend to agree. Certainly the address-cells and size-cells can > go. Part of the nastiness is that I'm trying to maintain a modicum of > backward compatibility at the moment in the device tree generator. = This > structure allow the dcr@0 node to have ranges; and the tft node to = have > a properly translated reg =3D <> property for the existing driver = which > only understands mmio. I don't think it really works for the opb2dcr > bridge to be a bridge and a dcr-controller at the same time. :) This > structure is also very similar to what is generated if the > dcr-controller is native from the processor (there's just no bridge). I don't really understand what you're getting at here, sorry. Perhaps you could describe what you're doing with the tft device in more detail? > > Current standard practice is not to represent the DCR bus as node = with > > subnodes for the DCR-controlled devices. That's because the DCR bus > > tends to run in addition to other on-chip busses, and some things = have > > to go on another on-chip bus to make sense, but still have DCR = control > > registers (for example the internal bus bridges on 4xx). > >=20 > > Arguably for DCR-only devices we should instead have a node > > representing the DCR bus and just put the devices under it with the > > DCR number encoded in reg in the normal way. But then its > > inconsistent with the devices that need the other DCR = representation. >=20 > Yup, it's exactly this problem I'm trying to fix in the case of the = tft > driver. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ = _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ------_=_NextPart_001_01C8B0C6.881F3D46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: = Usedcrinfrastructure.

The problem is that the tft driver currently in = mainline assumes that the dcr control registers
are accessed through mmio, and probes for a reg=3D<> = property.  Since the device is actually a dcr device,
it can be connected via mmio through a bride, or to the native dcr bus = of the processor.  For the time being,
I'd like to generate device trees compatible with either mechanism.

so, the problem is that the tree-parents of the tft node all have = ranges, and if the dcr-parent of the node is a bridge, then it has a = reg=3D<> property,
But if the dcr-parent is also a tree-parent, then it has to have ranges; = and a reg=3D<> property, which seems very strange, and not = something I think is
a good thing to do.

Steve

-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.= id.au]
Sent: Wed 5/7/2008 6:59 PM
To: Stephen Neuendorffer
Cc: Grant Likely; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: = Usedcrinfrastructure.

On Tue, May 06, 2008 at 10:43:50AM -0700, Stephen Neuendorffer = wrote:
[snip]
> > > Hmmm, something doesn't quite feel right about = this.  The node
> > > describing the tft device is a child of the dcr@0 node = which is the
> > > dcr bus.  However, dcr bindings use dcr-bus and = dcr-reg instead of
> > > parent-child relationship to specify how to access the = dcr
> registers.
> > > So, in this example; if the device is described by = tft@80, and the
> dcr
> > > bus is described by opb2dcr-bridge@40700000, then what = does dcr@0
> > > describe?  (I do understand what they really = describe in EDK terms;
> > > but I'm looking at it through device tree glasses).
> > >
> > > I don't think the presence of a dcr@0 node is a problem, = but in this
> > > case #size/address-cells doesn't have any meaning (the = child doesn't
> > > have a reg property) and it looks like it should be a = child of the
> > > opb2dcr-bridge node (otherwise, what is it attached = to?).
> >
> > Yes, indeed.  If dcr@0 is representing the DCR bus / = interface it
> > should really have the dcr-access-method property and have all = the
> > dcr-parent handles point at it.
>
> Hmm, I tend to agree.  Certainly the address-cells and = size-cells can
> go.  Part of the nastiness is that I'm trying to maintain a = modicum of
> backward compatibility at the moment in the device tree = generator.  This
> structure allow the dcr@0 node to have ranges; and the tft node to = have
> a properly translated reg =3D <> property for the existing = driver which
> only understands mmio.  I don't think it really works for the = opb2dcr
> bridge to be a bridge and a dcr-controller at the same time. = :)  This
> structure is also very similar to what is generated if the
> dcr-controller is native from the processor (there's just no = bridge).

I don't really understand what you're getting at here, sorry.  = Perhaps
you could describe what you're doing with the tft device in more
detail?

> > Current standard practice is not to represent the DCR bus as = node with
> > subnodes for the DCR-controlled devices.  That's because = the DCR bus
> > tends to run in addition to other on-chip busses, and some = things have
> > to go on another on-chip bus to make sense, but still have DCR = control
> > registers (for example the internal bus bridges on 4xx).
> >
> > Arguably for DCR-only devices we should instead have a = node
> > representing the DCR bus and just put the devices under it = with the
> > DCR number encoded in reg in the normal way.  But then = its
> > inconsistent with the devices that need the other DCR = representation.
>
> Yup, it's exactly this problem I'm trying to fix in the case of the = tft
> driver.

--
David Gibson    =         =         | I'll have my music baroque, = and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT = _the_ _other_
        =         =         =         | _way_ _around_!
http://www.ozlabs.org/~dgibson

------_=_NextPart_001_01C8B0C6.881F3D46--