[RFC] AmigaOne device tree source v2

[RFC] AmigaOne device tree source v2

[Gerhard Pircher]

Hi,

I updated the AmigaOne device tree based on the comments in this thread:
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038069.html
All the ISA devices are now subnodes of the PCI2ISA bridge, which marks
the first 64k (of PCI address space) as I/O space. The pci node doesn't
contain any interrupt routing information, because interrupt routing
differs between the three AmigaOne models. Thus I would like to omit it,
if it is not really necessary. The PCI host for bus 0 is a subnode of
the pci node, but I'm not sure if this is correct.

Please take a look at the reg and ranges properties of the PCI devices.
The PCI OF spec defined "zero" reg properties (like
reg = <00xxxx00 00000000 00000000 00000000 00000000>, where xxxx is
the device number), even if all the other BARs are defined. What are
they good for?
The BARs of the VIA IDE controller are assumed to be relocateable,
even if the address is fixed in compatibility mode.
BTW: Is there a way to specify the addresses for PCI config with
indirect addressing?

Thanks!

regards,

Gerhard


/*
 * 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>;

		cpu@0 {
			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
	};

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

		host@0 {
			vendor-id = 0x000010cc;
			device-id = 0x00000660;
			revision-id = 0x00000001;
			class-code = 0x00060000;
			subsystem-id = 0x00000000;
			subsystem-vendor-id = 0x00000000;
			devsel-speed = 0x00000001;
			66mhz-capable;
			min-grant = 0x00000000;
			max-latency = 0x00000000;
			// AGP aperture is unset.
			reg = <42000010 0 00000000 0 00400000>;
			assigned-addresses = <42000010 0 00000000 0 00400000>;
		}

		isa@7 {
			device_type = "isa";
			vendor-id = 0x00001106;
			device-id = 0x00000686;
			revision-id = 0x00000010;
			class-code = 0x00060100;
			subsystem-id = 0x00000000;
			subsystem-vendor-id = 0x00000000;
			devsel-speed = 0x00000001;
			min-grant = 0x00000000;
			max-latency = 0x00000000;
			/* First 64k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */
			ranges = <00000001 0 01000000 0 00000000 00010000>;
			interrupt-parent = <&/pci@80000000/isa@7/interrupt-controller>;
			#interrupt-cells = <2>;
			#address-cells = <2>;
			#size-cells = <1>;

			dma-controller {
				device_type = "dma-controller";
				compatible = "pnpPNP,200";
				reg = <00000001 00000000 00000010
				       00000001 00000080 00000010
				       00000001 000000c0 00000020>;
				/* Channel 4 reserverd, cascade mode, 2x32k transfer/counter
				 * widths and bus master capability. Is this really necessary?
				 */
/*				dma = <4 4 20 20 1>; */
			};

		  	interrupt-controller {
				device_type = "interrupt-controller";
				compatible = "pnpPNP,000";
				interrupt-controller;
				reg = <00000001 00000020 00000002
				       00000001 000000a0 00000002
				       00000001 000004d0 00000002>;
				reserved-interrupts = <2>;	
			};

			8042@60 {
				device_type = "8042";
				compatible = "pnpPNP,303";
				reg = <00000001 00000060 00000010>;
				interrupts = <1 3 c 3>;			// IRQ1, IRQ12 (rising edge)

				keyboard {
					device_type = "keyboard";
					compatible = "pnpPNP,303";	// Here again?
					reg = <0 0 0>;
				};

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

			timer@40 {
/*				device_type = "timer"; */		// No device type binding for now.
				compatibe = "pnpPNP,100";		// Also add pcspkr to platform devices.
				reg = <00000001 00000040 00000020>;
			};

			rtc@70 {
				device_type = "rtc";
				compatible = "pnpPNP,b00";		// <ds1385-rtc>; // What should be used here?
				reg = <00000001 00000070 00000002>;
				interrupts = <8 3>;
			};

			serial@2f8 {
				device_type = "serial";
				compatible = "pnpPNP,501" "pnpPNP,500";	// "ns16550"; add property check to OF serial code.
				reg = <00000001 000002f8 00000008>;
				interrupts = <3 3>;			// IRQ3 (rising edge)
				clock-frequency = <0>;			// Not necessary?
			};

			serial@3f8 {
				device_type = "serial";
				compatible = "pnpPNP,501" "pnpPNP,500";	// "ns16550"; add property check to OF serial code.
				reg = <00000001 000003f8 00000008>;
				interrupts = <4 3>;			// IRQ4 (rising edge)
				clock-frequency = <0>;			// Not necessary?
			};

			parallel@378 {
				device_type = "parallel";
				compatible = "pnpPNP,400"; 		// "pnpPNP,401"	// No ECP support for now.
				reg = <00000001 00000378 00000003
				       00000001 00000778 00000003>;
/*				interrupts = <7>; */			// No IRQ free on AmigaOne!
/*				dma = <3 0 0 0>; */			// Parallel port DMA mode?
			};

			fdc@3f0 {
				device_type = "fdc";
				compatible = "pnpPNP,700";
				reg = <00000001 000003f0 00000008>;
				interrupts = <6 3>;			// IRQ6 (rising edge)
/*				dma = < >; */				// Floppy DMA mode?

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

		ide@7,1 {
			// Is there a device_type defined for IDE controllers?
			vendor-id = 0x00001106;
			device-id  = 0x00000571;
			revision-id = 0x00000006;
			// Class code with PCI IDE programming interface indicator.
			class-code = 0x0001018f;
			subsystem-id = 0;
			subsystem-vendor-id = 0;
			devsel-speed = 0x00000001;
			min-grant = 0;
			max-latency = 0;
			fast-back-to-back;
			// Assume base addresses are relocateable, even if
			// controller operates in compatibility mode. Right?
			reg = <21003910 0 00000000 0 00000000
			       21003914 0 00000000 0 00000000
			       21003918 0 00000000 0 00000000
			       2100391c 0 00000000 0 00000000
			       21003920 0 00000000 0 00000000>;
			assigned-addresses = <01003910 0 000001f0 0 00000008
					      01003914 0 000003f4 0 00000004
					      01003918 0 00000170 0 00000008
					      0100391c 0 00000374 0 00000004
					      01003920 0 0000cc00 0 00000010>;
	};

	chosen {
		linux,stdout-path = "/pci@80000000/isa@7/serial@2f8";
	};
};

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

Re: [RFC] AmigaOne device tree source v2

[David Gibson]

On Fri, Aug 31, 2007 at 07:50:06PM +0200, Gerhard Pircher wrote:
> Hi,
> 
> I updated the AmigaOne device tree based on the comments in this thread:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038069.html
> All the ISA devices are now subnodes of the PCI2ISA bridge, which marks
> the first 64k (of PCI address space) as I/O space. The pci node doesn't
> contain any interrupt routing information, because interrupt routing
> differs between the three AmigaOne models. Thus I would like to omit it,
> if it is not really necessary. 

Interrupt routing information is really necessary.  If it differs
between the models then either you will need different device tree
source for each of them, or you will need to fill in the correct
interrupt routing information from the bootwrapper, whichever approach
is easier.

> The PCI host for bus 0 is a subnode of
> the pci node, but I'm not sure if this is correct.
> 
> Please take a look at the reg and ranges properties of the PCI devices.
> The PCI OF spec defined "zero" reg properties (like
> reg = <00xxxx00 00000000 00000000 00000000 00000000>, where xxxx is
> the device number), even if all the other BARs are defined. What are
> they good for?
> The BARs of the VIA IDE controller are assumed to be relocateable,
> even if the address is fixed in compatibility mode.
> BTW: Is there a way to specify the addresses for PCI config with
> indirect addressing?

I believe that's handled by the bridge's compatible and reg
properties.  The platform or bridge code will have to know that this
type of bridge (as encoded in compatible) uses indirect addressing,
and which resource (from the reg property) has the indirect access
registers.

I don't know enough about PCI to answer most of the above questions,
but I spotted a bunch of problems with the device tree anyway...
> /*
>  * 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>;
> 
> 		cpu@0 {
> 			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
> 	};
> 
>   	pci@80000000 {
> 		device_type = "pci";
> 		bus-frequency = <01fca055>;		// 33.3MHz
> 		bus-range = <0 1>;
> 		reg = <80000000 7f000000>;				// Whole PCI space.

'reg' and 'ranges' should not typically overlap.  'reg' should only
encode control registers for the bridge, not the whole PCI space (not
that I'm even entirely sure what you mean by that).

> 		ranges = <01000000 0 00000000 fe000000 0 00c00000	// PCI I/O
> 			  02000000 0 80000000 80000000 0 7d000000	// PCI memory
> 			  02000000 0 fd000000 fd000000 0 01000000>;	// PCI alias memory
> 		8259-interrupt-acknowledge = <fef00000>;
> 		#address-cells = <3>;
> 		#size-cells = <2>;
> 
> 		host@0 {

The unit address (after the @) should be derived from the first range
listed in the 'reg' property.  It's a bus address, not a slot number.

> 			vendor-id = 0x000010cc;

Um.. evidentally you have never even tried compiling this device tree,
since this is invalid syntax.  That would need to be:
			vendor-id = <000010cc>;
and likewise all the others below.

> 			device-id = 0x00000660;
> 			revision-id = 0x00000001;
> 			class-code = 0x00060000;
> 			subsystem-id = 0x00000000;
> 			subsystem-vendor-id = 0x00000000;
> 			devsel-speed = 0x00000001;
> 			66mhz-capable;
> 			min-grant = 0x00000000;
> 			max-latency = 0x00000000;
> 			// AGP aperture is unset.
> 			reg = <42000010 0 00000000 0 00400000>;
> 			assigned-addresses = <42000010 0 00000000 0 00400000>;
> 		}
> 
> 		isa@7 {
> 			device_type = "isa";
> 			vendor-id = 0x00001106;
> 			device-id = 0x00000686;
> 			revision-id = 0x00000010;
> 			class-code = 0x00060100;
> 			subsystem-id = 0x00000000;
> 			subsystem-vendor-id = 0x00000000;
> 			devsel-speed = 0x00000001;
> 			min-grant = 0x00000000;
> 			max-latency = 0x00000000;
> 			/* First 64k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */
> 			ranges = <00000001 0 01000000 0 00000000 00010000>;
> 			interrupt-parent = <&/pci@80000000/isa@7/interrupt-controller>;

Probably worth using a label on the interrupt node to avoid giving a
full path here.

> 			#interrupt-cells = <2>;
> 			#address-cells = <2>;
> 			#size-cells = <1>;
> 
> 			dma-controller {

All these devices should have unit addresses.

> 				device_type = "dma-controller";
> 				compatible = "pnpPNP,200";
> 				reg = <00000001 00000000 00000010
> 				       00000001 00000080 00000010
> 				       00000001 000000c0 00000020>;
> 				/* Channel 4 reserverd, cascade mode, 2x32k transfer/counter
> 				 * widths and bus master capability. Is this really necessary?
> 				 */
> /*				dma = <4 4 20 20 1>; */
> 			};
> 
> 		  	interrupt-controller {
> 				device_type = "interrupt-controller";
> 				compatible = "pnpPNP,000";
> 				interrupt-controller;
> 				reg = <00000001 00000020 00000002
> 				       00000001 000000a0 00000002
> 				       00000001 000004d0 00000002>;
> 				reserved-interrupts = <2>;	
> 			};
> 
> 			8042@60 {
> 				device_type = "8042";
> 				compatible = "pnpPNP,303";
> 				reg = <00000001 00000060 00000010>;
> 				interrupts = <1 3 c 3>;			// IRQ1, IRQ12 (rising edge)
> 
> 				keyboard {
> 					device_type = "keyboard";
> 					compatible = "pnpPNP,303";	// Here again?
> 					reg = <0 0 0>;
> 				};
> 
> 				mouse {
> 					device_type = "mouse";
> 					compatible = "pnpPNP,f03";
> 					reg = <0 0 0>;
> 				};
> 			};
> 
> 			timer@40 {
> /*				device_type = "timer"; */		// No device type binding for now.
> 				compatibe = "pnpPNP,100";		// Also add pcspkr to platform devices.
> 				reg = <00000001 00000040 00000020>;
> 			};
> 
> 			rtc@70 {
> 				device_type = "rtc";
> 				compatible = "pnpPNP,b00";		// <ds1385-rtc>; // What should be used here?
> 				reg = <00000001 00000070 00000002>;
> 				interrupts = <8 3>;
> 			};
> 
> 			serial@2f8 {
> 				device_type = "serial";
> 				compatible = "pnpPNP,501" "pnpPNP,500";	// "ns16550"; add property check to OF serial code.
> 				reg = <00000001 000002f8 00000008>;
> 				interrupts = <3 3>;			// IRQ3 (rising edge)
> 				clock-frequency = <0>;			// Not necessary?
> 			};
> 
> 			serial@3f8 {
> 				device_type = "serial";
> 				compatible = "pnpPNP,501" "pnpPNP,500";	// "ns16550"; add property check to OF serial code.
> 				reg = <00000001 000003f8 00000008>;
> 				interrupts = <4 3>;			// IRQ4 (rising edge)
> 				clock-frequency = <0>;			// Not necessary?
> 			};
> 
> 			parallel@378 {
> 				device_type = "parallel";
> 				compatible = "pnpPNP,400"; 		// "pnpPNP,401"	// No ECP support for now.
> 				reg = <00000001 00000378 00000003
> 				       00000001 00000778 00000003>;
> /*				interrupts = <7>; */			// No IRQ free on AmigaOne!
> /*				dma = <3 0 0 0>; */			// Parallel port DMA mode?
> 			};
> 
> 			fdc@3f0 {
> 				device_type = "fdc";
> 				compatible = "pnpPNP,700";
> 				reg = <00000001 000003f0 00000008>;
> 				interrupts = <6 3>;			// IRQ6 (rising edge)
> /*				dma = < >; */				// Floppy DMA mode?
> 
> 				disk@0 {
> 					device_type = "block";
> 					reg = <0 0 0>;
> 				};
> 			};
> 		};
> 
> 		ide@7,1 {

This will need a compatible property, at least.

> 			// Is there a device_type defined for IDE controllers?
> 			vendor-id = 0x00001106;
> 			device-id  = 0x00000571;
> 			revision-id = 0x00000006;
> 			// Class code with PCI IDE programming interface indicator.
> 			class-code = 0x0001018f;
> 			subsystem-id = 0;
> 			subsystem-vendor-id = 0;
> 			devsel-speed = 0x00000001;
> 			min-grant = 0;
> 			max-latency = 0;
> 			fast-back-to-back;
> 			// Assume base addresses are relocateable, even if
> 			// controller operates in compatibility mode. Right?
> 			reg = <21003910 0 00000000 0 00000000
> 			       21003914 0 00000000 0 00000000
> 			       21003918 0 00000000 0 00000000
> 			       2100391c 0 00000000 0 00000000
> 			       21003920 0 00000000 0 00000000>;
> 			assigned-addresses = <01003910 0 000001f0 0 00000008
> 					      01003914 0 000003f4 0 00000004
> 					      01003918 0 00000170 0 00000008
> 					      0100391c 0 00000374 0 00000004
> 					      01003920 0 0000cc00 0 00000010>;
> 	};
> 
> 	chosen {
> 		linux,stdout-path = "/pci@80000000/isa@7/serial@2f8";
> 	};
> };
> 

