[PATCH] Device tree bindings for Xilinx devices

[PATCH] Device tree bindings for Xilinx devices

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

This is a first draft, please review and comment.

On a side node, I think booting-without-of.txt could get really unwieldly
in the near future.  Perhaps the device tree bindings should be organized
differently and separated from the functional description of device tree
usage.  Thoughts?

Cheers,
g.

 Documentation/powerpc/booting-without-of.txt |   58 ++++++++++++++++++++++++++
 1 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 20e0e6c..a6d6056 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1850,6 +1850,64 @@ platforms are moved over to use the flattened-device-tree model.
 
    More devices will be defined as this spec matures.
 
+   l) Xilinx ML300 Framebuffer
+
+   Simple framebuffer device from the ML300 reference design (also on the
+   ML403 reference design as well as others).
+
+   Required properties:
+    - compatible : Must include "xilinx,ml300-fb"
+    - reg : offset and length of the framebuffer register set
+
+   Optional properties:
+    - resolution : <xres yres> pixel resolution of framebuffer.  Some
+                   implementations use a different resolution.  Default
+                   is <d#640 d#480>
+    - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
+                        Default is <d#1024 d#480>.
+    - rotate-display : rotate display 180 degrees.
+    - display-number : Logical number of display
+
+   m) Xilinx SystemACE
+
+   The Xilinx SystemACE device is used to program FPGAs from an FPGA
+   bitstream stored on a CF card.  It can also be used as a generic CF
+   interface device.
+
+   Required properties:
+    - compatible : Must include "xilinx,sysace"
+    - reg : offset and length of SystemACE register set
+
+   Recommended properties:
+    - interrupt-parent, interrupts : Connection of device irq signal.
+
+   Optional properties:
+    - number : logical number of the SystemACE device based at 0.
+    - 8-bit (empty) : Set this property if the SystemACE must be in 8 bit mode
+
+   n) Xilinx EMAC and Xilinx TEMAC
+
+   Xilinx Ethernet devices.  Uses common properties from other Ethernet
+   devices with the following constraints:
+   
+   Required properties:
+    - compatible : Must include one of: "xilinx,plb-temac",
+                   "xilinx,plb-emac", "xilinx-opb-emac"
+    - dma-mode : Must be one of "none", "simple", "sg" (sg == scatter gather)
+
+   o) Xilinx Uartlite
+
+   Xilinx uartlite devices are simple fixed speed serial ports.  Uartlite
+   ports should be described in a node with the following properties.
+
+   Requred properties:
+    - compatible : Must include "xilinx,uartlite"
+    - reg : offset and length of uartlite register set
+
+    Recommended properties:
+    - port-number : logical port number of uartlite device based at 0.
+    - interrupt-parent, interrupts : Connection of device irq signal.
+
 VII - Specifying interrupt information for devices
 ===================================================
 

Re: [PATCH] Device tree bindings for Xilinx devices

[Grant Likely]

Anybody have any comments on this?  Segher?  David?

Cheers,
g.

