[PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Usedcrinfrastructure.

[Stephen Neuendorffer]

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=<> 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=<> property,
But if the dcr-parent is also a tree-parent, then it has to have ranges; and a reg=<> property, which seems very strange, and not something I think is
a good thing to do.

Steve

-----Original Message-----
From: David Gibson [mailto:david at gibson.dropbear.id.au]
Sent: Wed 5/7/2008 6:59 PM
To: Stephen Neuendorffer
Cc: Grant Likely; linuxppc-dev at 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 at 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 at 80, and the
> dcr
> > > bus is described by opb2dcr-bridge at 40700000, then what does dcr at 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 at 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 at 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 at 0 node to have ranges; and the tft node to have
> a properly translated reg = <> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080507/b035c6bb/attachment.htm>