-- 
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] AmigaOne device tree source v2

[Benjamin Herrenschmidt]

> 'reg' and 'ranges' should not typically overlap.  'reg' should only
> encode control registers for the bridge, not the whole PCI space (not
> that I'm even entirely sure what you mean by that).
> 
> > 		ranges = <01000000 0 00000000 fe000000 0 00c00000	// PCI I/O
> > 			  02000000 0 80000000 80000000 0 7d000000	// PCI memory
> > 			  02000000 0 fd000000 fd000000 0 01000000>;	// PCI alias memory
> > 		8259-interrupt-acknowledge = <fef00000>;
> > 		#address-cells = <3>;
> > 		#size-cells = <2>;
> > 
> > 		host@0 {
> 
> The unit address (after the @) should be derived from the first range
> listed in the 'reg' property.  It's a bus address, not a slot number.

Actually... on PCI, the unit address is often the slot number, or
rather, "slot,function" with the second part ommited for non
multifunction devices.

> All these devices should have unit addresses.

 ... which for ISA are generally in the form iPORT (8242@i60 for
example) though I've seen the "i" ommited. Not terribly important I
would say but better to follow the spec.

> > 		ide@7,1 {
> 
> This will need a compatible property, at least.

Actually, it's a PCI device, it can have a compatible property based on
the generic PCI device compatible property generation as defined in the
OF PCI binding. Since that's just derived from other fields, I suppose
it can be omitted in a flat DT. It would be -nice- to have a more
explicit cpmpatible property but in that case, not absolutely necessary
since that device will be probed as PCI anyway.

Ben.

Re: [RFC] AmigaOne device tree source v2

[Segher Boessenkool]

>>> 		host@0 {
>>
>> The unit address (after the @) should be derived from the first range
>> listed in the 'reg' property.  It's a bus address, not a slot number.
>
> Actually... on PCI, the unit address is often the slot number, or
> rather, "slot,function" with the second part ommited for non
> multifunction devices.

Not slot number, but "device-id".  Like, if you have actual
PCI plugin slots on your board, they likely have device ids
16,17,...; but slot numbers 1, 2, 3 (little labels on the box).

David's point is that unit addresses are not random numbers.

>> All these devices should have unit addresses.
>
>  ... which for ISA are generally in the form iPORT (8242@i60 for
> example) though I've seen the "i" ommited. Not terribly important I
> would say but better to follow the spec.

Omitting the "i" is perfectly in line with the spec :-)

>>> 		ide@7,1 {
>>
>> This will need a compatible property, at least.
>
> Actually, it's a PCI device, it can have a compatible property based on
> the generic PCI device compatible property generation as defined in the
> OF PCI binding. Since that's just derived from other fields, I suppose
> it can be omitted in a flat DT. It would be -nice- to have a more
> explicit cpmpatible property but in that case, not absolutely necessary
> since that device will be probed as PCI anyway.

Yeah, PCI is a special case for Linux.  Maybe add a "pciclass,XXXX"
compatible property though, for good measure.  Anything else isn't
all that useful I think.


Segher

Re: [RFC] AmigaOne device tree source v2

[David Gibson]

On Mon, Sep 03, 2007 at 12:02:58PM +0200, Segher Boessenkool wrote:
> >>> 		host@0 {
> >>
> >> The unit address (after the @) should be derived from the first range
> >> listed in the 'reg' property.  It's a bus address, not a slot number.
> >
> > Actually... on PCI, the unit address is often the slot number, or
> > rather, "slot,function" with the second part ommited for non
> > multifunction devices.
> 
> Not slot number, but "device-id".  Like, if you have actual
> PCI plugin slots on your board, they likely have device ids
> 16,17,...; but slot numbers 1, 2, 3 (little labels on the box).
> 
> David's point is that unit addresses are not random numbers.

You flatter me.  But i'll happily make that point, now that my
ignorance is slightly alleviated ;-).

> >> All these devices should have unit addresses.
> >
> >  ... which for ISA are generally in the form iPORT (8242@i60 for
> > example) though I've seen the "i" ommited. Not terribly important I
> > would say but better to follow the spec.
> 
> Omitting the "i" is perfectly in line with the spec :-)
> 
> >>> 		ide@7,1 {
> >>
> >> This will need a compatible property, at least.
> >
> > Actually, it's a PCI device, it can have a compatible property based on
> > the generic PCI device compatible property generation as defined in the
> > OF PCI binding. Since that's just derived from other fields, I suppose
> > it can be omitted in a flat DT. It would be -nice- to have a more
> > explicit cpmpatible property but in that case, not absolutely necessary
> > since that device will be probed as PCI anyway.
> 
> Yeah, PCI is a special case for Linux.  Maybe add a "pciclass,XXXX"
> compatible property though, for good measure.  Anything else isn't
> all that useful I think.

Indeed, since PCI is probable, it's unclear whether these device nodes
are even necessary at all.  Depends on whether there's anything
interesting in the omitted interrupt routing information.

-- 
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] AmigaOne device tree source v2

[Gerhard Pircher]

Hi,

-------- Original-Nachricht --------
> Datum: Mon, 3 Sep 2007 11:34:31 +1000
> Von: David Gibson <david@gibson.dropbear.id.au>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: [RFC] AmigaOne device tree source v2

> Interrupt routing information is really necessary.  If it differs
> between the models then either you will need different device tree
> source for each of them, or you will need to fill in the correct
> interrupt routing information from the bootwrapper, whichever approach
> is easier.
Okay, I could probe the southbridge's PCI interrupt registers to fill in
some of the interrupt routing information from the bootwrapper.

> I believe that's handled by the bridge's compatible and reg
> properties.  The platform or bridge code will have to know that this
> type of bridge (as encoded in compatible) uses indirect addressing,
> and which resource (from the reg property) has the indirect access
> registers.
Well, then I'll copy and paste from the CHRP/Pegasos PCI setup code,
which should exactly do that. :-)

> I don't know enough about PCI to answer most of the above questions,
> but I spotted a bunch of problems with the device tree anyway...
> >   	pci@80000000 {
> > 		device_type = "pci";
> > 		bus-frequency = <01fca055>;		// 33.3MHz
> > 		bus-range = <0 1>;
> > 		reg = <80000000 7f000000>;				//
> >Whole PCI space.
> 
> 'reg' and 'ranges' should not typically overlap.  'reg' should only
> encode control registers for the bridge, not the whole PCI space (not
> that I'm even entirely sure what you mean by that).
Hmm, strange. I'm sure I found this in another device tree. I define
"whole PCI space" as PCI (prefetchable) memory and PCI I/O space.

> > 		host@0 {
> 
> The unit address (after the @) should be derived from the first range
> listed in the 'reg' property.  It's a bus address, not a slot number.
AFAIK it's the device number, which is 0 for this host/PCI bridge.

> > 			vendor-id = 0x000010cc;
> 
> Um.. evidentally you have never even tried compiling this device tree,
> since this is invalid syntax.  That would need to be:
> 			vendor-id = <000010cc>;
> and likewise all the others below.
Uh, yeah! I thought I fixed all these typos. You're right, I didn't try
to compile the device tree yet.

> > 			#interrupt-cells = <2>;
> > 			#address-cells = <2>;
> > 			#size-cells = <1>;
> > 
> > 			dma-controller {
> 
> All these devices should have unit addresses.
Okay, that would be dma-controller@0, interrupt-controller@20 and so.
Will be fixed!

> > 		ide@7,1 {
> 
> This will need a compatible property, at least.
I hoped the class-code property is enough for a PCI device, as it
clearly identifies this device as a PCI IDE conroller with primary and
secondary master functionality.

Thanks!

regards,

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] AmigaOne device tree source v2

[Gerhard Pircher]

Hi,

-------- Original-Nachricht --------
> Datum: Mon, 3 Sep 2007 20:12:34 +1000
> Von: David Gibson <david@gibson.dropbear.id.au>
> An: Segher Boessenkool <segher@kernel.crashing.org>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: [RFC] AmigaOne device tree source v2

> On Mon, Sep 03, 2007 at 12:02:58PM +0200, Segher Boessenkool wrote:
> > Yeah, PCI is a special case for Linux.  Maybe add a "pciclass,XXXX"
> > compatible property though, for good measure.  Anything else isn't
> > all that useful I think.
Wouldn't that be the same as the class-code property?

> Indeed, since PCI is probable, it's unclear whether these device nodes
> are even necessary at all.  Depends on whether there's anything
> interesting in the omitted interrupt routing information.
Well, I mainly specified the device node for the IDE controller, because
it works in compatible mode and thus the IDE driver needs to know about
the I/O ports. I guess the driver doesn't probe the BARs, if the
controller is configured for compatible mode (and AFAIK a VIA IDE
controller cannot be made work in fully native mode). Also the ppc_ide_md
function hooks are considered obsolete.
The interrupts for the IDE controller are another story. Judging from
what some developers wrote on this mailing list, there doesn't seem to
be a way to define legacy IDE interrupts (14 & 15) for a PCI device node.
Therefore I'll reuse the IDE interrupt quirk for the Pegasos.

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] AmigaOne device tree source v2

[Segher Boessenkool]

>>>   	pci@80000000 {
>>> 		device_type = "pci";
>>> 		bus-frequency = <01fca055>;		// 33.3MHz
>>> 		bus-range = <0 1>;
>>> 		reg = <80000000 7f000000>;				//
>>> Whole PCI space.
>>
>> 'reg' and 'ranges' should not typically overlap.  'reg' should only
>> encode control registers for the bridge, not the whole PCI space (not
>> that I'm even entirely sure what you mean by that).
> Hmm, strange. I'm sure I found this in another device tree. I define
> "whole PCI space" as PCI (prefetchable) memory and PCI I/O space.

PCI memory space sits on the PCI bus, not on the PCI host bridge,
so is not part of "reg" but is part of "ranges" here, since it is
direct mapped into the host's address space.

PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus.  So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property.  It could be a simple linear window (it
sounds like it is here?), but it could for example also be implemented
via an address/data register pair.

The order of the "reg" entries depends on the exact model of PCI
bridge, so a device binding for it has to be written.

>>> 		host@0 {
>>
>> The unit address (after the @) should be derived from the first range
>> listed in the 'reg' property.  It's a bus address, not a slot number.
> AFAIK it's the device number, which is 0 for this host/PCI bridge.

The unit address is relative to the parent bus.  The PCI host bridge
is not its own parent ;-)


Segher

Re: [RFC] AmigaOne device tree source v2

[Segher Boessenkool]

>>> Yeah, PCI is a special case for Linux.  Maybe add a "pciclass,XXXX"
>>> compatible property though, for good measure.  Anything else isn't
>>> all that useful I think.
> Wouldn't that be the same as the class-code property?

Sure, except it is a different property.  If you use the "class-code"
thing, you really should implement _all_ of the PCI binding's required
properties.  If you don't (since Linux doesn't use it anyway), it might
still be nice to have a "compatible" property at least (since that is
what is used for figuring out what device driver to use for this device
node).  Linux doesn't currently use that either, so you don't have to,
but you could put it there and it would make sense, that's all.

>> Indeed, since PCI is probable, it's unclear whether these device nodes
>> are even necessary at all.  Depends on whether there's anything
>> interesting in the omitted interrupt routing information.
> Well, I mainly specified the device node for the IDE controller, 
> because
> it works in compatible mode and thus the IDE driver needs to know about
> the I/O ports. I guess the driver doesn't probe the BARs, if the
> controller is configured for compatible mode (and AFAIK a VIA IDE
> controller cannot be made work in fully native mode).

Yeah most of those are nasty.

If the driver grabs some hardcoded legacy I/O ranges if the controller
is in legacy mode, the only thing that showing those ranges in the
"reg" property helps are _other_ parts of the kernel that might care,
not that driver since it hardcodes the address; and those other parts
of the kernel shouldn't care anyway, since _they_ shouldn't use any
hardcoded ranges either!

If those addresses really show up in the PCI BARs (most controllers
don't do that in legacy mode), the kernel's own PCI probing will
see it already; if they aren't in BARs, it is a bit tricky to encode
that correctly in the "reg" (it's perfectly well-defined, just a bit
hard to get it right).

> The interrupts for the IDE controller are another story. Judging from
> what some developers wrote on this mailing list, there doesn't seem to
> be a way to define legacy IDE interrupts (14 & 15) for a PCI device 
> node.

There is no such thing as "interrupt 14 and 15" on PCI.  You can use
the interrupt mapping recommended practice to show two interrupts
(and their polarity, and how they are routed to the relevant interrupt
controller) in the IDE node.


Segher

Re: [RFC] AmigaOne device tree source v2

[David Gibson]

On Tue, Sep 04, 2007 at 12:52:02AM +0200, Segher Boessenkool wrote:
> >>> Yeah, PCI is a special case for Linux.  Maybe add a "pciclass,XXXX"
> >>> compatible property though, for good measure.  Anything else isn't
> >>> all that useful I think.
> > Wouldn't that be the same as the class-code property?
> 
> Sure, except it is a different property.  If you use the "class-code"
> thing, you really should implement _all_ of the PCI binding's required
> properties.  If you don't (since Linux doesn't use it anyway), it might
> still be nice to have a "compatible" property at least (since that is
> what is used for figuring out what device driver to use for this device
> node).  Linux doesn't currently use that either, so you don't have to,
> but you could put it there and it would make sense, that's all.
> 
> >> Indeed, since PCI is probable, it's unclear whether these device nodes
> >> are even necessary at all.  Depends on whether there's anything
> >> interesting in the omitted interrupt routing information.
> > Well, I mainly specified the device node for the IDE controller, 
> > because
> > it works in compatible mode and thus the IDE driver needs to know about
> > the I/O ports. I guess the driver doesn't probe the BARs, if the
> > controller is configured for compatible mode (and AFAIK a VIA IDE
> > controller cannot be made work in fully native mode).

Hrm.. IIRC, it is permissible under Linux to only include device nodes
for those PCI devices where something must be specified which can't be
proved via PCI.

> Yeah most of those are nasty.
> 
> If the driver grabs some hardcoded legacy I/O ranges if the controller
> is in legacy mode, the only thing that showing those ranges in the
> "reg" property helps are _other_ parts of the kernel that might care,
> not that driver since it hardcodes the address; and those other parts
> of the kernel shouldn't care anyway, since _they_ shouldn't use any
> hardcoded ranges either!
> 
> If those addresses really show up in the PCI BARs (most controllers
> don't do that in legacy mode), the kernel's own PCI probing will
> see it already; if they aren't in BARs, it is a bit tricky to encode
> that correctly in the "reg" (it's perfectly well-defined, just a bit
> hard to get it right).
> 
> > The interrupts for the IDE controller are another story. Judging from
> > what some developers wrote on this mailing list, there doesn't seem to
> > be a way to define legacy IDE interrupts (14 & 15) for a PCI device 
> > node.
> 
> There is no such thing as "interrupt 14 and 15" on PCI.  You can use
> the interrupt mapping recommended practice to show two interrupts
> (and their polarity, and how they are routed to the relevant interrupt
> controller) in the IDE node.

What he said.  More specifically, your IDE device node could specify
interrupts which are routed to the ISA i8259 (and are therefore
equivalent to the legacy interrupts) rather than to the main system
interrupt controller, or via the normal pci interrupt map.

-- 
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] AmigaOne device tree source v2

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Tue, 4 Sep 2007 00:32:57 +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] AmigaOne device tree source v2

> PCI memory space sits on the PCI bus, not on the PCI host bridge,
> so is not part of "reg" but is part of "ranges" here, since it is
> direct mapped into the host's address space.
That's right, but what about this example here (from a Pegasos II):

/proc/device-tree/pci@80000000:
name             "pci"
linux,phandle    0fc59260 (264606304)
bus-range        00000000 00000000
pci-bridge-number 00000000
reg              80000000 40000000
8259-interrupt-acknowledge f1000cb4
ranges           01000000 00000000 00000000 fe000000 00000000 00010000
		 02000000 00000000 80000000 80000000 00000000 40000000
clock-frequency  01fca055 (33333333)
#size-cells      00000002
#address-cells   00000003
device_type      "pci"

AFAIU the reg property overlaps the ranges property for the PCI memory
space from 0x80000000 to 0xC0000000 or the CPU address space at the
same location!? Would be good to know, why it was defined like this.

> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> PowerPC system bus.  So, it can not be mentioned in the "ranges"
> property, but the PHB registers used to access it should be shown
> in the "reg" property.  It could be a simple linear window (it
> sounds like it is here?), but it could for example also be implemented
> via an address/data register pair.
Yes, it is a simple linear address window. I'll remove its address range
from the reg property.

> The order of the "reg" entries depends on the exact model of PCI
> bridge, so a device binding for it has to be written.
Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it should
be enough to check for the board type, but a compatible property doesn't
hurt.

Thanks,

Gerhard

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

Re: [RFC] AmigaOne device tree source v2

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Tue, 4 Sep 2007 00:52:02 +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] AmigaOne device tree source v2

> >>> Yeah, PCI is a special case for Linux.  Maybe add a "pciclass,XXXX"
> >>> compatible property though, for good measure.  Anything else isn't
> >>> all that useful I think.
> > Wouldn't that be the same as the class-code property?
> 
> Sure, except it is a different property.  If you use the "class-code"
> thing, you really should implement _all_ of the PCI binding's required
> properties.  If you don't (since Linux doesn't use it anyway), it might
> still be nice to have a "compatible" property at least (since that is
> what is used for figuring out what device driver to use for this device
> node).  Linux doesn't currently use that either, so you don't have to,
> but you could put it there and it would make sense, that's all.
Okay, I'll add a compatible = "pciclass,0101"; property to the node.
BTW: It looks like the Pegasos II device tree defines device_type = "spi"
for the IDE controller. Is that correct?

> If those addresses really show up in the PCI BARs (most controllers
> don't do that in legacy mode), the kernel's own PCI probing will
> see it already; if they aren't in BARs, it is a bit tricky to encode
> that correctly in the "reg" (it's perfectly well-defined, just a bit
> hard to get it right).
These addresses show up in the PCI BARs of the VIA 686B IDE controller,
even if it is configured for compatible mode.

> There is no such thing as "interrupt 14 and 15" on PCI.  You can use
> the interrupt mapping recommended practice to show two interrupts
> (and their polarity, and how they are routed to the relevant interrupt
> controller) in the IDE node.
But I'll still need a quirk in the IDE driver, because it doesn't make
use of any interrupt routing information in the device tree. If so, I
can omit the whole IDE controller device node and simply rely on the
IDE driver's probe functions and the Pegasos IDE IRQ quirk.
I wonder how this issue will be handled for libata and the via-pata
driver, since IIRC this one doesn't contain the Pegasos IDE IRQ quirk.

Thanks,

Gerhard

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

Re: [RFC] AmigaOne device tree source v2

[David Gibson]

On Tue, Sep 04, 2007 at 01:49:45PM +0200, Gerhard Pircher wrote:
> 
> -------- Original-Nachricht --------
> > Datum: Tue, 4 Sep 2007 00:32:57 +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] AmigaOne device tree source v2
> 
> > PCI memory space sits on the PCI bus, not on the PCI host bridge,
> > so is not part of "reg" but is part of "ranges" here, since it is
> > direct mapped into the host's address space.
> That's right, but what about this example here (from a Pegasos II):
> 
> /proc/device-tree/pci@80000000:
> name             "pci"
> linux,phandle    0fc59260 (264606304)
> bus-range        00000000 00000000
> pci-bridge-number 00000000
> reg              80000000 40000000
> 8259-interrupt-acknowledge f1000cb4
> ranges           01000000 00000000 00000000 fe000000 00000000 00010000
> 		 02000000 00000000 80000000 80000000 00000000 40000000
> clock-frequency  01fca055 (33333333)
> #size-cells      00000002
> #address-cells   00000003
> device_type      "pci"
> 
> AFAIU the reg property overlaps the ranges property for the PCI memory
> space from 0x80000000 to 0xC0000000 or the CPU address space at the
> same location!? Would be good to know, why it was defined like this.

That looks totally bogus.  Unlike Segher, I think there are a few
cases where overlapping reg and ranges can make sense (PCI bridges
where config space is accessed indirectly via MMIO registers which lie
in the legacy ISA IO space is an example).  But this doesn't look like
such a case - it just looks like whoever did the device tree
misunderstood the distinction between reg and ranges.

> > PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> > PowerPC system bus.  So, it can not be mentioned in the "ranges"
> > property, but the PHB registers used to access it should be shown
> > in the "reg" property.  It could be a simple linear window (it
> > sounds like it is here?), but it could for example also be implemented
> > via an address/data register pair.

Err... huh?  The legacy IO space is assigned a block of addresses in
3-word "OF-PCI-space by the PCI binding.  When that is translated into
an MMIO range by the bridge, there's no reason that can't be encoded
into the ranges property.

> Yes, it is a simple linear address window. I'll remove its address range
> from the reg property.
> 
> > The order of the "reg" entries depends on the exact model of PCI
> > bridge, so a device binding for it has to be written.
> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it should
> be enough to check for the board type, but a compatible property doesn't
> hurt.

The whole damn point of the device tree is to avoid using this kind of
non-local information "I know what the board type is over there, so it
must be this PCI bridge over here".  The node should have a compatible
property which is sufficient to select the right bridge driver.

I think this is typically badly done at the moment, simply because PCI
has historically been set up by the platform code, rather than by a
"host bridge driver" in the mould of other drivers.  I don't see that
changing real soon, but that doesn't mean we shouldn't at least put
enough information in the device tree to make it possible.

-- 
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] AmigaOne device tree source v2

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Wed, 5 Sep 2007 12:48:05 +1000
> Von: David Gibson <david@gibson.dropbear.id.au>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: Segher Boessenkool <segher@kernel.crashing.org>, linuxppc-dev@ozlabs.org
> Betreff: Re: [RFC] AmigaOne device tree source v2

> That looks totally bogus.  Unlike Segher, I think there are a few
> cases where overlapping reg and ranges can make sense (PCI bridges
> where config space is accessed indirectly via MMIO registers which lie
> in the legacy ISA IO space is an example).  But this doesn't look like
> such a case - it just looks like whoever did the device tree
> misunderstood the distinction between reg and ranges.
AmigaOne's PCI bridge implements PCI config with indirect addressing, but
not within the ISA I/O space. I just wanted to clear up the meaning of
this reg entry, because it looks like everyone interprets the OF spec a
little bit differently.

> > > PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> > > PowerPC system bus.  So, it can not be mentioned in the "ranges"
> > > property, but the PHB registers used to access it should be shown
> > > in the "reg" property.  It could be a simple linear window (it
> > > sounds like it is here?), but it could for example also be
> > > implemented via an address/data register pair.
> 
> Err... huh?  The legacy IO space is assigned a block of addresses in
> 3-word "OF-PCI-space by the PCI binding.  When that is translated into
> an MMIO range by the bridge, there's no reason that can't be encoded
> into the ranges property.
I defined the legacy I/O space together with the PCI I/O space in the
ranges property of the PCI node:
ranges = <01000000 0 00000000 fe000000 0 00c00000
The first 64k of this address space are mapped to ISA I/O in the PCI2ISA
bridge node.

> The whole damn point of the device tree is to avoid using this kind of
> non-local information "I know what the board type is over there, so it
> must be this PCI bridge over here".  The node should have a compatible
> property which is sufficient to select the right bridge driver.
Yeah, I defined a compatible = "mai,articias"; property in the pci node.
Are there any naming conventions (maybe lower case only)?

> I think this is typically badly done at the moment, simply because PCI
> has historically been set up by the platform code, rather than by a
> "host bridge driver" in the mould of other drivers.  I don't see that
> changing real soon, but that doesn't mean we shouldn't at least put
> enough information in the device tree to make it possible.
I agree (even if it means more work for me :-)

I'll post a revised version of the device tree.

Thanks!

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] AmigaOne device tree source v2

[Segher Boessenkool]

> Hrm.. IIRC, it is permissible under Linux to only include device nodes
> for those PCI devices where something must be specified which can't be
> proved via PCI.

It is.  It isn't clear (to me, at least) which properties are
required in a PCI node that exists for e.g. interrupt reasons
only; or how the kernel decides if a PCI node is a "real" PCI
node (i.e., using the PCI binding), or an "empty" PCI node.


Segher

Re: [RFC] AmigaOne device tree source v2

[Segher Boessenkool]

>> PCI memory space sits on the PCI bus, not on the PCI host bridge,
>> so is not part of "reg" but is part of "ranges" here, since it is
>> direct mapped into the host's address space.
> That's right, but what about this example here (from a Pegasos II):
>
> /proc/device-tree/pci@80000000:

> reg              80000000 40000000

> ranges           01000000 00000000 00000000 fe000000 00000000 00010000
> 		 02000000 00000000 80000000 80000000 00000000 40000000

That's just broken.

> AFAIU the reg property overlaps the ranges property for the PCI memory
> space from 0x80000000 to 0xC0000000 or the CPU address space at the
> same location!?

reg = < something for pci config space >,
       < fe000000 10000 >

ranges = < 02000000 0 80000000  80000000  0 40000000 >

>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
>> PowerPC system bus.  So, it can not be mentioned in the "ranges"
>> property, but the PHB registers used to access it should be shown
>> in the "reg" property.  It could be a simple linear window (it
>> sounds like it is here?), but it could for example also be implemented
>> via an address/data register pair.
> Yes, it is a simple linear address window. I'll remove its address 
> range
> from the reg property.

No, please remove it from the "ranges" property, instead.

>> The order of the "reg" entries depends on the exact model of PCI
>> bridge, so a device binding for it has to be written.
> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it 
> should
> be enough to check for the board type, but a compatible property 
> doesn't
> hurt.

Please always use "compatible" to probe any devices.


Segher

Re: [RFC] AmigaOne device tree source v2

[Segher Boessenkool]

> BTW: It looks like the Pegasos II device tree defines device_type = 
> "spi"
> for the IDE controller. Is that correct?

There is no standard binding for an "spi" device type.  I have no
idea which of various "SPI" kind of devices is meant here; and none
of the ones I know of have anything to do with ATA anyway.

In short, it probably is incorrect.

Also, in general, you shouldn't use "device_type" in flat device
trees (the main exceptions are: some/most bus nodes, cpu nodes,
some other "standard" nodes).

>> There is no such thing as "interrupt 14 and 15" on PCI.  You can use
>> the interrupt mapping recommended practice to show two interrupts
>> (and their polarity, and how they are routed to the relevant interrupt
>> controller) in the IDE node.
> But I'll still need a quirk in the IDE driver, because it doesn't make
> use of any interrupt routing information in the device tree. If so, I
> can omit the whole IDE controller device node and simply rely on the
> IDE driver's probe functions and the Pegasos IDE IRQ quirk.
> I wonder how this issue will be handled for libata and the via-pata
> driver, since IIRC this one doesn't contain the Pegasos IDE IRQ quirk.

I imagine the ata quirk would ask the arch or platform code about
the interrupts used; it in turn can query the device tree.


Segher

Re: [RFC] AmigaOne device tree source v2

[Segher Boessenkool]

> That looks totally bogus.  Unlike Segher, I think there are a few
> cases where overlapping reg and ranges can make sense

That's not unlike me -- I may have lower tolerance for it though :-)

> (PCI bridges
> where config space is accessed indirectly via MMIO registers which lie
> in the legacy ISA IO space is an example).

That's a good example yes.

> But this doesn't look like
> such a case - it just looks like whoever did the device tree
> misunderstood the distinction between reg and ranges.

Indeed.

>>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
>>> PowerPC system bus.  So, it can not be mentioned in the "ranges"
>>> property, but the PHB registers used to access it should be shown
>>> in the "reg" property.  It could be a simple linear window (it
>>> sounds like it is here?), but it could for example also be 
>>> implemented
>>> via an address/data register pair.
>
> Err... huh?  The legacy IO space is assigned a block of addresses in
> 3-word "OF-PCI-space by the PCI binding.  When that is translated into
> an MMIO range by the bridge, there's no reason that can't be encoded
> into the ranges property.

Sure, it can be encoded like that.  But does it make sense?
You cannot use legacy I/O space as normal memory space.

On an arch like x86, where "I/O addresses" exist on the system
bus as well, it would make sense, since you can translate I/O
addresses to I/O addresses that way (except on x86 even it cannot
be done either, since I/O addresses cannot be encoded on the root
bus -- at least not in existing device trees.  There is no official
x86 binding yet though).

Also, from a driver standpoint, a PHB driver needs to find out
two main things about the bridge: a) how and where to generate
config cycles; b) how and where to generate legacy I/O cycles.
It is told "how" by the "compatible" property, and "where" by
the "reg" property, normally.