On 10/8/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> This is a first draft, please review and comment.
>
> On a side node, I think booting-without-of.txt could get really unwieldly
> in the near future.  Perhaps the device tree bindings should be organized
> differently and separated from the functional description of device tree
> usage.  Thoughts?
>
> Cheers,
> g.
>
>  Documentation/powerpc/booting-without-of.txt |   58 ++++++++++++++++++++++++++
>  1 files changed, 58 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 20e0e6c..a6d6056 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1850,6 +1850,64 @@ platforms are moved over to use the flattened-device-tree model.
>
>     More devices will be defined as this spec matures.
>
> +   l) Xilinx ML300 Framebuffer
> +
> +   Simple framebuffer device from the ML300 reference design (also on the
> +   ML403 reference design as well as others).
> +
> +   Required properties:
> +    - compatible : Must include "xilinx,ml300-fb"
> +    - reg : offset and length of the framebuffer register set
> +
> +   Optional properties:
> +    - resolution : <xres yres> pixel resolution of framebuffer.  Some
> +                   implementations use a different resolution.  Default
> +                   is <d#640 d#480>
> +    - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
> +                        Default is <d#1024 d#480>.
> +    - rotate-display : rotate display 180 degrees.
> +    - display-number : Logical number of display
> +
> +   m) Xilinx SystemACE
> +
> +   The Xilinx SystemACE device is used to program FPGAs from an FPGA
> +   bitstream stored on a CF card.  It can also be used as a generic CF
> +   interface device.
> +
> +   Required properties:
> +    - compatible : Must include "xilinx,sysace"
> +    - reg : offset and length of SystemACE register set
> +
> +   Recommended properties:
> +    - interrupt-parent, interrupts : Connection of device irq signal.
> +
> +   Optional properties:
> +    - number : logical number of the SystemACE device based at 0.
> +    - 8-bit (empty) : Set this property if the SystemACE must be in 8 bit mode
> +
> +   n) Xilinx EMAC and Xilinx TEMAC
> +
> +   Xilinx Ethernet devices.  Uses common properties from other Ethernet
> +   devices with the following constraints:
> +
> +   Required properties:
> +    - compatible : Must include one of: "xilinx,plb-temac",
> +                   "xilinx,plb-emac", "xilinx-opb-emac"
> +    - dma-mode : Must be one of "none", "simple", "sg" (sg == scatter gather)
> +
> +   o) Xilinx Uartlite
> +
> +   Xilinx uartlite devices are simple fixed speed serial ports.  Uartlite
> +   ports should be described in a node with the following properties.
> +
> +   Requred properties:
> +    - compatible : Must include "xilinx,uartlite"
> +    - reg : offset and length of uartlite register set
> +
> +    Recommended properties:
> +    - port-number : logical port number of uartlite device based at 0.
> +    - interrupt-parent, interrupts : Connection of device irq signal.
> +
>  VII - Specifying interrupt information for devices
>  ===================================================
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Device tree bindings for Xilinx devices

[Josh Boyer]

On Mon, 2007-10-08 at 01:53 -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> 
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> 
> This is a first draft, please review and comment.

I'll start off with the fact that I hardly consider myself a DT expert,
so take what I say with a grain of salt.

> On a side node, I think booting-without-of.txt could get really unwieldly
> in the near future.  Perhaps the device tree bindings should be organized
> differently and separated from the functional description of device tree
> usage.  Thoughts?
> 
> Cheers,
> g.
> 
>  Documentation/powerpc/booting-without-of.txt |   58 ++++++++++++++++++++++++++
>  1 files changed, 58 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 20e0e6c..a6d6056 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1850,6 +1850,64 @@ platforms are moved over to use the flattened-device-tree model.
> 
>     More devices will be defined as this spec matures.
> 
> +   l) Xilinx ML300 Framebuffer
> +
> +   Simple framebuffer device from the ML300 reference design (also on the
> +   ML403 reference design as well as others).
> +
> +   Required properties:
> +    - compatible : Must include "xilinx,ml300-fb"

Similarly, "xilinx,ml403-fb" will be required for ML403 correct?  Or do
they share exact identical implementations?

> +    - reg : offset and length of the framebuffer register set
> +
> +   Optional properties:
> +    - resolution : <xres yres> pixel resolution of framebuffer.  Some
> +                   implementations use a different resolution.  Default
> +                   is <d#640 d#480>
> +    - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
> +                        Default is <d#1024 d#480>.
> +    - rotate-display : rotate display 180 degrees.
> +    - display-number : Logical number of display
> +
> +   m) Xilinx SystemACE
> +
> +   The Xilinx SystemACE device is used to program FPGAs from an FPGA
> +   bitstream stored on a CF card.  It can also be used as a generic CF
> +   interface device.
> +
> +   Required properties:
> +    - compatible : Must include "xilinx,sysace"
> +    - reg : offset and length of SystemACE register set
> +
> +   Recommended properties:
> +    - interrupt-parent, interrupts : Connection of device irq signal.
> +
> +   Optional properties:
> +    - number : logical number of the SystemACE device based at 0.

"number" seems a bit to generic to me.  logical-number seems a bit more
descriptive.

> +    - 8-bit (empty) : Set this property if the SystemACE must be in 8 bit mode
> +
> +   n) Xilinx EMAC and Xilinx TEMAC
> +
> +   Xilinx Ethernet devices.  Uses common properties from other Ethernet
> +   devices with the following constraints:
> +   
> +   Required properties:
> +    - compatible : Must include one of: "xilinx,plb-temac",
> +                   "xilinx,plb-emac", "xilinx-opb-emac"

