[RFC] Device tree for new desktop platform in arch/powerpc

[RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

Hi,

I'm working on support for the AmigaOne and started to write a device tree source file for use with the cuboot bootwrapper. Additionally to the booting-without-of.txt document and other dts files I found some OpenFirmware related documents on http://playground.sun.com/1275/ and tried to follow their guidelines. Note that I didn't try to compile the dts file yet, as it is not yet complete.

Some questions arose during the implementation, which I hope some of you can answer:

1. The AmigaOne makes use of different G3 (750Cx, 750GL, 750GX) and G4 (7400, 7450, 7455, 7457) CPUs. The current dts file defines a cpu node with the name "PowerPC,7xxx@0" and the bootwrapper just fills in the cpu-, bus- and timebase frequencies. Is this the recommended way, or should the bootwrapper create a fresh cpu node with the correct name of the CPU (e.g. "PowerPC,7455@ 0" - I guess this would require a table with all PVR values and their corresponding CPU name. Or is there a function in the kernel that do this?).

2. I tried to define all ISA devices, which are integrated in the southbridge (VT82C686B). Currently these are child nodes of the device tree root. Should they be child nodes of the southbridge's PCI-to-ISA device node? If so, where should I specify the register address ranges (reg property)? In the PCI device node or in the ISA device nodes, as it is now?

3. The dts files define the device_type of a serial port as "serial", whereas the OF spec says "pnpPNP,501". What's the difference between the two?

4. I couldn't find any information for a device tree representation of the i8259 interrupt controller in the booting-without-of.txt file. Is my implementation correct (inspired by the OF documents)?

I would be grateful, if you could take a look at my dts file and comment on every line that doesn't meet your views.

Thanks in advance!

regards,

Gerhard
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

[-- Attachment #2: amigaone.dts --]
[-- Type: application/octet-stream, Size: 4047 bytes --]

/*
 * AmigaOne Device Tree Source
 *
 * Copyright 2007 Gerhard Pircher (gerhard_pircher@gmx.net)
 *
 * This program is free software; you can redistribute  it and/or modify it
 * under  the terms of  the GNU General  Public License as published by the
 * Free Software Foundation;  either version 2 of the  License, or (at your
 * option) any later version.
 */


/ {
	model = "Eyetech,AmigaOne";
	compatible = "Eyetech,AmigaOne" "MAI,Teron";
	#address-cells = <1>;
	#size-cells = <1>;

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		PowerPC,7xxx@0 {			// Can be 75x or 745x?
			device_type = "cpu";
			reg = <0>;
			d-cache-line-size = <20>;	// 32 bytes
			i-cache-line-size = <20>;	// 32 bytes
			d-cache-size = <8000>;		// L1, 32K
			i-cache-size = <8000>;		// L1, 32K
			timebase-frequency = <0>;	// 33.3 MHz, from U-boot
			clock-frequency = <0>;		// From U-boot
			bus-frequency = <0>;		// From U-boot
			32-bit;
		};
	};

	memory {
		device_type = "memory";
		reg = <0 0>;				// From U-boot
	};

	// Should the following nodes be childs of a ISA bus node?

	dma-controller {
		device_type = "dma-controller";
		compatible = "chrp,dma";
		reg = <0 10 80 10 c0 20>;
		/* Channel 4 reserverd, cascade mode, 2x32k transfer/counter
		 * widths and bus master capability. Is this really necessary?
		 */
/*		dma = <4 4 20 20 1>; */
		#address-cells = <1>;
		#size-cells = <0>;			// No physical address.
	};

  	interrupt-controller {
		device_type = "interrupt-controller";
		compatible = "chrp,iic";
		interrupt-controller;
		reg = <20 2 a0 2 4d0 2>;
		reserved-interrupts = <2>;
		#address-cells = <1>;
		#size-cells = <0>;
		#interrupt-cells = <2>;
	};

	8042@60 {
		device_type = "8042";
		compatible = "chrp,8042";
		reg = <60 10>;
		interrupts = <1 3 c 3>;			// IRQ1, IRQ12 (rising edge)
		interrupt-parent = <&interrupt-controller>;
		#address-cells = <1>;
		#size-cells = <0>;			// No physical address.

		keyboard {
			device_type = "keyboard";
			compatible = "pnpPNP,303";
			reg = <0>;
		};

		mouse {
			device_type = "mouse";
			compatible = "pnpPNP,f03";
			reg = <1>;
		};
	};

	timer@40 {
		device_type = "timer";
		reg = <40 20>
		#address-cells = <1>;
		#size-cells = <0>;
	};

	rtc@70 {
		device_type = "rtc";
		compatible = <ds1385-rtc>;
		reg = <70 2>;
		interrupts = <8 3>;
		#address-cells = <1>;
		#size-cells = <0>;
	};

	serial@3f8 {
		device_type = "serial";
/*		compatible = "pnpPNP,501";*/
		compatible = "ns16550";
		reg = <3f8 8>;
		interrupts = <4 3>;			// IRQ4 (rising edge)
		interrupt-parent = <&interrupt-controller>;
		clock-frequency = <0>;			// Not necessary?
		#address-cells = <1>;
		#size-cells = <0>;
	};

	serial@2f8 {
		device_type = "serial";
/*		compatible = "pnpPNP,501";*/
		compatible = "ns16550";
		reg = <2f8 8>;
		interrupts = <3 3>;			// IRQ3 (rising edge)
		interrupt-parent = <&interrupt-controller>;
		clock-frequency = <0>;			// Not necessary?
		#address-cells = <1>;
		#size-cells = <0>;
	};

	parallel@378 {
		device_type = "parallel";
		compatible = "chrp,ecp";
		reg = <378 3 778 3>;
/*		interrupts = <7>;*/			// No IRQ free on AmigaOne!
		interrupt-parent = <&interrupt-controller>;
/*		dma = <3 0 0 0>;*/			// Parallel port DMA mode?
		#address-cells = <1>;
		#size-cells = <0>;
	};

	fdc@3f0 {
		device_type = "fdc";
		compatible = "pnpPNP,700";
		reg = <3f0 8>;
		interrupts = <6 3>;			// IRQ6 (rising edge)
		interrupt-parent = <&interrupt-controller>;
/*		dma = < >;*/				// Floppy DMA mode?
		#address-cells = <1>;
		#size-cells = <0>;

		disk {
			device_type = "block";
			reg = <0>;
		};
	};	

  	pci@80000000 {
		device_type = "pci";
		bus-frequency = <01fca055>;		// 33.3MHz
		bus-range = <0 f>;
		reg = <80000000 7f000000>;			// Whole PCI space.
		ranges = <01000000 0 0 fe000000 0 00c00000	// PCI I/O
			  02000000 0 0 80000000 0 7d000000	// PCI memory
			  02000000 0 0 fd000000 0 01000000	// PCI alias memory
			  00000000 0 0 fec00000 0 00300000>;	// PCI config
		8259-interrupt-acknowledge = <fef00000>;
		#address-cells = <3>;
		#size-cells = <2>;
	};
};

[-- Attachment #3: ioports --]
[-- Type: application/octet-stream, Size: 1190 bytes --]

00000000-00bfffff : PCI host bridge
  00000000-0000001f : dma1
  00000020-00000021 : 8259 (master)
  00000040-0000005f : timer
  00000060-0000006f : i8042
  00000080-0000008f : dma page reg
  000000a0-000000a1 : 8259 (slave)
  000000c0-000000df : dma2
  00000170-00000177 : ide1
  000001f0-000001f7 : ide0
  000002f8-000002ff : serial
  00000376-00000376 : ide1
  00000378-0000037a : parport0
  000003c0-000003df : vga+
  000003e8-000003ef : serial
  000003f6-000003f6 : ide0
  000003f8-000003ff : serial
  000004d0-000004d1 : 8259 edge control
  00002000-00002fff : PCI Bus #01
    00002000-000020ff : 0000:01:00.0
  0000cc00-0000cc0f : 0000:00:07.1
    0000cc00-0000cc07 : ide0
    0000cc08-0000cc0f : ide1
  00802000-0080207f : 0000:00:06.0
  00802080-0080209f : 0000:00:07.2
    00802080-0080209f : uhci_hcd
  008020a0-008020bf : 0000:00:07.3
    008020a0-008020bf : uhci_hcd
  00802100-008021ff : 0000:00:07.5
  00802200-00802203 : 0000:00:07.5
  00802204-00802207 : 0000:00:07.5
  00802300-008023ff : 0000:00:07.6
  00802400-0080241f : 0000:00:09.0
    00802400-0080241f : EMU10K1
  00802420-00802427 : 0000:00:09.1
    00802420-00802427 : emu10k1-gp
e100e000-e100e07f : 0000:00:06.0

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Mark A. Greer]

On Mon, Jun 18, 2007 at 08:57:15PM +0200, Gerhard Pircher wrote:

> 1. The AmigaOne makes use of different G3 (750Cx, 750GL, 750GX) and G4 (7400, 7450, 7455, 7457) CPUs. The current dts file defines a cpu node with the name "PowerPC,7xxx@0" and the bootwrapper just fills in the cpu-, bus- and timebase frequencies. Is this the recommended way, or should the bootwrapper create a fresh cpu node with the correct name of the CPU (e.g. "PowerPC,7455@ 0" - I guess this would require a table with all PVR values and their corresponding CPU name. Or is there a function in the kernel that do this?).

I'm far from an authoritative figure on this but making a reasonable
default (in your dts file) then updating in the bootwrapper makes sense
to me.  That's what I did for several properties in the prpmc2800's dts.

> 2. I tried to define all ISA devices, which are integrated in the southbridge (VT82C686B). Currently these are child nodes of the device tree root. Should they be child nodes of the southbridge's PCI-to-ISA device node?

I would think so.

> If so, where should I specify the register address ranges (reg property)? In the PCI device node or in the ISA device nodes, as it is now?

Each device's node should have a reg property for its registers.  You'll
need a ranges property for the pci-isa bridge as well.

Mark

P.S. You should change email clients of fix the one you're using to
     break lines up so they don't wrap in a std 80 char line window.

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Mon, 18 Jun 2007 12:15:29 -0700
Von: "Mark A. Greer" <mgreer@mvista.com>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, "list <linuxppc-dev"@ozlabs.org
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> On Mon, Jun 18, 2007 at 08:57:15PM +0200, Gerhard Pircher wrote:
> 
> > 1. The AmigaOne makes use of different G3...
> 
> I'm far from an authoritative figure on this but making a
> reasonable default (in your dts file) then updating in the 
> bootwrapper makes sense to me.  That's what I did for several 
> properties in the prpmc2800's dts.
So, the bootwrapper should update the name property of the CPU node. Is the cpu node name used somewhere?

> > If so, where should I specify the register address ranges (reg
> > property)? In the PCI device node or in the ISA device nodes,
> > as it is now?
> 
> Each device's node should have a reg property for its registers.
> You'll need a ranges property for the pci-isa bridge as well.
Ah yes, didn't think about that.

> P.S. You should change email clients of fix the one you're using
> to break lines up so they don't wrap in a std 80 char line 
> window.
Yeah, sorry. Forgot about that when writing the mail.

Gerhard
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Mark A. Greer]