But yes, you _can_ use "ranges" for this purpose on PHBs where
legacy I/O is linearly mapped.  It just doesn't make much sense.
The binding for your specific PHB should tell you what to do.

>> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it 
>> should
>> be enough to check for the board type, but a compatible property 
>> doesn't
>> hurt.
>
> The whole damn point of the device tree is to avoid using this kind of
> non-local information "I know what the board type is over there, so it
> must be this PCI bridge over here".  The node should have a compatible
> property which is sufficient to select the right bridge driver.

Yeah.  _Even if_ the kernel decides to cheat by hardcoding certain
board information, that doesn't mean the device tree shouldn't
encode that info, too.

> I think this is typically badly done at the moment, simply because PCI
> has historically been set up by the platform code, rather than by a
> "host bridge driver" in the mould of other drivers.  I don't see that
> changing real soon, but that doesn't mean we shouldn't at least put
> enough information in the device tree to make it possible.

Exactly.


Segher

Re: [RFC] AmigaOne device tree source v2

[Segher Boessenkool]

>> The node should have a compatible
>> property which is sufficient to select the right bridge driver.
> Yeah, I defined a compatible = "mai,articias"; property in the pci 
> node.
> Are there any naming conventions (maybe lower case only)?

It's conventional for the part behind the comma to be lower-case
only, yes.  There are more stringent rules for the part before
the comma (the manufacturer part).  What is "mai"?


