<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Usedcrinfrastructure.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=2>The problem is that the tft driver currently in mainline assumes that the dcr control registers<BR>
are accessed through mmio, and probes for a reg=&lt;&gt; property.&nbsp; Since the device is actually a dcr device,<BR>
it can be connected via mmio through a bride, or to the native dcr bus of the processor.&nbsp; For the time being,<BR>
I'd like to generate device trees compatible with either mechanism.<BR>
<BR>
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=&lt;&gt; property,<BR>
But if the dcr-parent is also a tree-parent, then it has to have ranges; and a reg=&lt;&gt; property, which seems very strange, and not something I think is<BR>
a good thing to do.<BR>
<BR>
Steve<BR>
<BR>
-----Original Message-----<BR>
From: David Gibson [<A HREF="mailto:david@gibson.dropbear.id.au">mailto:david@gibson.dropbear.id.au</A>]<BR>
Sent: Wed 5/7/2008 6:59 PM<BR>
To: Stephen Neuendorffer<BR>
Cc: Grant Likely; linuxppc-dev@ozlabs.org<BR>
Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Usedcrinfrastructure.<BR>
<BR>
On Tue, May 06, 2008 at 10:43:50AM -0700, Stephen Neuendorffer wrote:<BR>
[snip]<BR>
&gt; &gt; &gt; Hmmm, something doesn't quite feel right about this.&nbsp; The node<BR>
&gt; &gt; &gt; describing the tft device is a child of the dcr@0 node which is the<BR>
&gt; &gt; &gt; dcr bus.&nbsp; However, dcr bindings use dcr-bus and dcr-reg instead of<BR>
&gt; &gt; &gt; parent-child relationship to specify how to access the dcr<BR>
&gt; registers.<BR>
&gt; &gt; &gt; So, in this example; if the device is described by tft@80, and the<BR>
&gt; dcr<BR>
&gt; &gt; &gt; bus is described by opb2dcr-bridge@40700000, then what does dcr@0<BR>
&gt; &gt; &gt; describe?&nbsp; (I do understand what they really describe in EDK terms;<BR>
&gt; &gt; &gt; but I'm looking at it through device tree glasses).<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; I don't think the presence of a dcr@0 node is a problem, but in this<BR>
&gt; &gt; &gt; case #size/address-cells doesn't have any meaning (the child doesn't<BR>
&gt; &gt; &gt; have a reg property) and it looks like it should be a child of the<BR>
&gt; &gt; &gt; opb2dcr-bridge node (otherwise, what is it attached to?).<BR>
&gt; &gt;<BR>
&gt; &gt; Yes, indeed.&nbsp; If dcr@0 is representing the DCR bus / interface it<BR>
&gt; &gt; should really have the dcr-access-method property and have all the<BR>
&gt; &gt; dcr-parent handles point at it.<BR>
&gt;<BR>
&gt; Hmm, I tend to agree.&nbsp; Certainly the address-cells and size-cells can<BR>
&gt; go.&nbsp; Part of the nastiness is that I'm trying to maintain a modicum of<BR>
&gt; backward compatibility at the moment in the device tree generator.&nbsp; This<BR>
&gt; structure allow the dcr@0 node to have ranges; and the tft node to have<BR>
&gt; a properly translated reg = &lt;&gt; property for the existing driver which<BR>
&gt; only understands mmio.&nbsp; I don't think it really works for the opb2dcr<BR>
&gt; bridge to be a bridge and a dcr-controller at the same time. :)&nbsp; This<BR>
&gt; structure is also very similar to what is generated if the<BR>
&gt; dcr-controller is native from the processor (there's just no bridge).<BR>
<BR>
I don't really understand what you're getting at here, sorry.&nbsp; Perhaps<BR>
you could describe what you're doing with the tft device in more<BR>
detail?<BR>
<BR>
&gt; &gt; Current standard practice is not to represent the DCR bus as node with<BR>
&gt; &gt; subnodes for the DCR-controlled devices.&nbsp; That's because the DCR bus<BR>
&gt; &gt; tends to run in addition to other on-chip busses, and some things have<BR>
&gt; &gt; to go on another on-chip bus to make sense, but still have DCR control<BR>
&gt; &gt; registers (for example the internal bus bridges on 4xx).<BR>
&gt; &gt;<BR>
&gt; &gt; Arguably for DCR-only devices we should instead have a node<BR>
&gt; &gt; representing the DCR bus and just put the devices under it with the<BR>
&gt; &gt; DCR number encoded in reg in the normal way.&nbsp; But then its<BR>
&gt; &gt; inconsistent with the devices that need the other DCR representation.<BR>
&gt;<BR>
&gt; Yup, it's exactly this problem I'm trying to fix in the case of the tft<BR>
&gt; driver.<BR>
<BR>
--<BR>
David Gibson&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | I'll have my music baroque, and my code<BR>
david AT gibson.dropbear.id.au&nbsp; | minimalist, thank you.&nbsp; NOT _the_ _other_<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | _way_ _around_!<BR>
<A HREF="http://www.ozlabs.org/~dgibson">http://www.ozlabs.org/~dgibson</A><BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>