I think you mean "xilinx,opb-emac" on that last one.

> +    - dma-mode : Must be one of "none", "simple", "sg" (sg == scatter gather)
> +
> +   o) Xilinx Uartlite
> +
> +   Xilinx uartlite devices are simple fixed speed serial ports.  Uartlite
> +   ports should be described in a node with the following properties.
> +
> +   Requred properties:
> +    - compatible : Must include "xilinx,uartlite"
> +    - reg : offset and length of uartlite register set
> +
> +    Recommended properties:
> +    - port-number : logical port number of uartlite device based at 0.
> +    - interrupt-parent, interrupts : Connection of device irq signal.
> +

josh

Re: [PATCH] Device tree bindings for Xilinx devices

[David Gibson]

On Wed, Oct 10, 2007 at 03:38:02PM -0500, Josh Boyer wrote:
> On Mon, 2007-10-08 at 01:53 -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> > 
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> > 
> > This is a first draft, please review and comment.
> 
> I'll start off with the fact that I hardly consider myself a DT expert,
> so take what I say with a grain of salt.
> 
> > On a side node, I think booting-without-of.txt could get really unwieldly
> > in the near future.  Perhaps the device tree bindings should be organized
> > differently and separated from the functional description of device tree
> > usage.  Thoughts?
> > 
> > Cheers,
> > g.
> > 
> >  Documentation/powerpc/booting-without-of.txt |   58 ++++++++++++++++++++++++++
> >  1 files changed, 58 insertions(+), 0 deletions(-)
> > 
> > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > index 20e0e6c..a6d6056 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -1850,6 +1850,64 @@ platforms are moved over to use the flattened-device-tree model.
> > 
> >     More devices will be defined as this spec matures.
> > 
> > +   l) Xilinx ML300 Framebuffer
> > +
> > +   Simple framebuffer device from the ML300 reference design (also on the
> > +   ML403 reference design as well as others).
> > +
> > +   Required properties:
> > +    - compatible : Must include "xilinx,ml300-fb"
> 
> Similarly, "xilinx,ml403-fb" will be required for ML403 correct?  Or do
> they share exact identical implementations?
> 
> > +    - reg : offset and length of the framebuffer register set
> > +
> > +   Optional properties:
> > +    - resolution : <xres yres> pixel resolution of framebuffer.  Some
> > +                   implementations use a different resolution.  Default
> > +                   is <d#640 d#480>
> > +    - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
> > +                        Default is <d#1024 d#480>.
> > +    - rotate-display : rotate display 180 degrees.
> > +    - display-number : Logical number of display
> > +
> > +   m) Xilinx SystemACE
> > +
> > +   The Xilinx SystemACE device is used to program FPGAs from an FPGA
> > +   bitstream stored on a CF card.  It can also be used as a generic CF
> > +   interface device.
> > +
> > +   Required properties:
> > +    - compatible : Must include "xilinx,sysace"
> > +    - reg : offset and length of SystemACE register set
> > +
> > +   Recommended properties:
> > +    - interrupt-parent, interrupts : Connection of device irq signal.
> > +
> > +   Optional properties:
> > +    - number : logical number of the SystemACE device based at 0.
> 
> "number" seems a bit to generic to me.  logical-number seems a bit more
> descriptive.

We've used 'cell-index' for similar purposes on other 4xx.

> 
> > +    - 8-bit (empty) : Set this property if the SystemACE must be in 8 bit mode
> > +
> > +   n) Xilinx EMAC and Xilinx TEMAC
> > +
> > +   Xilinx Ethernet devices.  Uses common properties from other Ethernet
> > +   devices with the following constraints:
> > +   
> > +   Required properties:
> > +    - compatible : Must include one of: "xilinx,plb-temac",
> > +                   "xilinx,plb-emac", "xilinx-opb-emac"
> 
> I think you mean "xilinx,opb-emac" on that last one.
> 
> > +    - dma-mode : Must be one of "none", "simple", "sg" (sg == scatter gather)
> > +
> > +   o) Xilinx Uartlite
> > +
> > +   Xilinx uartlite devices are simple fixed speed serial ports.  Uartlite
> > +   ports should be described in a node with the following properties.
> > +
> > +   Requred properties:
> > +    - compatible : Must include "xilinx,uartlite"
> > +    - reg : offset and length of uartlite register set
> > +
> > +    Recommended properties:
> > +    - port-number : logical port number of uartlite device based at 0.
> > +    - interrupt-parent, interrupts : Connection of device irq signal.
> > +
> 
> josh
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