Segher

Re: [RFC] AmigaOne device tree source v2

[Sven Luther]

On Thu, Sep 06, 2007 at 04:00:45PM +0200, Segher Boessenkool wrote:
> >> The node should have a compatible
> >> property which is sufficient to select the right bridge driver.
> > Yeah, I defined a compatible = "mai,articias"; property in the pci 
> > node.
> > Are there any naming conventions (maybe lower case only)?
> 
> It's conventional for the part behind the comma to be lower-case
> only, yes.  There are more stringent rules for the part before
> the comma (the manufacturer part).  What is "mai"?

mai logic (some mentor arc derivative i think, ma stands for mentor arc)
was the firm who produced the articia northbridge. The Articia S
northbridge was known to be defective, and i am unsure if mai survived
it or something. 

Friendly,

Sven Luther

PCI I/O space -- reg or ranges?

[Scott Wood]

On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > Err... huh?  The legacy IO space is assigned a block of addresses in
> > 3-word "OF-PCI-space by the PCI binding.  When that is translated into
> > an MMIO range by the bridge, there's no reason that can't be encoded
> > into the ranges property.
> 
> Sure, it can be encoded like that.  But does it make sense?
> You cannot use legacy I/O space as normal memory space.

Why does it not make sense?  I'm not sure what you mean by using it as
"normal memory space", but if the PCI bridge does a straightforward
linear mapping of I/O into memory space (like most non-x86 bridges do),
it seems to make sense to me to reuse the existing ranges mechanism
rather than require each driver to have extra glue code.