On Mon, Jun 18, 2007 at 09:43:59PM +0200, Gerhard Pircher wrote:
> Von: "Mark A. Greer" <mgreer@mvista.com>
> > On Mon, Jun 18, 2007 at 08:57:15PM +0200, Gerhard Pircher wrote:
> > 
> > > 1. The AmigaOne makes use of different G3...
> > 
> > I'm far from an authoritative figure on this but making a
> > reasonable default (in your dts file) then updating in the 
> > bootwrapper makes sense to me.  That's what I did for several 
> > properties in the prpmc2800's dts.
> So, the bootwrapper should update the name property of the CPU node. Is the cpu node name used somewhere?

Oh, sorry I really talking about the cpu frequencies, etc.
I don't think the name of the cpu node matters but I'd have to check.
Others probably know off the top of their heads.

Mark

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[David Gibson]

On Mon, Jun 18, 2007 at 01:25:18PM -0700, Mark A. Greer wrote:
> On Mon, Jun 18, 2007 at 09:43:59PM +0200, Gerhard Pircher wrote:
> > Von: "Mark A. Greer" <mgreer@mvista.com>
> > > On Mon, Jun 18, 2007 at 08:57:15PM +0200, Gerhard Pircher wrote:
> > > 
> > > > 1. The AmigaOne makes use of different G3...
> > > 
> > > I'm far from an authoritative figure on this but making a
> > > reasonable default (in your dts file) then updating in the 
> > > bootwrapper makes sense to me.  That's what I did for several 
> > > properties in the prpmc2800's dts.
> > So, the bootwrapper should update the name property of the CPU node. Is the cpu node name used somewhere?
> 
> Oh, sorry I really talking about the cpu frequencies, etc.
> I don't think the name of the cpu node matters but I'd have to check.
> Others probably know off the top of their heads.

I don't believe the name is actually used.  It would be nice to get it
right, though - I think it can be considered option for the first cut,
though.

-- 
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: [RFC] Device tree for new desktop platform in arch/powerpc

[David Gibson]