-- 
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

Re: [PATCH] Device tree bindings for Xilinx devices

[Grant Likely]

On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> On Wed, Oct 10, 2007 at 03:38:02PM -0500, Josh Boyer wrote:
> > On Mon, 2007-10-08 at 01:53 -0600, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > ---
> > >
> > > This is a first draft, please review and comment.
> >
> > I'll start off with the fact that I hardly consider myself a DT expert,
> > so take what I say with a grain of salt.
> >
> > > On a side node, I think booting-without-of.txt could get really unwieldly
> > > in the near future.  Perhaps the device tree bindings should be organized
> > > differently and separated from the functional description of device tree
> > > usage.  Thoughts?
> > >
> > > Cheers,
> > > g.
> > >
> > >  Documentation/powerpc/booting-without-of.txt |   58 ++++++++++++++++++++++++++
> > >  1 files changed, 58 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > > index 20e0e6c..a6d6056 100644
> > > --- a/Documentation/powerpc/booting-without-of.txt
> > > +++ b/Documentation/powerpc/booting-without-of.txt
> > > @@ -1850,6 +1850,64 @@ platforms are moved over to use the flattened-device-tree model.
> > >
> > >     More devices will be defined as this spec matures.
> > >
> > > +   l) Xilinx ML300 Framebuffer
> > > +
> > > +   Simple framebuffer device from the ML300 reference design (also on the
> > > +   ML403 reference design as well as others).
> > > +
> > > +   Required properties:
> > > +    - compatible : Must include "xilinx,ml300-fb"
> >
> > Similarly, "xilinx,ml403-fb" will be required for ML403 correct?  Or do
> > they share exact identical implementations?
> >
> > > +    - reg : offset and length of the framebuffer register set
> > > +
> > > +   Optional properties:
> > > +    - resolution : <xres yres> pixel resolution of framebuffer.  Some
> > > +                   implementations use a different resolution.  Default
> > > +                   is <d#640 d#480>
> > > +    - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
> > > +                        Default is <d#1024 d#480>.
> > > +    - rotate-display : rotate display 180 degrees.
> > > +    - display-number : Logical number of display
> > > +
> > > +   m) Xilinx SystemACE
> > > +
> > > +   The Xilinx SystemACE device is used to program FPGAs from an FPGA
> > > +   bitstream stored on a CF card.  It can also be used as a generic CF
> > > +   interface device.
> > > +
> > > +   Required properties:
> > > +    - compatible : Must include "xilinx,sysace"
> > > +    - reg : offset and length of SystemACE register set
> > > +
> > > +   Recommended properties:
> > > +    - interrupt-parent, interrupts : Connection of device irq signal.
> > > +
> > > +   Optional properties:
> > > +    - number : logical number of the SystemACE device based at 0.
> >
> > "number" seems a bit to generic to me.  logical-number seems a bit more
> > descriptive.
>
> We've used 'cell-index' for similar purposes on other 4xx.

Unfortunately, 'cell' has been used in the sense of a logic cell in an
SoC.  In the case of the SystemACE, it is an external chip.

What about "device-number"?

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Device tree bindings for Xilinx devices

[David Gibson]

On Wed, Oct 10, 2007 at 08:25:36PM -0600, Grant Likely wrote:
> On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > On Wed, Oct 10, 2007 at 03:38:02PM -0500, Josh Boyer wrote:
[snip]
> > > "number" seems a bit to generic to me.  logical-number seems a bit more
> > > descriptive.
> >
> > We've used 'cell-index' for similar purposes on other 4xx.
> 
> Unfortunately, 'cell' has been used in the sense of a logic cell in an
> SoC.  In the case of the SystemACE, it is an external chip.
> 
> What about "device-number"?