And given the substantial impact of such a change on many existing device
trees and the kernel, it should probably be brought up in a thread with a
subject that will clue people in to what is being discussed, rather than
buried in "AmigaOne device tree source v2".

BTW, memory space could be non-linear as well, so should we stop using
ranges for that?  For an example, see the old Alphas which lacked
byte/word I/O, and thus used a weird sparse mapping to control the size
of the access that went out over the bus.

> Also, from a driver standpoint, a PHB driver needs to find out
> two main things about the bridge: a) how and where to generate
> config cycles; b) how and where to generate legacy I/O cycles.
> It is told "how" by the "compatible" property, and "where" by
> the "reg" property, normally.

All it currently needs to do is a), provided it's a normal linear mapping
and the I/O space is in ranges.

-Scott

Re: [RFC] AmigaOne device tree source v2

[Segher Boessenkool]

>>>> The node should have a compatible
>>>> property which is sufficient to select the right bridge driver.
>>> Yeah, I defined a compatible = "mai,articias"; property in the pci
>>> node.
>>> Are there any naming conventions (maybe lower case only)?
>>
>> It's conventional for the part behind the comma to be lower-case
>> only, yes.  There are more stringent rules for the part before
>> the comma (the manufacturer part).  What is "mai"?
>
> mai logic (some mentor arc derivative i think, ma stands for mentor 
> arc)
> was the firm who produced the articia northbridge.