On Mon, Jun 18, 2007 at 08:57:15PM +0200, Gerhard Pircher wrote:
> Hi,
> 
> I'm working on support for the AmigaOne and started to write a device tree source file for use with the cuboot bootwrapper. Additionally to the booting-without-of.txt document and other dts files I found some OpenFirmware related documents on http://playground.sun.com/1275/ and tried to follow their guidelines. Note that I didn't try to compile the dts file yet, as it is not yet complete.
> 
> Some questions arose during the implementation, which I hope some of you can answer:
> 
> 1. The AmigaOne makes use of different G3 (750Cx, 750GL, 750GX) and
> G4 (7400, 7450, 7455, 7457) CPUs. The current dts file defines a cpu
> node with the name "PowerPC,7xxx@0" and the bootwrapper just fills
> in the cpu-, bus- and timebase frequencies. Is this the recommended
> way, or should the bootwrapper create a fresh cpu node with the
> correct name of the CPU (e.g. "PowerPC,7455@ 0" - I guess this would
> require a table with all PVR values and their corresponding CPU
> name. Or is there a function in the kernel that do this?).
> 
> 2. I tried to define all ISA devices, which are integrated in the
> southbridge (VT82C686B). Currently these are child nodes of the
> device tree root. Should they be child nodes of the southbridge's
> PCI-to-ISA device node? If so, where should I specify the register
> address ranges (reg property)? In the PCI device node or in the ISA
> device nodes, as it is now?

They should be children of the PCI<->ISA bridge.  They should specify
there own address ranges in their reg properties - but those address
ranges are in the address space of the ISA bus.  The PCI<->ISA bridge
will need a correct ranges property to map that into the PCI address
space, and the PCI host bridge will need a ranges which maps that into
the processor's 

> 3. The dts files define the device_type of a serial port as
> "serial", whereas the OF spec says "pnpPNP,501". What's the
> difference between the two?

Err... device_type == "pnpPNP,501", or compatible == "pnpPNP,501"?

> 4. I couldn't find any information for a device tree representation
> of the i8259 interrupt controller in the booting-without-of.txt
> file. Is my implementation correct (inspired by the OF documents)?
> 
> I would be grateful, if you could take a look at my dts file and
> comment on every line that doesn't meet your views.

> /*
>  * AmigaOne Device Tree Source
>  *
>  * Copyright 2007 Gerhard Pircher (gerhard_pircher@gmx.net)
>  *
>  * This program is free software; you can redistribute  it and/or modify it
>  * under  the terms of  the GNU General  Public License as published by the
>  * Free Software Foundation;  either version 2 of the  License, or (at your
>  * option) any later version.
>  */

> / {
> 	model = "Eyetech,AmigaOne";
> 	compatible = "Eyetech,AmigaOne" "MAI,Teron";
> 	#address-cells = <1>;
> 	#size-cells = <1>;

> 	cpus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;

> 		PowerPC,7xxx@0 {			// Can be 75x or 745x?
> 			device_type = "cpu";
> 			reg = <0>;
> 			d-cache-line-size = <20>;	// 32 bytes
> 			i-cache-line-size = <20>;	// 32 bytes
> 			d-cache-size = <8000>;		// L1, 32K
> 			i-cache-size = <8000>;		// L1, 32K
> 			timebase-frequency = <0>;	// 33.3 MHz, from U-boot
> 			clock-frequency = <0>;		// From U-boot
> 			bus-frequency = <0>;		// From U-boot
> 			32-bit;
> 		};
> 	};

> 	memory {
> 		device_type = "memory";
> 		reg = <0 0>;				// From U-boot
> 	};

> 	// Should the following nodes be childs of a ISA bus node?

If they're ISA devices, then yes, they should.

> 	dma-controller {
> 		device_type = "dma-controller";
> 		compatible = "chrp,dma";
> 		reg = <0 10 80 10 c0 20>;
> 		/* Channel 4 reserverd, cascade mode, 2x32k transfer/counter
> 		 * widths and bus master capability. Is this really necessary?
> 		 */
> /*		dma = <4 4 20 20 1>; */
> 		#address-cells = <1>;
> 		#size-cells = <0>;			// No physical address.

This node has no children, so #address-cells and #size-cells values
are meaningless.

> 	};

>   	interrupt-controller {
> 		device_type = "interrupt-controller";
> 		compatible = "chrp,iic";

Is there a device binding defined somewhere for "chrp,iic"?

> 		interrupt-controller;
> 		reg = <20 2 a0 2 4d0 2>;
> 		reserved-interrupts = <2>;
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		#interrupt-cells = <2>;
> 	};

> 	8042@60 {
> 		device_type = "8042";
> 		compatible = "chrp,8042";
> 		reg = <60 10>;
> 		interrupts = <1 3 c 3>;			// IRQ1, IRQ12 (rising edge)
> 		interrupt-parent = <&interrupt-controller>;

This should cause a dtc error.  Either you want &/interrupt-controller
or give the interrupt-controller node a label and refer to that.  It's
either '&/some/full/path' or '&label'.

> 		#address-cells = <1>;
> 		#size-cells = <0>;			// No physical address.

Comment is arguably incorrect.

> 		keyboard {
> 			device_type = "keyboard";
> 			compatible = "pnpPNP,303";
> 			reg = <0>;
> 		};

> 		mouse {
> 			device_type = "mouse";
> 			compatible = "pnpPNP,f03";
> 			reg = <1>;
> 		};
> 	};

> 	timer@40 {
> 		device_type = "timer";

For flat device trees we're generally avoiding setting the device_type
property unless there is a clearly defined "class binding" which
applies.  There are a number of cases here where I'm not sure if
that's true.

> 		reg = <40 20>
> 		#address-cells = <1>;
> 		#size-cells = <0>;

No children, so #a and #s are pointless.

> 	};

> 	rtc@70 {
> 		device_type = "rtc";
> 		compatible = <ds1385-rtc>;
> 		reg = <70 2>;
> 		interrupts = <8 3>;
> 		#address-cells = <1>;
> 		#size-cells = <0>;

Ditto

> 	};

> 	serial@3f8 {
> 		device_type = "serial";
> /*		compatible = "pnpPNP,501";*/
> 		compatible = "ns16550";
> 		reg = <3f8 8>;
> 		interrupts = <4 3>;			// IRQ4 (rising edge)
> 		interrupt-parent = <&interrupt-controller>;
> 		clock-frequency = <0>;			// Not necessary?

Probably necessary, but may need to be filled in from the bootwrapper.

> 		#address-cells = <1>;
> 		#size-cells = <0>;

Ditto.

> 	};

> 	serial@2f8 {
> 		device_type = "serial";
> /*		compatible = "pnpPNP,501";*/
> 		compatible = "ns16550";
> 		reg = <2f8 8>;
> 		interrupts = <3 3>;			// IRQ3 (rising edge)
> 		interrupt-parent = <&interrupt-controller>;
> 		clock-frequency = <0>;			// Not necessary?
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 	};

> 	parallel@378 {
> 		device_type = "parallel";
> 		compatible = "chrp,ecp";
> 		reg = <378 3 778 3>;
> /*		interrupts = <7>;*/			// No IRQ free on AmigaOne!
> 		interrupt-parent = <&interrupt-controller>;
> /*		dma = <3 0 0 0>;*/			// Parallel port DMA mode?
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 	};

> 	fdc@3f0 {
> 		device_type = "fdc";
> 		compatible = "pnpPNP,700";
> 		reg = <3f0 8>;
> 		interrupts = <6 3>;			// IRQ6 (rising edge)
> 		interrupt-parent = <&interrupt-controller>;
> /*		dma = < >;*/				// Floppy DMA mode?
> 		#address-cells = <1>;
> 		#size-cells = <0>;

> 		disk {
> 			device_type = "block";
> 			reg = <0>;
> 		};

Don't think you need this subnode.

> 	};	