Ok, I misunderstood.  If it's not on chip, what significance does this
serial number have?  Where would a driver need it?

-- 
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

Re: [PATCH] Device tree bindings for Xilinx devices

[Grant Likely]

On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> On Wed, Oct 10, 2007 at 08:25:36PM -0600, Grant Likely wrote:
> > On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > > We've used 'cell-index' for similar purposes on other 4xx.
> >
> > Unfortunately, 'cell' has been used in the sense of a logic cell in an
> > SoC.  In the case of the SystemACE, it is an external chip.
> >
> > What about "device-number"?
>
> Ok, I misunderstood.  If it's not on chip, what significance does this
> serial number have?  Where would a driver need it?

If there were 2 systemace devices on board; one attached to a CF slot
labeled "1" and the other to one labeled "2".  :-)  Same problem as
lining up serial device files to physical port numbers.

The driver doesn't technically need it, but the information does need
to flow through to the creation of logically numbered device files.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Device tree bindings for Xilinx devices

[David Gibson]

On Wed, Oct 10, 2007 at 10:18:50PM -0600, Grant Likely wrote:
> On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > On Wed, Oct 10, 2007 at 08:25:36PM -0600, Grant Likely wrote:
> > > On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > > > We've used 'cell-index' for similar purposes on other 4xx.
> > >
> > > Unfortunately, 'cell' has been used in the sense of a logic cell in an
> > > SoC.  In the case of the SystemACE, it is an external chip.
> > >
> > > What about "device-number"?
> >
> > Ok, I misunderstood.  If it's not on chip, what significance does this
> > serial number have?  Where would a driver need it?
> 
> If there were 2 systemace devices on board; one attached to a CF slot
> labeled "1" and the other to one labeled "2".  :-)  Same problem as
> lining up serial device files to physical port numbers.
> 
> The driver doesn't technically need it, but the information does need
> to flow through to the creation of logically numbered device files.

Ah.  Then, I'm afraid it doesn't belong in the core binding.

Preferably, you should just figure out something without help of this
property - plenty of other things have to figure out device names
without assistance like this.

If you really must you could do this in analogy with the
"linux,network-index" property - but this would be, as that is, an
ugly hack, and should be recognized as such.

Segher's suggestion of using OF-style aliases for this is a fairly
good one, actually.  I just need to get to implementing it...

-- 
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

Re: [PATCH] Device tree bindings for Xilinx devices

[Grant Likely]

On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> On Wed, Oct 10, 2007 at 10:18:50PM -0600, Grant Likely wrote:
> > On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > > On Wed, Oct 10, 2007 at 08:25:36PM -0600, Grant Likely wrote:
> > > > On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > > > > We've used 'cell-index' for similar purposes on other 4xx.
> > > >
> > > > Unfortunately, 'cell' has been used in the sense of a logic cell in an
> > > > SoC.  In the case of the SystemACE, it is an external chip.
> > > >
> > > > What about "device-number"?
> > >
> > > Ok, I misunderstood.  If it's not on chip, what significance does this
> > > serial number have?  Where would a driver need it?
> >
> > If there were 2 systemace devices on board; one attached to a CF slot
> > labeled "1" and the other to one labeled "2".  :-)  Same problem as
> > lining up serial device files to physical port numbers.
> >
> > The driver doesn't technically need it, but the information does need
> > to flow through to the creation of logically numbered device files.
>
> Ah.  Then, I'm afraid it doesn't belong in the core binding.
>
> Preferably, you should just figure out something without help of this
> property - plenty of other things have to figure out device names
> without assistance like this.

I'm not too stuck on the method used, but I do think it is appropriate
to encode this kind of data in the device tree in some form...
However, for this particular device I'm probably just borrowing
trouble.  I'll drop the property.