It should either be "00009D2,articia-s" (using the OUI) or
"mai-logic,articia-s", then.

> The Articia S
> northbridge was known to be defective, and i am unsure if mai survived
> it or something.

It seems they didn't.


Segher

Re: PCI I/O space -- reg or ranges?

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Thu, 6 Sep 2007 09:15:01 -0500
> Von: Scott Wood <scottwood@freescale.com>
> An: Segher Boessenkool <segher@kernel.crashing.org>
> CC: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
> Betreff: PCI I/O space -- reg or ranges?

> > Sure, it can be encoded like that.  But does it make sense?
> > You cannot use legacy I/O space as normal memory space.
> 
> Why does it not make sense?  I'm not sure what you mean by using it as
> "normal memory space", but if the PCI bridge does a straightforward
> linear mapping of I/O into memory space (like most non-x86 bridges do),
> it seems to make sense to me to reuse the existing ranges mechanism
> rather than require each driver to have extra glue code.
Well, pci_process_bridge_OF_ranges() only looks at the ranges property to
ioremap() I/O space.

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: PCI I/O space -- reg or ranges?

[Segher Boessenkool]

>>> Sure, it can be encoded like that.  But does it make sense?
>>> You cannot use legacy I/O space as normal memory space.
>>
>> Why does it not make sense?  I'm not sure what you mean by using it as
>> "normal memory space", but if the PCI bridge does a straightforward
>> linear mapping of I/O into memory space (like most non-x86 bridges 
>> do),
>> it seems to make sense to me to reuse the existing ranges mechanism
>> rather than require each driver to have extra glue code.
> Well, pci_process_bridge_OF_ranges() only looks at the ranges property 
> to
> ioremap() I/O space.