>   	pci@80000000 {
> 		device_type = "pci";
> 		bus-frequency = <01fca055>;		// 33.3MHz
> 		bus-range = <0 f>;
> 		reg = <80000000 7f000000>;			// Whole PCI space.
> 		ranges = <01000000 0 0 fe000000 0 00c00000	// PCI I/O
> 			  02000000 0 0 80000000 0 7d000000	// PCI memory
> 			  02000000 0 0 fd000000 0 01000000	// PCI alias memory
> 			  00000000 0 0 fec00000 0 00300000>;	// PCI config
> 		8259-interrupt-acknowledge = <fef00000>;
> 		#address-cells = <3>;
> 		#size-cells = <2>;
> 	};
> };


-- 
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: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

[Your "To:" header was broken...]


> 1. The AmigaOne makes use of different G3 (750Cx, 750GL, 750GX) and G4 
> (7400, 7450, 7455, 7457) CPUs. The current dts file defines a cpu node 
> with the name "PowerPC,7xxx@0" and the bootwrapper just fills in the 
> cpu-, bus- and timebase frequencies. Is this the recommended way, or 
> should the bootwrapper create a fresh cpu node with the correct name 
> of the CPU (e.g. "PowerPC,7455@ 0" - I guess this would require a 
> table with all PVR values and their corresponding CPU name. Or is 
> there a function in the kernel that do this?).

Just name the cpu nodes "cpu@0" etc.  The "generic names"
recommended practice wants this, and the node names here
aren't actually used by anything anyway, except they look
nice to the user.  The PowerPC ISA binding predates the
generic names r.p. btw.

> 2. I tried to define all ISA devices, which are integrated in the 
> southbridge (VT82C686B). Currently these are child nodes of the device 
> tree root.

This cannot work on PowerPC since PowerPC doesn't have
legacy I/O on the system bus.

> Should they be child nodes of the southbridge's PCI-to-ISA device node?

Yes.

> If so, where should I specify the register address ranges (reg 
> property)? In the PCI device node or in the ISA device nodes, as it is 
> now?

Both.  Each device has a "reg" property that describes that
device's registers relative to the addressing on the bus it
sits on.  All busses that do a direct one-to-one mapping of
some address range (perhaps with a translation) have a "ranges"
property describing that.

> 3. The dts files define the device_type of a serial port as "serial", 
> whereas the OF spec says "pnpPNP,501". What's the difference between 
> the two?

"device_type" is "serial", "compatible" is "pnpPNP,whatever".

Where in the OF specs did you find this pnpPNP thing btw?

> 4. I couldn't find any information for a device tree representation of 
> the i8259 interrupt controller in the booting-without-of.txt file. Is 
> my implementation correct (inspired by the OF documents)?

"name" = "device_type" = "interrupt-controller".
"compatible" is one of those pnpPNP things.

> I would be grateful, if you could take a look at my dts file and 
> comment on every line that doesn't meet your views.