My main concern is that I don't like the implicit numbering that
occurs simply based on the order of devices in the device tree.  If
the probe algorithm ever changes to parse in reverse order or
something reorders the tree, then the device numbers also change.  :-(

I'd rather be explicit.  In fact I've already been bitten by this
where the mpc5200 has 6 PSC, each of which can be configured as a
serial port.  However, I've got access to 3 different boards; each of
which has the logical port numbers 100% unrelated to the 'cell'
number.

> If you really must you could do this in analogy with the
> "linux,network-index" property - but this would be, as that is, an
> ugly hack, and should be recognized as such
>
> Segher's suggestion of using OF-style aliases for this is a fairly
> good one, actually.  I just need to get to implementing it...

/me needs to look up what that look like and how I would use it.  My
knowledge of OF is sadly lacking.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Device tree bindings for Xilinx devices

[David Gibson]

On Wed, Oct 10, 2007 at 10:58:25PM -0600, Grant Likely wrote:
> On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > On Wed, Oct 10, 2007 at 10:18:50PM -0600, Grant Likely wrote:
> > > On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > > > On Wed, Oct 10, 2007 at 08:25:36PM -0600, Grant Likely wrote:
> > > > > On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > > > > > We've used 'cell-index' for similar purposes on other 4xx.
> > > > >
> > > > > Unfortunately, 'cell' has been used in the sense of a logic cell in an
> > > > > SoC.  In the case of the SystemACE, it is an external chip.
> > > > >
> > > > > What about "device-number"?
> > > >
> > > > Ok, I misunderstood.  If it's not on chip, what significance does this
> > > > serial number have?  Where would a driver need it?
> > >
> > > If there were 2 systemace devices on board; one attached to a CF slot
> > > labeled "1" and the other to one labeled "2".  :-)  Same problem as
> > > lining up serial device files to physical port numbers.
> > >
> > > The driver doesn't technically need it, but the information does need
> > > to flow through to the creation of logically numbered device files.
> >
> > Ah.  Then, I'm afraid it doesn't belong in the core binding.
> >
> > Preferably, you should just figure out something without help of this
> > property - plenty of other things have to figure out device names
> > without assistance like this.
> 
> I'm not too stuck on the method used, but I do think it is appropriate
> to encode this kind of data in the device tree in some form...
> However, for this particular device I'm probably just borrowing
> trouble.  I'll drop the property.
> 
> My main concern is that I don't like the implicit numbering that
> occurs simply based on the order of devices in the device tree.  If
> the probe algorithm ever changes to parse in reverse order or
> something reorders the tree, then the device numbers also change.  :-(

Way of the future, apparently, everything's supposed to use udev to
give things logical names.  No, I'm not thrilled at the prospect
either.

> I'd rather be explicit.  In fact I've already been bitten by this
> where the mpc5200 has 6 PSC, each of which can be configured as a
> serial port.  However, I've got access to 3 different boards; each of
> which has the logical port numbers 100% unrelated to the 'cell'
> number.

In any case, this can't really belong in a *device* binding.  Because
the numbering has to cross devices of the same basic type, but
different implementations.  Where "basic type" is based on how device
names are allocated, and is thus inherently Linux specific.

> > If you really must you could do this in analogy with the
> > "linux,network-index" property - but this would be, as that is, an
> > ugly hack, and should be recognized as such
> >
> > Segher's suggestion of using OF-style aliases for this is a fairly
> > good one, actually.  I just need to get to implementing it...
> 
> /me needs to look up what that look like and how I would use it.  My
> knowledge of OF is sadly lacking.

Short version by example:
/ {
	/* ... */
	aliases {
		hd = "/pci@f0000000/sata@f4000000/....";
		enet0 = "/soc/ethernet@c000";
		enet1 = "/soc/ethernet@d000";
		enet2 = "/pci@f0000000/isa/ethernet@i480"
		ttya = "/soc/serial@e000";
		ttyb = "/pci/isa/serail@3f8";
	}
}

-- 
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

Re: [PATCH] Device tree bindings for Xilinx devices

[Grant Likely]

On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > My main concern is that I don't like the implicit numbering that
> > occurs simply based on the order of devices in the device tree.  If
> > the probe algorithm ever changes to parse in reverse order or
> > something reorders the tree, then the device numbers also change.  :-(
>
> Way of the future, apparently, everything's supposed to use udev to
> give things logical names.  No, I'm not thrilled at the prospect
> either.

...

So in the OF aliases approach, would udev need to read the aliases
node when assigning names to devices?

>
> > I'd rather be explicit.  In fact I've already been bitten by this
> > where the mpc5200 has 6 PSC, each of which can be configured as a
> > serial port.  However, I've got access to 3 different boards; each of
> > which has the logical port numbers 100% unrelated to the 'cell'
> > number.
>
> In any case, this can't really belong in a *device* binding.  Because
> the numbering has to cross devices of the same basic type, but
> different implementations.  Where "basic type" is based on how device
> names are allocated, and is thus inherently Linux specific.

Okay, that makes sense.

> > > Segher's suggestion of using OF-style aliases for this is a fairly
> > > good one, actually.  I just need to get to implementing it...
> >
> > /me needs to look up what that look like and how I would use it.  My
> > knowledge of OF is sadly lacking.
>
> Short version by example:
> / {
>         /* ... */
>         aliases {
>                 hd = "/pci@f0000000/sata@f4000000/....";
>                 enet0 = "/soc/ethernet@c000";
>                 enet1 = "/soc/ethernet@d000";
>                 enet2 = "/pci@f0000000/isa/ethernet@i480"
>                 ttya = "/soc/serial@e000";
>                 ttyb = "/pci/isa/serail@3f8";
>         }
> }

Ah, my plan worked...  I got you to teach me about OF aliases and I
have to do any work myself.  :-)

Hmm, yes that would provide the information nicely.  As long as the
data is in the tree, I'm pretty happy.

Cheers,
g.

>
> --
> 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
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Device tree bindings for Xilinx devices

[David Gibson]

On Wed, Oct 10, 2007 at 11:27:14PM -0600, Grant Likely wrote:
> On 10/10/07, David Gibson <dwg@au1.ibm.com> wrote:
> > > My main concern is that I don't like the implicit numbering that
> > > occurs simply based on the order of devices in the device tree.  If
> > > the probe algorithm ever changes to parse in reverse order or
> > > something reorders the tree, then the device numbers also change.  :-(
> >
> > Way of the future, apparently, everything's supposed to use udev to
> > give things logical names.  No, I'm not thrilled at the prospect
> > either.
> 
> ...
> 
> So in the OF aliases approach, would udev need to read the aliases
> node when assigning names to devices?

Well... maybe.  Exactly how to sensibly propogate the information up
to userspace depends on the type of device and other factors.  In most
cases I'd expect some kind of kernel intermediary between the device
tree and udev, but there might be instances where it would make sense
for udev to directly access /proc/device-tree/aliases via a helper
program.

In any case, if the kernel does provide some sort of name/number for
the device, you can use the aliases for that.

> > > I'd rather be explicit.  In fact I've already been bitten by this
> > > where the mpc5200 has 6 PSC, each of which can be configured as a
> > > serial port.  However, I've got access to 3 different boards; each of
> > > which has the logical port numbers 100% unrelated to the 'cell'
> > > number.
> >
> > In any case, this can't really belong in a *device* binding.  Because
> > the numbering has to cross devices of the same basic type, but
> > different implementations.  Where "basic type" is based on how device
> > names are allocated, and is thus inherently Linux specific.
> 
> Okay, that makes sense.
> 
> > > > Segher's suggestion of using OF-style aliases for this is a fairly
> > > > good one, actually.  I just need to get to implementing it...
> > >
> > > /me needs to look up what that look like and how I would use it.  My
> > > knowledge of OF is sadly lacking.
> >
> > Short version by example:
> > / {
> >         /* ... */
> >         aliases {
> >                 hd = "/pci@f0000000/sata@f4000000/....";
> >                 enet0 = "/soc/ethernet@c000";
> >                 enet1 = "/soc/ethernet@d000";
> >                 enet2 = "/pci@f0000000/isa/ethernet@i480"
> >                 ttya = "/soc/serial@e000";
> >                 ttyb = "/pci/isa/serail@3f8";
> >         }
> > }
> 
> Ah, my plan worked...  I got you to teach me about OF aliases and I
> have to do any work myself.  :-)

Well, be careful, and take that example with a grain of salt.  I made
it up on the spot without checking a lot, so although it gives you the
general idea, I probably haven't followed conventions for the names of
the aliases and so forth.

> Hmm, yes that would provide the information nicely.  As long as the
> data is in the tree, I'm pretty happy.

-- 
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