That's because it is the function that process the "ranges"
property, like its name shows ;-)


Segher

Re: [RFC] AmigaOne device tree source v2

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Thu, 6 Sep 2007 15:36:30 +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] AmigaOne device tree source v2

> >> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >> PowerPC system bus.  So, it can not be mentioned in the "ranges"
> >> property, but the PHB registers used to access it should be shown
> >> in the "reg" property.  It could be a simple linear window (it
> >> sounds like it is here?), but it could for example also be implemented
> >> via an address/data register pair.
> > Yes, it is a simple linear address window. I'll remove its address 
> > range from the reg property.
> 
> No, please remove it from the "ranges" property, instead.
What about the PCI2ISA bridge? I map the first 64k PCI I/O address space
as ISA I/O space by using a ranges property. Would that be incorrect,
too?

Gerhard

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

Re: [RFC] AmigaOne device tree source v2

[David Gibson]

On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > That looks totally bogus.  Unlike Segher, I think there are a few
> > cases where overlapping reg and ranges can make sense
> 
> That's not unlike me -- I may have lower tolerance for it though :-)

I see.  Can't imagine how I got another impression... :-p

: Date: Thu, 19 Jul 2007 17:51:17 +0200
: From: Segher Boessenkool <segher@kernel.crashing.org>
: Subject: Re: [PATCH] Add 8548CDS with Arcadia 3.0 support
...
: "reg" and "ranges" overlap, that can't be right.