Please send the thing inline, not as an attachment.


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>>   	interrupt-controller {
>> 		device_type = "interrupt-controller";
>> 		compatible = "chrp,iic";
>
> Is there a device binding defined somewhere for "chrp,iic"?

In the CHRP platform binding, which doesn't apply here.

>> 		keyboard {
>> 			device_type = "keyboard";
>> 			compatible = "pnpPNP,303";
>> 			reg = <0>;
>> 		};
>
>> 		mouse {
>> 			device_type = "mouse";
>> 			compatible = "pnpPNP,f03";
>> 			reg = <1>;
>> 		};
>> 	};
>
>> 	timer@40 {
>> 		device_type = "timer";
>
> For flat device trees we're generally avoiding setting the device_type
> property unless there is a clearly defined "class binding" which
> applies.  There are a number of cases here where I'm not sure if
> that's true.

Keyboard and mouse have defined "device_type"s.  Timer I
don't think so.

Either way, I'd leave out the device_type here, the OS
isn't supposed to use it anyway.

>> 	serial@3f8 {
>> 		device_type = "serial";
>> /*		compatible = "pnpPNP,501";*/
>> 		compatible = "ns16550";
>> 		reg = <3f8 8>;
>> 		interrupts = <4 3>;			// IRQ4 (rising edge)
>> 		interrupt-parent = <&interrupt-controller>;
>> 		clock-frequency = <0>;			// Not necessary?
>
> Probably necessary, but may need to be filled in from the bootwrapper.

If absent, "clock-frequency" should be taken to be the
default thing.  Actually, for pnpPNP (PC-style) serial,
the clock frequency is fixed.

>>   	pci@80000000 {
>> 		device_type = "pci";
>> 		bus-frequency = <01fca055>;		// 33.3MHz

So write it in decimal...


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 15:42:32 +1000
Von: David Gibson <david@gibson.dropbear.id.au>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, "list <linuxppc-dev"@ozlabs.org
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> > 3. The dts files define the device_type of a serial port as
> > "serial", whereas the OF spec says "pnpPNP,501". What's the
> > difference between the two?
> 
> Err... device_type == "pnpPNP,501", or compatible == "pnpPNP,501"?
Sorry, I meant compatible = "ns16550" and compatible = "pnpPNP,501".

> This node has no children, so #address-cells and #size-cells values
> are meaningless.
Ah, I thought these properties are always necessary, if a ranges or reg
property is defined.

> >   	interrupt-controller {
> > 		device_type = "interrupt-controller";
> > 		compatible = "chrp,iic";
> 
> Is there a device binding defined somewhere for "chrp,iic"?
Dunno. :-) It's based on these document here:
http://playground.sun.com/1275/bindings/devices/html/isa-pic-1_1d.html
http://playground.sun.com/1275/bindings/pci/pci2_1.pdf

> This should cause a dtc error.  Either you want &/interrupt-controller
> or give the interrupt-controller node a label and refer to that.  It's
> either '&/some/full/path' or '&label'.
That makes sense.

> > 	timer@40 {
> > 		device_type = "timer";
> 
> For flat device trees we're generally avoiding setting the device_type
> property unless there is a clearly defined "class binding" which
> applies.  There are a number of cases here where I'm not sure if
> that's true.
What about platforms that provide a real OF device tree? Do they define
device nodes for timers?

> > 		clock-frequency = <0>;			// Not necessary?
> 
> Probably necessary, but may need to be filled in from the bootwrapper.
This should be a constant anyway, so I can define it here.

> > 	fdc@3f0 {
> > 		device_type = "fdc";
> > 		compatible = "pnpPNP,700";
> > 		reg = <3f0 8>;
> > 		interrupts = <6 3>;
> > 		interrupt-parent = <&interrupt-controller>;
> > /*		dma = < >;*/
> > 		#address-cells = <1>;
> > 		#size-cells = <0>;
> >
> > 		disk {
> > 			device_type = "block";
> > 			reg = <0>;
> > 		};
> >
> Don't think you need this subnode.
It's mentioned here (if I interpreted it correctly):
http://playground.sun.com/1275/bindings/devices/html/fdc.html
Not sure, if the Linux kernel needs it.

Thanks!

regards,

Gerhard
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 08:08:42 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: ppcdev list <linuxppc-dev@ozlabs.org>
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> Just name the cpu nodes "cpu@0" etc.  The "generic names"
> recommended practice wants this, and the node names here
> aren't actually used by anything anyway, except they look
> nice to the user.  The PowerPC ISA binding predates the
> generic names r.p. btw.
Good! That simplifies the (yet to be written) amigaone-cuboot.c
bootwrapper code a lot.

> > 3. The dts files define the device_type of a serial port as "serial", 
> > whereas the OF spec says "pnpPNP,501". What's the difference between 
> > the two?
> 
> "device_type" is "serial", "compatible" is "pnpPNP,whatever".
Sorry, I was thinking about compatible = "ns16550" and
compatible = "pnp..", but wrote device_type = "serial".
What's the difference between "ns16550" and "pnpPNP,501"?

> Where in the OF specs did you find this pnpPNP thing btw?
See here:
http://playground.sun.com/1275/bindings/devices/html/serial.html

or

Quote from the document:
>  "compatible" S
> Standard property name, specifies device names with which this
> device is compatible.
> 
> The meaning of this property is as defined in Open Firmware,
> as modified by the Generic Names Recommended Practice [7]. As
> described in those documents, the entries are a list of device
> names with which this device is compatible, starting with the
> name of the device itself and progressing through successively
> less precise and possibly less functional compatible devices.
> 
> For this device, the compatible property shall include "pnpPNP,501."
- End -

> "name" = "device_type" = "interrupt-controller".
> "compatible" is one of those pnpPNP things.

Quote from the "CHRP(TM) ISA Interrupt Controller Device
Binding" document:
> "compatible" S
> Standard property name, specifies device names with which
> this device is compatible.
> ....
> The compatible property shall include "chrp,iic."
- End -

I couldn't find any reference about a "pnp..." value for an i8259
interrupt controller. Is there already a generic function within the
kernel that can setup the interrupt controller based solely on the
information in the device tree?

> Please send the thing inline, not as an attachment.
Okay, will do so next time.

Thanks!

regards,

Gerhard
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>>> 3. The dts files define the device_type of a serial port as
>>> "serial", whereas the OF spec says "pnpPNP,501". What's the
>>> difference between the two?
>>
>> Err... device_type == "pnpPNP,501", or compatible == "pnpPNP,501"?
> Sorry, I meant compatible = "ns16550" and compatible = "pnpPNP,501".

"pnpPNP,501" says that the device is a 16550A-compatible
UART compatible with how that is used in a PC (using the
same base clock, and some other minor things).

"ns16550" simply says the device is compatible with
the NS16550.  Also note the lack of "A".

>> This node has no children, so #address-cells and #size-cells values
>> are meaningless.
> Ah, I thought these properties are always necessary, if a ranges or reg
> property is defined.

They are necessary if one of the children has a "reg" or
"ranges" or similar, or if this node has a "ranges"
property.  "#xxx-cells" defines the number of cells for
the bus that this node is the controller for.  So, for
"reg", the relevant #xxx-cells entry is that in your parent;
for "ranges" you need both the "#address-cells" entry in
your parent and your own #xxx-cells values (since "ranges"
uses parent bus address, child bus address, child bus size).

>>>   	interrupt-controller {
>>> 		device_type = "interrupt-controller";
>>> 		compatible = "chrp,iic";
>>
>> Is there a device binding defined somewhere for "chrp,iic"?
> Dunno. :-) It's based on these document here:
> http://playground.sun.com/1275/bindings/devices/html/isa-pic-1_1d.html
> http://playground.sun.com/1275/bindings/pci/pci2_1.pdf

How does PCI come into the picture here?

>>> 	timer@40 {
>>> 		device_type = "timer";
>>
>> For flat device trees we're generally avoiding setting the device_type
>> property unless there is a clearly defined "class binding" which
>> applies.  There are a number of cases here where I'm not sure if
>> that's true.
> What about platforms that provide a real OF device tree? Do they define
> device nodes for timers?

Sure.  There typically is a device node for every
(addressable) device on the system.  There is no
defined binding for timer devices though, so there
shouldn't be a "device_type" in a timer node.

>>> 		clock-frequency = <0>;			// Not necessary?

Since this is an AT timer, you should use "compatible"
= "pnpPNP,100", and the clock frequency is implicit.

>>> 	fdc@3f0 {

>>> 		disk {
>>> 			device_type = "block";
>>> 			reg = <0>;
>>> 		};
>>>
>> Don't think you need this subnode.
> It's mentioned here (if I interpreted it correctly):
> http://playground.sun.com/1275/bindings/devices/html/fdc.html

"disk" subnodes describe the floppy disk _drives_ actually.
You should have a disk@0 and/or a disk@1, if you have any
floppy disk drives at all that is.

> Not sure, if the Linux kernel needs it.

The linux floppy driver will do its own probing, so no
it won't care.  Can't hurt to include it though.

In real OF these nodes are very necessary of course,
since without device node you cannot use it to read
files from.


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>> Where in the OF specs did you find this pnpPNP thing btw?
> See here:
> http://playground.sun.com/1275/bindings/devices/html/serial.html

Ah, the CHRP stuff I so happily ignore.

The generic pnpPNP thing is described in the ISA binding,
4.1.1 "name".  You should put this into "compatible"
though, since generic names are preferred.

>> "compatible" is one of those pnpPNP things.
>
> Quote from the "CHRP(TM) ISA Interrupt Controller Device
> Binding" document:

But you're not CHRP.  This is an ISA device however,
so you should follow the ISA binding.

> I couldn't find any reference about a "pnp..." value for an i8259
> interrupt controller.

pnpPNP,0 for AT-style, pnpPNP,1 for EISA-style.

It is quite hard to find a list of the standard PNP
device code.  Here's a link, grab it before the file
disappears forever:

<http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a 
-923143f3456c/devids.txt>

> Is there already a generic function within the
> kernel that can setup the interrupt controller based solely on the
> information in the device tree?

Probably not.  There are bits and pieces though, your
job is to glue it all together.  You can handle this
in your platform code, if people want to make it more
generic they can always refactor the code ;-)


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 11:14:44 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> "pnpPNP,501" says that the device is a 16550A-compatible
> UART compatible with how that is used in a PC (using the
> same base clock, and some other minor things).
> 
> "ns16550" simply says the device is compatible with
> the NS16550.  Also note the lack of "A".
I guess I can define both of them or do they conflict (IIRC
the two hardware revision should be compatible)?

> >> Is there a device binding defined somewhere for "chrp,iic"?
> > Dunno. :-) It's based on these document here:
> > http://playground.sun.com/1275/bindings/devices/html/isa-pic-1_1d.html
> > http://playground.sun.com/1275/bindings/pci/pci2_1.pdf
> 
> How does PCI come into the picture here?
I just added it, because it defines how the interrupts property
should be specfied.

> Sure.  There typically is a device node for every
> (addressable) device on the system.  There is no
> defined binding for timer devices though, so there
> shouldn't be a "device_type" in a timer node.
Okay, I'll remove the device_type property.
> >>> 		clock-frequency = <0>;			// Not necessary?
> 
> Since this is an AT timer, you should use "compatible"
> = "pnpPNP,100", and the clock frequency is implicit.
Where are all this "pnpPNP,xxx" identifiers specified (except
for serial parallel, fdc, keyboard, mouse)?

> "disk" subnodes describe the floppy disk _drives_ actually.
> You should have a disk@0 and/or a disk@1, if you have any
> floppy disk drives at all that is.
Ah yes, I may have forgotten the "@0" by mistake.

> The linux floppy driver will do its own probing, so no
> it won't care. Can't hurt to include it though.
That was my intention.

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>> "pnpPNP,501" says that the device is a 16550A-compatible
>> UART compatible with how that is used in a PC (using the
>> same base clock, and some other minor things).
>>
>> "ns16550" simply says the device is compatible with
>> the NS16550.  Also note the lack of "A".
> I guess I can define both of them or do they conflict (IIRC
> the two hardware revision should be compatible)?

Use one or the other, not both.  Perhaps you'll need
to add the pnpPNP,500 and pnpPNP,501 entries to the
generic OF serial code, should be trivial to do.

The 16550A supports something the 16550 doesn't (don't
ask me what, I forgot :-) ), so don't say it is an A
when it isn't; the other way around is fine though.

And it doesn't matter much for Linux anyway currently,
the "generic" kernel driver will do its own wacky probing.

>>> http://playground.sun.com/1275/bindings/pci/pci2_1.pdf
>>
>> How does PCI come into the picture here?
> I just added it, because it defines how the interrupts property
> should be specfied.

"interrupts" is defined by the base OF spec.  The specific
format for any interrupt domain is defined by the binding
for that domain, notably by the bindings for interrupt
controllers.

> Where are all this "pnpPNP,xxx" identifiers specified (except
> for serial parallel, fdc, keyboard, mouse)?

They are defined by the vendor of the devices; for
vendor "PNP", i.e. legacy non-PNP PC devices, that
is MicroSoft.


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 12:08:06 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, david@gibson.dropbear.id.au
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> > I guess I can define both of them or do they conflict (IIRC
> > the two hardware revision should be compatible)?
> 
> Use one or the other, not both.  Perhaps you'll need
> to add the pnpPNP,500 and pnpPNP,501 entries to the
> generic OF serial code, should be trivial to do.
I guess I stick with compatible = "serial" for now, as it should
also work with the generic serial console support code.

> The 16550A supports something the 16550 doesn't (don't
> ask me what, I forgot :-) ), so don't say it is an A
> when it isn't; the other way around is fine though.
> 
> And it doesn't matter much for Linux anyway currently,
> the "generic" kernel driver will do its own wacky probing.
Yes, that's why the current AmigaOne kernels (2.6.16) detect 3 serial
ports, whereas there should be only 2 (the first two are detected by
probing for the VIA southbridge and the last one IIRC is registered by
request_region()). I hope the device tree fixes this.

> > Where are all this "pnpPNP,xxx" identifiers specified (except
> > for serial parallel, fdc, keyboard, mouse)?
> 
> They are defined by the vendor of the devices; for
> vendor "PNP", i.e. legacy non-PNP PC devices, that
> is MicroSoft.
Downloaded the file you pointed to and the OF generic names document. I
thought the OF core specification defines them, but it's not available
freely.

Thanks a lot!

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>>> I guess I can define both of them or do they conflict (IIRC
>>> the two hardware revision should be compatible)?
>>
>> Use one or the other, not both.  Perhaps you'll need
>> to add the pnpPNP,500 and pnpPNP,501 entries to the
>> generic OF serial code, should be trivial to do.
> I guess I stick with compatible = "serial" for now, as it should
> also work with the generic serial console support code.

"compatible" = "serial" is completely wrong -- it is
a generic name and should never be matched on.

>> The 16550A supports something the 16550 doesn't (don't
>> ask me what, I forgot :-) ), so don't say it is an A
>> when it isn't; the other way around is fine though.
>>
>> And it doesn't matter much for Linux anyway currently,
>> the "generic" kernel driver will do its own wacky probing.
> Yes, that's why the current AmigaOne kernels (2.6.16) detect 3 serial
> ports, whereas there should be only 2 (the first two are detected by
> probing for the VIA southbridge and the last one IIRC is registered by
> request_region()). I hope the device tree fixes this.

It should, yes.

>>> Where are all this "pnpPNP,xxx" identifiers specified (except
>>> for serial parallel, fdc, keyboard, mouse)?
>>
>> They are defined by the vendor of the devices; for
>> vendor "PNP", i.e. legacy non-PNP PC devices, that
>> is MicroSoft.
> Downloaded the file you pointed to and the OF generic names document. I
> thought the OF core specification defines them, but it's not available
> freely.

That's a common misconception :-)

<ftp://playground.sun.com/pub/p1275/coredoc/1275-1994/1275.ps.gz>


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 15:15:33 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, david@gibson.dropbear.id.au
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> "compatible" = "serial" is completely wrong -- it is
> a generic name and should never be matched on.
Doh again! Looks like I'm absent-minded today.

> > Downloaded the file you pointed to and the OF generic names document. I
> > thought the OF core specification defines them, but it's not available
> > freely.
> 
> That's a common misconception :-)
> 
> <ftp://playground.sun.com/pub/p1275/coredoc/1275-1994/1275.ps.gz>
So much for "available commercially". :-) Thanks!

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Benjamin Herrenschmidt]

> 2. I tried to define all ISA devices, which are integrated in the
> southbridge (VT82C686B). Currently these are child nodes of the device
> tree root. Should they be child nodes of the southbridge's PCI-to-ISA
> device node? If so, where should I specify the register address ranges
> (reg property)? In the PCI device node or in the ISA device nodes, as
> it is now?

You should have /pci/isa <--- this is the PCI2ISA bridge

and the ISA devices below that. Best is I send you an example of a CHRP
or pSeries devie-tree with ISA stuff on it tomorrow. Ping me if I
forget.

> 3. The dts files define the device_type of a serial port as "serial",
> whereas the OF spec says "pnpPNP,501". What's the difference between
> the two?

Use the pnp stuff for "compatible", you can mostly ignore device_type or
set it to the same as name.

> 4. I couldn't find any information for a device tree representation of
> the i8259 interrupt controller in the booting-without-of.txt file. Is
> my implementation correct (inspired by the OF documents)?

Haven't looked at your .dts yet but it should be "interrupt-controller",
compatible "chrp,iic" or "i8259", with a #interrupt-cells of 2 and
interrupts following the standard ISA encoding. You probably also want
an interrupt-parent property in the isa bridge node pointing back to the
8259 so it becomes the default for all ISA devices.