: Date: Tue, 7 Aug 2007 18:51:04 +0200
: From: Segher Boessenkool <segher@kernel.crashing.org>
: Subject: Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
...
: > To be honest this looks rather to me like another case where having
: > overlapping 'reg' and 'ranges' would actually make sense.
:
: It never makes sense.  You should give the "master" device
: the full "reg" range it covers, and have it define its own
...

> > (PCI bridges
> > where config space is accessed indirectly via MMIO registers which lie
> > in the legacy ISA IO space is an example).
> 
> That's a good example yes.
> 
> > But this doesn't look like
> > such a case - it just looks like whoever did the device tree
> > misunderstood the distinction between reg and ranges.
> 
> Indeed.
> 
> >>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >>> PowerPC system bus.  So, it can not be mentioned in the "ranges"
> >>> property, but the PHB registers used to access it should be shown
> >>> in the "reg" property.  It could be a simple linear window (it
> >>> sounds like it is here?), but it could for example also be 
> >>> implemented
> >>> via an address/data register pair.
> >
> > Err... huh?  The legacy IO space is assigned a block of addresses in
> > 3-word "OF-PCI-space by the PCI binding.  When that is translated into
> > an MMIO range by the bridge, there's no reason that can't be encoded
> > into the ranges property.
> 
> Sure, it can be encoded like that.  But does it make sense?
> You cannot use legacy I/O space as normal memory space.

Well, no, but you can't use *any* MMIO space as normal memory space,
and that's handled routinely by 'ranges'.

> On an arch like x86, where "I/O addresses" exist on the system
> bus as well, it would make sense, since you can translate I/O
> addresses to I/O addresses that way (except on x86 even it cannot
> be done either, since I/O addresses cannot be encoded on the root
> bus -- at least not in existing device trees.  There is no official
> x86 binding yet though).

What!?  This is nuts, Segher.  Why should the binding have to define
some bridge-specific way of encoding the legacy I/O information, when
the PCI-binding's address encoding plus 'ranges' provides a perfectly
unambiguous way of doing so.  *And* it makes the normal semantics of
ranges do just the right thing for a subordinate PCI<->ISA bridge.

> Also, from a driver standpoint, a PHB driver needs to find out
> two main things about the bridge: a) how and where to generate
> config cycles; b) how and where to generate legacy I/O cycles.
> It is told "how" by the "compatible" property, and "where" by
> the "reg" property, normally.
> 
> But yes, you _can_ use "ranges" for this purpose on PHBs where
> legacy I/O is linearly mapped.  It just doesn't make much sense.
> The binding for your specific PHB should tell you what to do.

-- 
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] AmigaOne device tree source v2

[David Gibson]

On Thu, Sep 06, 2007 at 03:36:30PM +0200, Segher Boessenkool wrote:
[snip]
> >> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >> PowerPC system bus.  So, it can not be mentioned in the "ranges"
> >> property, but the PHB registers used to access it should be shown
> >> in the "reg" property.  It could be a simple linear window (it
> >> sounds like it is here?), but it could for example also be implemented
> >> via an address/data register pair.
> > Yes, it is a simple linear address window. I'll remove its address 
> > range
> > from the reg property.
> 
> No, please remove it from the "ranges" property, instead.

No, don't.  Removing it from reg is just fine.

> >> The order of the "reg" entries depends on the exact model of PCI
> >> bridge, so a device binding for it has to be written.
> > Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it 
> > should
> > be enough to check for the board type, but a compatible property 
> > doesn't
> > hurt.
> 
> Please always use "compatible" to probe any devices.

Do do that, 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