> I would be grateful, if you could take a look at my dts file and
> comment on every line that doesn't meet your views.

Will do as soon as I find some time...

Ben.

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Benjamin Herrenschmidt]

On Tue, 2007-06-19 at 15:42 +1000, David Gibson wrote:
> 
> Is there a device binding defined somewhere for "chrp,iic"?

Yes, it's the standard for 8259 on chrp and chrp-like platforms.

> >               interrupt-controller;
> >               reg = <20 2 a0 2 4d0 2>;
> >               reserved-interrupts = <2>;

I'm currious about the above though, what is it ?

> >               #address-cells = <1>;

Why #address-cells set to 1 ? In a PIC node, in fact, I would expect it
to be 0 to avoid any spurrious "reg" matching for interrupts.

> >               #size-cells = <0>;
> >               #interrupt-cells = <2>;
> >       };
> 
> >       8042@60 {
> >               device_type = "8042";
> >               compatible = "chrp,8042";
> >               reg = <60 10>;
> >               interrupts = <1 3 c 3>;                 // IRQ1, IRQ12
> (rising edge)
> >               interrupt-parent = <&interrupt-controller>;

Just put the interrupt-parent pointer once in the isa bridge and all isa
devices below the bridge.

> This should cause a dtc error.  Either you want &/interrupt-controller
> or give the interrupt-controller node a label and refer to that.  It's
> either '&/some/full/path' or '&label'.
> 
> >               #address-cells = <1>;
> >               #size-cells = <0>;                      // No physical
> address.
> 
> Comment is arguably incorrect.

Yeah, not sure what that is supposed to be.

Ben.

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Thu, 21 Jun 2007 22:36:46 +1000
Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, list <linuxppc-dev@ozlabs.org>
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> You should have /pci/isa <--- this is the PCI2ISA bridge
> 
> and the ISA devices below that. Best is I send you an example of a CHRP
> or pSeries devie-tree with ISA stuff on it tomorrow. Ping me if I
> forget.
That would help a lot. Thank you!

> Haven't looked at your .dts yet but it should be "interrupt-controller",
> compatible "chrp,iic" or "i8259", with a #interrupt-cells of 2 and
> interrupts following the standard ISA encoding. You probably also want
> an interrupt-parent property in the isa bridge node pointing back to the
> 8259 so it becomes the default for all ISA devices.
What about PCI devices? Wouldn't it better to define the interrupt-parent property in the PCI bus node?

Gerhard
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Thu, 21 Jun 2007 22:42:13 +1000
Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
An: David Gibson <david@gibson.dropbear.id.au>
CC: Gerhard Pircher <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org, list <linuxppc-dev@ozlabs.org>
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> > >               interrupt-controller;
> > >               reg = <20 2 a0 2 4d0 2>;
> > >               reserved-interrupts = <2>;
> 
> I'm currious about the above though, what is it ?

Quote from the CHRP ISA interrupt controller device binding document:
“reserved-interrupts”
Standard property name to define reserved interrupts.
prop-encoded-array: An integer array, encoded with encode-int.
The value of this property shall be a list of ISA interrupts which cannot
be assigned due to cascading, wiring, or other reasons. Only the irq# part
of the property is pertinent to this use.
- End -

> > >               #address-cells = <1>;
> 
> Why #address-cells set to 1 ? In a PIC node, in fact, I would expect it
> to be 0 to avoid any spurrious "reg" matching for interrupts.
Yeah, I got them wrong almost everywhere.

regards,

Gerhard
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>> 3. The dts files define the device_type of a serial port as "serial",
>> whereas the OF spec says "pnpPNP,501". What's the difference between
>> the two?
>
> Use the pnp stuff for "compatible", you can mostly ignore device_type 
> or
> set it to the same as name.

Only if the name is indeed the correct, defined, device_type
for that device, and you implement the whole binding for that
device_type (I recommend you do, for serial; it makes it
easier to use that device as an early console).

>> 4. I couldn't find any information for a device tree representation of
>> the i8259 interrupt controller in the booting-without-of.txt file. Is
>> my implementation correct (inspired by the OF documents)?
>
> Haven't looked at your .dts yet but it should be 
> "interrupt-controller",
> compatible "chrp,iic" or "i8259", with a #interrupt-cells of 2 and
> interrupts following the standard ISA encoding. You probably also want
> an interrupt-parent property in the isa bridge node pointing back to 
> the
> 8259 so it becomes the default for all ISA devices.

Yeah.  You can also use the "pnpPNP," name for the 8259 if
it is hooked up like on a PC.

>> I would be grateful, if you could take a look at my dts file and
>> comment on every line that doesn't meet your views.

Please send a new .dts based on the comments you've had so far?


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>>>               #address-cells = <1>;
>
> Why #address-cells set to 1 ? In a PIC node, in fact, I would expect it
> to be 0 to avoid any spurrious "reg" matching for interrupts.

The "#address-cells" property should be completely absent,
even; for interrupt matching, that means "treat as 0, no
unit address used in interrupt mapping, just the interrupt
number", and for the "normal" purpose (defining the format
of devices on the bus rooted at / represented by this node)
it means "there is no such bus" -- this is different from
#address-cells = 0.

> Just put the interrupt-parent pointer once in the isa bridge and all 
> isa
> devices below the bridge.

Definitely.

>>>               #address-cells = <1>;
>>>               #size-cells = <0>;                      // No physical
>> address.
>>
>> Comment is arguably incorrect.
>
> Yeah, not sure what that is supposed to be.

#size-cells = 0 means the addressing scheme on this bus is
not directly related to the mechanism (if any) by which
registers on a device on the bus are addressed.


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>> You probably also want
>> an interrupt-parent property in the isa bridge node pointing back to 
>> the
>> 8259 so it becomes the default for all ISA devices.
> What about PCI devices? Wouldn't it better to define the 
> interrupt-parent property in the PCI bus node?

Devices on an ISA bus have their interrupts encoded according
to the ISA bus binding; this is exactly the format that the
ISA interrupt controller (the 8259) expects, so by setting
the interrupt-parent on the bus node to point to the 8259 (and
not doing interrupt mapping in the ISA child nodes) all works
exactly as planned.

Devices on a PCI bus have their interrupts encoded according
to the PCI bus binding; this is a very much different format
so you better have a real mapping (probably in the PCI host
bridge) translating it to ISA interrupts (and pointing it there),
if that's how the interrupts are routed on your box.

I hope this helps, it's a bit hard to explain without whiteboard :-)


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>>>>               reserved-interrupts =3D <2>;
>>
>> I'm currious about the above though, what is it ?
>
> Quote from the CHRP ISA interrupt controller device binding document:
> =93reserved-interrupts=94
> Standard property name to define reserved interrupts.
> prop-encoded-array: An integer array, encoded with encode-int.
> The value of this property shall be a list of ISA interrupts which=20
> cannot
> be assigned due to cascading, wiring, or other reasons. Only the irq#=20=

> part
> of the property is pertinent to this use.

I never found any situation where this property is useful
(you need a lot more information to do anything but static
IRQ routing on ISA anyway), but it doesn't harm anything
either.


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Thu, 21 Jun 2007 16:24:17 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Gerhard Pircher <gerhard_pircher@gmx.net>, list <linuxppc-dev@ozlabs.org>
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> Yeah.  You can also use the "pnpPNP," name for the 8259 if
> it is hooked up like on a PC.
Yes, it is hooked up like on a PC (or on the Pegasos 1).

> Please send a new .dts based on the comments you've had so far?
Yes, I'll do so.

Gerhard
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Thu, 21 Jun 2007 16:38:49 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, Benjamin Herrenschmidt <benh@kernel.crashing.org>
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> Devices on a PCI bus have their interrupts encoded according
> to the PCI bus binding; this is a very much different format
> so you better have a real mapping (probably in the PCI host
> bridge) translating it to ISA interrupts (and pointing it there),
> if that's how the interrupts are routed on your box.
Ah, right. I have already seen that in a dts file, but didn't remember it.

> I hope this helps, it's a bit hard to explain without whiteboard :-)
For sure it helps!

Gerhard
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Benjamin Herrenschmidt]

> > Haven't looked at your .dts yet but it should be "interrupt-controller",
> > compatible "chrp,iic" or "i8259", with a #interrupt-cells of 2 and
> > interrupts following the standard ISA encoding. You probably also want
> > an interrupt-parent property in the isa bridge node pointing back to the
> > 8259 so it becomes the default for all ISA devices.

> What about PCI devices? Wouldn't it better to define the interrupt-parent property in the PCI bus node?

PCI devices generally have their interrupts specified by an
interrupt-map in the PCI bridge.

Do you have the recommended practice "interrupt mapping" standard ?

It also allowed to make it optional to have nodes for the PCI devices in
slots, you can provide the mapping of all 4 INT# lines in the bridge
node and linux can use it when probing for devices, so your bootwrapper
doesn't have to know what's in the slots and doesn't have to create
device nodes for those.

Ben.

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Benjamin Herrenschmidt]

> The "#address-cells" property should be completely absent,
> even; for interrupt matching, that means "treat as 0, no
> unit address used in interrupt mapping, just the interrupt
> number", and for the "normal" purpose (defining the format
> of devices on the bus rooted at / represented by this node)
> it means "there is no such bus" -- this is different from
> #address-cells = 0.

I'd rather have it present and explicitely set to 0, which happens to be
what both Apple and IBM OF implementations also do. Have you verified if
the linux parser behaves properly if it's absent ?

Ben.

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>> The "#address-cells" property should be completely absent,
>> even; for interrupt matching, that means "treat as 0, no
>> unit address used in interrupt mapping, just the interrupt
>> number", and for the "normal" purpose (defining the format
>> of devices on the bus rooted at / represented by this node)
>> it means "there is no such bus" -- this is different from
>> #address-cells = 0.
>
> I'd rather have it present and explicitely set to 0,

It is not the "right thing" to do, but should be harmless
in most situations.

> which happens to be
> what both Apple and IBM OF implementations also do. Have you verified 
> if
> the linux parser behaves properly if it's absent ?

No, I haven't.  I prefer following the standard instead of simply
making the code work with one or two implementations; I hope
you did the same :-)

If it doesn't work, it's simply a bug in Linux.


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Benjamin Herrenschmidt]

On Fri, 2007-06-22 at 09:52 +0200, Segher Boessenkool wrote:
> >> The "#address-cells" property should be completely absent,
> >> even; for interrupt matching, that means "treat as 0, no
> >> unit address used in interrupt mapping, just the interrupt
> >> number", and for the "normal" purpose (defining the format
> >> of devices on the bus rooted at / represented by this node)
> >> it means "there is no such bus" -- this is different from
> >> #address-cells = 0.
> >
> > I'd rather have it present and explicitely set to 0,
> 
> It is not the "right thing" to do, but should be harmless
> in most situations.

It's pretty much the right thing to do in that case imho... based on the
assumption that a common practice is worth 10 standards :-)

(I think I could even quote Linus on that one, let's just say that I
totally agree with him on those matters, I'd rather have people
"standardize" around existing common practices that happen to also work
well with existing code rather than doing differently because that's
what a 10 yrs old unmaintained piece of pdf says should be done :-)

Ben.

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Segher Boessenkool]

>>>> The "#address-cells" property should be completely absent,
>>>> even; for interrupt matching, that means "treat as 0, no
>>>> unit address used in interrupt mapping, just the interrupt
>>>> number", and for the "normal" purpose (defining the format
>>>> of devices on the bus rooted at / represented by this node)
>>>> it means "there is no such bus" -- this is different from
>>>> #address-cells = 0.
>>>
>>> I'd rather have it present and explicitely set to 0,
>>
>> It is not the "right thing" to do, but should be harmless
>> in most situations.
>
> It's pretty much the right thing to do in that case imho... based on 
> the
> assumption that a common practice is worth 10 standards :-)

It is of course "defensive programming", in that a device
tree like that also works with badly broken OS code.

So perhaps we should indeed recommend this for Linux flat
device trees.

Which is not to say that the Linux parsing code shouldn't
be fixed (if it is broken at all, who knows).

> (I think I could even quote Linus on that one, let's just say that I
> totally agree with him on those matters, I'd rather have people
> "standardize" around existing common practices that happen to also work
> well with existing code rather than doing differently because that's
> what a 10 yrs old unmaintained piece of pdf says should be done :-)

OTOH, you need a few people doing the "interesting" cases,
so you can find and fix the flaws in your OS code :-)


Segher

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Fri, 22 Jun 2007 09:22:49 +1000
Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc

> Do you have the recommended practice "interrupt mapping" standard ?
Yes, downloaded it right now.

> It also allowed to make it optional to have nodes for the PCI devices in
> slots, you can provide the mapping of all 4 INT# lines in the bridge
> node and linux can use it when probing for devices, so your bootwrapper
> doesn't have to know what's in the slots and doesn't have to create
> device nodes for those.
I would like to have PCI nodes only for the PCI host and PCI2ISA bridge.
The interrupt mapping of the INT# lines can be configured within U-boot,
thus I would avoid to specify it somewhere in the device tree, if it isn't
really necessary.

Gerhard
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [RFC] Device tree for new desktop platform in arch/powerpc

[Benjamin Herrenschmidt]

On Fri, 2007-06-22 at 15:12 +0200, Gerhard Pircher wrote:
> I would like to have PCI nodes only for the PCI host and PCI2ISA
> bridge.
> The interrupt mapping of the INT# lines can be configured within
> U-boot,
> thus I would avoid to specify it somewhere in the device tree, if it
> isn't
> really necessary.

You still need to provide the IRQ mapping for the PCI slots, but you can
do that from the interrupt-map property of the PCI host bridge node.

Ben.