All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: David Gibson <david@gibson.dropbear.id.au>,
	linux-kernel@vger.kernel.org, sodaville@linutronix.de,
	devicetree-discuss@lists.ozlabs.org, x86@kernel.org
Subject: Re: [PATCH TIP v2 03/14] x86/dtb: Add a device tree for CE4100
Date: Wed, 16 Feb 2011 14:44:28 -0700	[thread overview]
Message-ID: <20110216214428.GD22837@angua.secretlab.ca> (raw)
In-Reply-To: <20110202185841.GA28674@www.tglx.de>

On Thu, Feb 03, 2011 at 12:28:41AM +0530, Sebastian Andrzej Siewior wrote:
> Cc: devicetree-discuss@lists.ozlabs.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
> ---
> - intel,ce4100-immr become intel,ce4100-cp. cp stands for core
>   peripherals. The Atom data sheet talks here about ACPI devices. Since
>   we don't have ACPI this does not apply here.
> - The interrupt map is gone. There are now plenty of device nodes.
> - The "unit address string" got fixed, it uses not DD,V format.

It's actually useful to have this revision history as part of the
patch description itself so that when it is committed we've got a
record of exactly which version got committed.

g.

> 
>  arch/x86/platform/ce4100/falconfalls.dts |  424 ++++++++++++++++++++++++++++++
>  1 files changed, 424 insertions(+), 0 deletions(-)
>  create mode 100644 arch/x86/platform/ce4100/falconfalls.dts
> 
> diff --git a/arch/x86/platform/ce4100/falconfalls.dts b/arch/x86/platform/ce4100/falconfalls.dts
> new file mode 100644
> index 0000000..e888657
> --- /dev/null
> +++ b/arch/x86/platform/ce4100/falconfalls.dts
> @@ -0,0 +1,424 @@
> +/*
> + * CE4100 on Falcon Falls
> + *
> + * (c) Copyright 2010 Intel Corporation
> + *
> + * 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; version 2 of the License.
> + */
> +/dts-v1/;
> +/ {
> +	model = "intel,falconfalls";
> +	compatible = "intel,falconfalls";
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			compatible = "intel,ce4100";
> +			reg = <0>;
> +			lapic = <&lapic0>;
> +		};
> +	};
> +
> +	soc@0 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "intel,ce4100-cp";

You *must* include documentation for each of these new compatible
values before merging this patch.  At the very least it acts as a
placeholder and describes exactly what the string describes.

> +		ranges;
> +
> +		ioapic1: interrupt-controller@fec00000 {
> +			#interrupt-cells = <2>;
> +			compatible = "intel,ioapic-ce4100", "intel,ioapic";

"intel,ioapic" is probably too generic and can be dropped.  Newer
devices can claim compatibility with "intel,ioapic-ce4100" if they are
indeed compatible so that device drivers don't need to be modified.
It is better to anchor compatible values to real implementations that
try to come up with 'generic' or wildcard strings.  Ditto through the
rest of the file.

"intel,ce4100-ioapic" (instead of intel,ioapic-ce4100) would follow
current convention better of specifying the chip first, followed by
the on-chip device.

> +			interrupt-controller;
> +			reg = <0xfec00000 0x1000>;
> +		};
> +
> +		timer@fed00000 {
> +			compatible = "intel,hpet-ce4100", "intel,hpet";
> +			reg = <0xfed00000 0x200>;
> +		};
> +
> +		lapic0: interrupt-controller@fee00000 {
> +			compatible = "intel,lapic-ce4100", "intel,lapic";
> +			reg = <0xfee00000 0x1000>;
> +		};
> +
> +		pci@3fc {
> +			#address-cells = <3>;
> +			#interrupt-cells = <1>;
> +			#size-cells = <2>;
> +			compatible = "intel,ce4100-pci", "pci";
> +			device_type = "pci";
> +			bus-range = <0 0>;
> +			ranges = <0x2000000 0 0xbffff000 0xbffff000 0 0x1000
> +				  0x2000000 0 0xdffe0000 0xdffe0000 0 0x1000
> +				  0x0000000 0 0x0	 0x0	    0 0x100>;
> +
> +			/* Secondary IO-APIC */
> +			ioapic2: interrupt-controller@0,1 {
> +				#interrupt-cells = <2>;
> +				compatible = "intel,ioapic-ce4100", "intel,ioapic";
> +				interrupt-controller;
> +				reg = <0x100 0x0 0x0 0x0 0x0>;
> +				assigned-addresses = <0x02000000 0x0 0xbffff000 0x0 0x1000>;
> +			};
> +
> +			pci@1,0 {
> +				#address-cells = <3>;
> +				#interrupt-cells = <1>;
> +				#size-cells = <2>;
> +				compatible = "intel,ce4100-pci", "pci";
> +				device_type = "pci";
> +				bus-range = <1 1>;
> +				ranges = <0x2000000 0 0xdffe0000 0x2000000 0 0xdffe0000 0 0x1000>;
> +
> +				interrupt-parent = <&ioapic2>;
> +
> +				display@2,0 {
> +					compatible = "pci8086,2e5b.2",
> +						   "pci8086,2e5b",
> +						   "pciclass038000",
> +						   "pciclass0380";
> +
> +					reg = <0x11000 0x0 0x0 0x0 0x0>;
> +					interrupts = <0 1>;
> +				};

Here's where things get a little sticky for PCI child devices
(probably should have thought about this earlier, sorry).  Are these
devices runtime detectable?  ie. does reading the PCI BARs and irq
configuration registers reflect reality?

In general, if something can be *reliably* detected then it should not
be listed in the device tree.  However, if there is some horrid gotcha
that prevents it being detected reliably, then it definitely should
appear here.

I cannot answer this question for you since I don't know the hardware.
It's a judgement call that you'll need to make on whether or not these
PCI (or pseudo pci?) devices should be listed in the dt.

One of the things that does need to be improved is partial probing of
PCI busses so that only the messy PCI devices get listed in the device
tree, and the rest of the devices can get detected in the normal
manner.

> +
> +				multimedia@3,0 {
> +					compatible = "pci8086,2e5c.2",
> +						   "pci8086,2e5c",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x11800 0x0 0x0 0x0 0x0>;
> +					interrupts = <2 1>;
> +				};
> +
> +				multimedia@4,0 {
> +					compatible = "pci8086,2e5d.2",
> +						   "pci8086,2e5d",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x12000 0x0 0x0 0x0 0x0>;
> +					interrupts = <4 1>;
> +				};
> +
> +				multimedia@4,1 {
> +					compatible = "pci8086,2e5e.2",
> +						   "pci8086,2e5e",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x12100 0x0 0x0 0x0 0x0>;
> +					interrupts = <5 1>;
> +				};
> +
> +				sound@6,0 {
> +					compatible = "pci8086,2e5f.2",
> +						   "pci8086,2e5f",
> +						   "pciclass040100",
> +						   "pciclass0401";
> +
> +					reg = <0x13000 0x0 0x0 0x0 0x0>;
> +					interrupts = <6 1>;
> +				};
> +
> +				sound@6,1 {
> +					compatible = "pci8086,2e5f.2",
> +						   "pci8086,2e5f",
> +						   "pciclass040100",
> +						   "pciclass0401";
> +
> +					reg = <0x13100 0x0 0x0 0x0 0x0>;
> +					interrupts = <7 1>;
> +				};
> +
> +				sound@6,2 {
> +					compatible = "pci8086,2e60.2",
> +						   "pci8086,2e60",
> +						   "pciclass040100",
> +						   "pciclass0401";
> +
> +					reg = <0x13200 0x0 0x0 0x0 0x0>;
> +					interrupts = <8 1>;
> +				};
> +
> +				display@8,0 {
> +					compatible = "pci8086,2e61.2",
> +						   "pci8086,2e61",
> +						   "pciclass038000",
> +						   "pciclass0380";
> +
> +					reg = <0x14000 0x0 0x0 0x0 0x0>;
> +					interrupts = <9 1>;
> +				};
> +
> +				display@8,1 {
> +					compatible = "pci8086,2e62.2",
> +						   "pci8086,2e62",
> +						   "pciclass038000",
> +						   "pciclass0380";
> +
> +					reg = <0x14100 0x0 0x0 0x0 0x0>;
> +					interrupts = <10 1>;
> +				};
> +
> +				multimedia@8,2 {
> +					compatible = "pci8086,2e63.2",
> +						   "pci8086,2e63",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x14200 0x0 0x0 0x0 0x0>;
> +					interrupts = <11 1>;
> +				};
> +
> +				entertainment-encryption@9,0 {
> +					compatible = "pci8086,2e64.2",
> +						   "pci8086,2e64",
> +						   "pciclass101000",
> +						   "pciclass1010";
> +
> +					reg = <0x14800 0x0 0x0 0x0 0x0>;
> +					interrupts = <12 1>;
> +				};
> +
> +				localbus@a,0 {
> +					compatible = "pci8086,2e65.2",
> +						   "pci8086,2e65",
> +						   "pciclassff0000",
> +						   "pciclassff00";
> +
> +					reg = <0x15000 0x0 0x0 0x0 0x0>;
> +				};
> +
> +				serial@b,0 {
> +					compatible = "pci8086,2e66.2",
> +						   "pci8086,2e66",
> +						   "pciclass070003",
> +						   "pciclass0700";
> +
> +					reg = <0x15800 0x0 0x0 0x0 0x0>;
> +					interrupts = <14 1>;
> +				};
> +
> +				gpio@b,1 {
> +					compatible = "pci8086,2e67.2",
> +						   "pci8086,2e67",
> +						   "pciclassff0000",
> +						   "pciclassff00";
> +
> +					reg = <0x15900 0x0 0x0 0x0 0x0>;
> +					interrupts = <15 1>;
> +				};
> +
> +				i2c-controller@b,2 {
> +					#address-cells = <2>;
> +					#size-cells = <1>;
> +					compatible = "pci8086,2e68.2",
> +						   "pci8086,2e68",
> +						   "pciclass,ff0000",
> +						   "pciclass,ff00";
> +
> +					reg = <0x15a00 0x0 0x0 0x0 0x0>;
> +					interrupts = <16 1>;

Yeah, this would be an example of a device which must appear in the dt
since there is no way to detect the set of child i2c devices.

> +					ranges = <0 0	0x02000000 0 0xdffe0500	0x100
> +						  1 0	0x02000000 0 0xdffe0600	0x100
> +						  2 0	0x02000000 0 0xdffe0700	0x100>;
> +
> +					i2c@0 {
> +						#address-cells = <1>;
> +						#size-cells = <0>;
> +						compatible = "intel,ce4100-i2c-controller";
> +						reg = <0 0 0x100>;
> +					};
> +
> +					i2c@1 {
> +						#address-cells = <1>;
> +						#size-cells = <0>;
> +						compatible = "intel,ce4100-i2c-controller";
> +						reg = <1 0 0x100>;
> +
> +						gpio@26 {
> +							compatible = "ti,pcf8575";
> +							reg = <0x26>;
> +						};
> +					};
> +
> +					i2c@2 {
> +						#address-cells = <1>;
> +						#size-cells = <0>;
> +						compatible = "intel,ce4100-i2c-controller";
> +						reg = <2 0 0x100>;
> +
> +						gpio@26 {
> +							compatible = "ti,pcf8575";
> +							reg = <0x26>;
> +						};
> +					};
> +				};
> +
> +				smard-card@b,3 {
> +					compatible = "pci8086,2e69.2",
> +						   "pci8086,2e69",
> +						   "pciclass070500",
> +						   "pciclass0705";
> +
> +					reg = <0x15b00 0x0 0x0 0x0 0x0>;
> +					interrupts = <15 1>;
> +				};
> +
> +				spi-controller@b,4 {
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +					compatible =
> +						"pci8086,2e6a.2",
> +						"pci8086,2e6a",
> +						"pciclass,ff0000",
> +						"pciclass,ff00";
> +
> +					reg = <0x15c00 0x0 0x0 0x0 0x0>;
> +					interrupts = <15 1>;

Ditto here.

> +
> +					dac@0 {
> +						compatible = "ti,pcm1755";
> +						reg = <0>;
> +						spi-max-frequency = <115200>;
> +					};
> +
> +					dac@1 {
> +						compatible = "ti,pcm1609a";
> +						reg = <1>;
> +						spi-max-frequency = <115200>;
> +					};
> +
> +					eeprom@2 {
> +						compatible = "atmel,at93c46";
> +						reg = <2>;
> +						spi-max-frequency = <115200>;
> +					};
> +				};
> +
> +				multimedia@b,7 {
> +					compatible = "pci8086,2e6d.2",
> +						   "pci8086,2e6d",
> +						   "pciclassff0000",
> +						   "pciclassff00";
> +
> +					reg = <0x15f00 0x0 0x0 0x0 0x0>;
> +				};
> +
> +				ethernet@c,0 {
> +					compatible = "pci8086,2e6e.2",
> +						   "pci8086,2e6e",
> +						   "pciclass020000",
> +						   "pciclass0200";
> +
> +					reg = <0x16000 0x0 0x0 0x0 0x0>;
> +					interrupts = <21 1>;
> +				};
> +
> +				clock@c,1 {
> +					compatible = "pci8086,2e6f.2",
> +						   "pci8086,2e6f",
> +						   "pciclassff0000",
> +						   "pciclassff00";
> +
> +					reg = <0x16100 0x0 0x0 0x0 0x0>;
> +					interrupts = <3 1>;
> +				};
> +
> +				usb@d,0 {
> +					compatible = "pci8086,2e70.2",
> +						   "pci8086,2e70",
> +						   "pciclass0c0320",
> +						   "pciclass0c03";
> +
> +					reg = <0x16800 0x0 0x0 0x0 0x0>;
> +					interrupts = <22 3>;
> +				};
> +
> +				usb@d,1 {
> +					compatible = "pci8086,2e70.2",
> +						   "pci8086,2e70",
> +						   "pciclass0c0320",
> +						   "pciclass0c03";
> +
> +					reg = <0x16900 0x0 0x0 0x0 0x0>;
> +					interrupts = <22 3>;
> +				};
> +
> +				sata@e,0 {
> +					compatible = "pci8086,2e71.0",
> +						   "pci8086,2e71",
> +						   "pciclass010601",
> +						   "pciclass0106";
> +
> +					reg = <0x17000 0x0 0x0 0x0 0x0>;
> +					interrupts = <23 3>;
> +				};
> +
> +				flash@f,0 {
> +					compatible = "pci8086,701.1",
> +						   "pci8086,701",
> +						   "pciclass050100",
> +						   "pciclass0501";
> +
> +					reg = <0x17800 0x0 0x0 0x0 0x0>;
> +					interrupts = <13 1>;
> +				};
> +
> +				entertainment-encryption@10,0 {
> +					compatible = "pci8086,702.1",
> +						   "pci8086,702",
> +						   "pciclass101000",
> +						   "pciclass1010";
> +
> +					reg = <0x18000 0x0 0x0 0x0 0x0>;
> +				};
> +
> +				co-processor@11,0 {
> +					compatible = "pci8086,703.1",
> +						   "pci8086,703",
> +						   "pciclass0b4000",
> +						   "pciclass0b40";
> +
> +					reg = <0x18800 0x0 0x0 0x0 0x0>;
> +					interrupts = <1 1>;
> +				};
> +
> +				multimedia@12,0 {
> +					compatible = "pci8086,704.0",
> +						   "pci8086,704",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x19000 0x0 0x0 0x0 0x0>;
> +				};
> +			};
> +
> +			isa@1f,0 {
> +				#address-cells = <2>;
> +				#size-cells = <1>;
> +				compatible = "isa";
> +				ranges = <1 0 0 0 0 0x100>;
> +
> +				rtc@70 {
> +					compatible = "intel,ce4100-rtc", "motorola,mc146818";
> +					interrupts = <8 3>;
> +					interrupt-parent = <&ioapic1>;
> +					ctrl-reg = <2>;
> +					freq-reg = <0x26>;
> +					reg = <1 0x70 2>;
> +				};
> +			};
> +		};
> +	};
> +};
> -- 
> 1.7.3.2
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Sebastian Andrzej Siewior
	<bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: sodaville-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH TIP v2 03/14] x86/dtb: Add a device tree for CE4100
Date: Wed, 16 Feb 2011 14:44:28 -0700	[thread overview]
Message-ID: <20110216214428.GD22837@angua.secretlab.ca> (raw)
In-Reply-To: <20110202185841.GA28674-Hfxr4Dq0UpYb1SvskN2V4Q@public.gmane.org>

On Thu, Feb 03, 2011 at 12:28:41AM +0530, Sebastian Andrzej Siewior wrote:
> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> Signed-off-by: Dirk Brandewie <dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> - intel,ce4100-immr become intel,ce4100-cp. cp stands for core
>   peripherals. The Atom data sheet talks here about ACPI devices. Since
>   we don't have ACPI this does not apply here.
> - The interrupt map is gone. There are now plenty of device nodes.
> - The "unit address string" got fixed, it uses not DD,V format.

It's actually useful to have this revision history as part of the
patch description itself so that when it is committed we've got a
record of exactly which version got committed.

g.

> 
>  arch/x86/platform/ce4100/falconfalls.dts |  424 ++++++++++++++++++++++++++++++
>  1 files changed, 424 insertions(+), 0 deletions(-)
>  create mode 100644 arch/x86/platform/ce4100/falconfalls.dts
> 
> diff --git a/arch/x86/platform/ce4100/falconfalls.dts b/arch/x86/platform/ce4100/falconfalls.dts
> new file mode 100644
> index 0000000..e888657
> --- /dev/null
> +++ b/arch/x86/platform/ce4100/falconfalls.dts
> @@ -0,0 +1,424 @@
> +/*
> + * CE4100 on Falcon Falls
> + *
> + * (c) Copyright 2010 Intel Corporation
> + *
> + * 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; version 2 of the License.
> + */
> +/dts-v1/;
> +/ {
> +	model = "intel,falconfalls";
> +	compatible = "intel,falconfalls";
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			compatible = "intel,ce4100";
> +			reg = <0>;
> +			lapic = <&lapic0>;
> +		};
> +	};
> +
> +	soc@0 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "intel,ce4100-cp";

You *must* include documentation for each of these new compatible
values before merging this patch.  At the very least it acts as a
placeholder and describes exactly what the string describes.

> +		ranges;
> +
> +		ioapic1: interrupt-controller@fec00000 {
> +			#interrupt-cells = <2>;
> +			compatible = "intel,ioapic-ce4100", "intel,ioapic";

"intel,ioapic" is probably too generic and can be dropped.  Newer
devices can claim compatibility with "intel,ioapic-ce4100" if they are
indeed compatible so that device drivers don't need to be modified.
It is better to anchor compatible values to real implementations that
try to come up with 'generic' or wildcard strings.  Ditto through the
rest of the file.

"intel,ce4100-ioapic" (instead of intel,ioapic-ce4100) would follow
current convention better of specifying the chip first, followed by
the on-chip device.

> +			interrupt-controller;
> +			reg = <0xfec00000 0x1000>;
> +		};
> +
> +		timer@fed00000 {
> +			compatible = "intel,hpet-ce4100", "intel,hpet";
> +			reg = <0xfed00000 0x200>;
> +		};
> +
> +		lapic0: interrupt-controller@fee00000 {
> +			compatible = "intel,lapic-ce4100", "intel,lapic";
> +			reg = <0xfee00000 0x1000>;
> +		};
> +
> +		pci@3fc {
> +			#address-cells = <3>;
> +			#interrupt-cells = <1>;
> +			#size-cells = <2>;
> +			compatible = "intel,ce4100-pci", "pci";
> +			device_type = "pci";
> +			bus-range = <0 0>;
> +			ranges = <0x2000000 0 0xbffff000 0xbffff000 0 0x1000
> +				  0x2000000 0 0xdffe0000 0xdffe0000 0 0x1000
> +				  0x0000000 0 0x0	 0x0	    0 0x100>;
> +
> +			/* Secondary IO-APIC */
> +			ioapic2: interrupt-controller@0,1 {
> +				#interrupt-cells = <2>;
> +				compatible = "intel,ioapic-ce4100", "intel,ioapic";
> +				interrupt-controller;
> +				reg = <0x100 0x0 0x0 0x0 0x0>;
> +				assigned-addresses = <0x02000000 0x0 0xbffff000 0x0 0x1000>;
> +			};
> +
> +			pci@1,0 {
> +				#address-cells = <3>;
> +				#interrupt-cells = <1>;
> +				#size-cells = <2>;
> +				compatible = "intel,ce4100-pci", "pci";
> +				device_type = "pci";
> +				bus-range = <1 1>;
> +				ranges = <0x2000000 0 0xdffe0000 0x2000000 0 0xdffe0000 0 0x1000>;
> +
> +				interrupt-parent = <&ioapic2>;
> +
> +				display@2,0 {
> +					compatible = "pci8086,2e5b.2",
> +						   "pci8086,2e5b",
> +						   "pciclass038000",
> +						   "pciclass0380";
> +
> +					reg = <0x11000 0x0 0x0 0x0 0x0>;
> +					interrupts = <0 1>;
> +				};

Here's where things get a little sticky for PCI child devices
(probably should have thought about this earlier, sorry).  Are these
devices runtime detectable?  ie. does reading the PCI BARs and irq
configuration registers reflect reality?

In general, if something can be *reliably* detected then it should not
be listed in the device tree.  However, if there is some horrid gotcha
that prevents it being detected reliably, then it definitely should
appear here.

I cannot answer this question for you since I don't know the hardware.
It's a judgement call that you'll need to make on whether or not these
PCI (or pseudo pci?) devices should be listed in the dt.

One of the things that does need to be improved is partial probing of
PCI busses so that only the messy PCI devices get listed in the device
tree, and the rest of the devices can get detected in the normal
manner.

> +
> +				multimedia@3,0 {
> +					compatible = "pci8086,2e5c.2",
> +						   "pci8086,2e5c",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x11800 0x0 0x0 0x0 0x0>;
> +					interrupts = <2 1>;
> +				};
> +
> +				multimedia@4,0 {
> +					compatible = "pci8086,2e5d.2",
> +						   "pci8086,2e5d",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x12000 0x0 0x0 0x0 0x0>;
> +					interrupts = <4 1>;
> +				};
> +
> +				multimedia@4,1 {
> +					compatible = "pci8086,2e5e.2",
> +						   "pci8086,2e5e",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x12100 0x0 0x0 0x0 0x0>;
> +					interrupts = <5 1>;
> +				};
> +
> +				sound@6,0 {
> +					compatible = "pci8086,2e5f.2",
> +						   "pci8086,2e5f",
> +						   "pciclass040100",
> +						   "pciclass0401";
> +
> +					reg = <0x13000 0x0 0x0 0x0 0x0>;
> +					interrupts = <6 1>;
> +				};
> +
> +				sound@6,1 {
> +					compatible = "pci8086,2e5f.2",
> +						   "pci8086,2e5f",
> +						   "pciclass040100",
> +						   "pciclass0401";
> +
> +					reg = <0x13100 0x0 0x0 0x0 0x0>;
> +					interrupts = <7 1>;
> +				};
> +
> +				sound@6,2 {
> +					compatible = "pci8086,2e60.2",
> +						   "pci8086,2e60",
> +						   "pciclass040100",
> +						   "pciclass0401";
> +
> +					reg = <0x13200 0x0 0x0 0x0 0x0>;
> +					interrupts = <8 1>;
> +				};
> +
> +				display@8,0 {
> +					compatible = "pci8086,2e61.2",
> +						   "pci8086,2e61",
> +						   "pciclass038000",
> +						   "pciclass0380";
> +
> +					reg = <0x14000 0x0 0x0 0x0 0x0>;
> +					interrupts = <9 1>;
> +				};
> +
> +				display@8,1 {
> +					compatible = "pci8086,2e62.2",
> +						   "pci8086,2e62",
> +						   "pciclass038000",
> +						   "pciclass0380";
> +
> +					reg = <0x14100 0x0 0x0 0x0 0x0>;
> +					interrupts = <10 1>;
> +				};
> +
> +				multimedia@8,2 {
> +					compatible = "pci8086,2e63.2",
> +						   "pci8086,2e63",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x14200 0x0 0x0 0x0 0x0>;
> +					interrupts = <11 1>;
> +				};
> +
> +				entertainment-encryption@9,0 {
> +					compatible = "pci8086,2e64.2",
> +						   "pci8086,2e64",
> +						   "pciclass101000",
> +						   "pciclass1010";
> +
> +					reg = <0x14800 0x0 0x0 0x0 0x0>;
> +					interrupts = <12 1>;
> +				};
> +
> +				localbus@a,0 {
> +					compatible = "pci8086,2e65.2",
> +						   "pci8086,2e65",
> +						   "pciclassff0000",
> +						   "pciclassff00";
> +
> +					reg = <0x15000 0x0 0x0 0x0 0x0>;
> +				};
> +
> +				serial@b,0 {
> +					compatible = "pci8086,2e66.2",
> +						   "pci8086,2e66",
> +						   "pciclass070003",
> +						   "pciclass0700";
> +
> +					reg = <0x15800 0x0 0x0 0x0 0x0>;
> +					interrupts = <14 1>;
> +				};
> +
> +				gpio@b,1 {
> +					compatible = "pci8086,2e67.2",
> +						   "pci8086,2e67",
> +						   "pciclassff0000",
> +						   "pciclassff00";
> +
> +					reg = <0x15900 0x0 0x0 0x0 0x0>;
> +					interrupts = <15 1>;
> +				};
> +
> +				i2c-controller@b,2 {
> +					#address-cells = <2>;
> +					#size-cells = <1>;
> +					compatible = "pci8086,2e68.2",
> +						   "pci8086,2e68",
> +						   "pciclass,ff0000",
> +						   "pciclass,ff00";
> +
> +					reg = <0x15a00 0x0 0x0 0x0 0x0>;
> +					interrupts = <16 1>;

Yeah, this would be an example of a device which must appear in the dt
since there is no way to detect the set of child i2c devices.

> +					ranges = <0 0	0x02000000 0 0xdffe0500	0x100
> +						  1 0	0x02000000 0 0xdffe0600	0x100
> +						  2 0	0x02000000 0 0xdffe0700	0x100>;
> +
> +					i2c@0 {
> +						#address-cells = <1>;
> +						#size-cells = <0>;
> +						compatible = "intel,ce4100-i2c-controller";
> +						reg = <0 0 0x100>;
> +					};
> +
> +					i2c@1 {
> +						#address-cells = <1>;
> +						#size-cells = <0>;
> +						compatible = "intel,ce4100-i2c-controller";
> +						reg = <1 0 0x100>;
> +
> +						gpio@26 {
> +							compatible = "ti,pcf8575";
> +							reg = <0x26>;
> +						};
> +					};
> +
> +					i2c@2 {
> +						#address-cells = <1>;
> +						#size-cells = <0>;
> +						compatible = "intel,ce4100-i2c-controller";
> +						reg = <2 0 0x100>;
> +
> +						gpio@26 {
> +							compatible = "ti,pcf8575";
> +							reg = <0x26>;
> +						};
> +					};
> +				};
> +
> +				smard-card@b,3 {
> +					compatible = "pci8086,2e69.2",
> +						   "pci8086,2e69",
> +						   "pciclass070500",
> +						   "pciclass0705";
> +
> +					reg = <0x15b00 0x0 0x0 0x0 0x0>;
> +					interrupts = <15 1>;
> +				};
> +
> +				spi-controller@b,4 {
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +					compatible =
> +						"pci8086,2e6a.2",
> +						"pci8086,2e6a",
> +						"pciclass,ff0000",
> +						"pciclass,ff00";
> +
> +					reg = <0x15c00 0x0 0x0 0x0 0x0>;
> +					interrupts = <15 1>;

Ditto here.

> +
> +					dac@0 {
> +						compatible = "ti,pcm1755";
> +						reg = <0>;
> +						spi-max-frequency = <115200>;
> +					};
> +
> +					dac@1 {
> +						compatible = "ti,pcm1609a";
> +						reg = <1>;
> +						spi-max-frequency = <115200>;
> +					};
> +
> +					eeprom@2 {
> +						compatible = "atmel,at93c46";
> +						reg = <2>;
> +						spi-max-frequency = <115200>;
> +					};
> +				};
> +
> +				multimedia@b,7 {
> +					compatible = "pci8086,2e6d.2",
> +						   "pci8086,2e6d",
> +						   "pciclassff0000",
> +						   "pciclassff00";
> +
> +					reg = <0x15f00 0x0 0x0 0x0 0x0>;
> +				};
> +
> +				ethernet@c,0 {
> +					compatible = "pci8086,2e6e.2",
> +						   "pci8086,2e6e",
> +						   "pciclass020000",
> +						   "pciclass0200";
> +
> +					reg = <0x16000 0x0 0x0 0x0 0x0>;
> +					interrupts = <21 1>;
> +				};
> +
> +				clock@c,1 {
> +					compatible = "pci8086,2e6f.2",
> +						   "pci8086,2e6f",
> +						   "pciclassff0000",
> +						   "pciclassff00";
> +
> +					reg = <0x16100 0x0 0x0 0x0 0x0>;
> +					interrupts = <3 1>;
> +				};
> +
> +				usb@d,0 {
> +					compatible = "pci8086,2e70.2",
> +						   "pci8086,2e70",
> +						   "pciclass0c0320",
> +						   "pciclass0c03";
> +
> +					reg = <0x16800 0x0 0x0 0x0 0x0>;
> +					interrupts = <22 3>;
> +				};
> +
> +				usb@d,1 {
> +					compatible = "pci8086,2e70.2",
> +						   "pci8086,2e70",
> +						   "pciclass0c0320",
> +						   "pciclass0c03";
> +
> +					reg = <0x16900 0x0 0x0 0x0 0x0>;
> +					interrupts = <22 3>;
> +				};
> +
> +				sata@e,0 {
> +					compatible = "pci8086,2e71.0",
> +						   "pci8086,2e71",
> +						   "pciclass010601",
> +						   "pciclass0106";
> +
> +					reg = <0x17000 0x0 0x0 0x0 0x0>;
> +					interrupts = <23 3>;
> +				};
> +
> +				flash@f,0 {
> +					compatible = "pci8086,701.1",
> +						   "pci8086,701",
> +						   "pciclass050100",
> +						   "pciclass0501";
> +
> +					reg = <0x17800 0x0 0x0 0x0 0x0>;
> +					interrupts = <13 1>;
> +				};
> +
> +				entertainment-encryption@10,0 {
> +					compatible = "pci8086,702.1",
> +						   "pci8086,702",
> +						   "pciclass101000",
> +						   "pciclass1010";
> +
> +					reg = <0x18000 0x0 0x0 0x0 0x0>;
> +				};
> +
> +				co-processor@11,0 {
> +					compatible = "pci8086,703.1",
> +						   "pci8086,703",
> +						   "pciclass0b4000",
> +						   "pciclass0b40";
> +
> +					reg = <0x18800 0x0 0x0 0x0 0x0>;
> +					interrupts = <1 1>;
> +				};
> +
> +				multimedia@12,0 {
> +					compatible = "pci8086,704.0",
> +						   "pci8086,704",
> +						   "pciclass048000",
> +						   "pciclass0480";
> +
> +					reg = <0x19000 0x0 0x0 0x0 0x0>;
> +				};
> +			};
> +
> +			isa@1f,0 {
> +				#address-cells = <2>;
> +				#size-cells = <1>;
> +				compatible = "isa";
> +				ranges = <1 0 0 0 0 0x100>;
> +
> +				rtc@70 {
> +					compatible = "intel,ce4100-rtc", "motorola,mc146818";
> +					interrupts = <8 3>;
> +					interrupt-parent = <&ioapic1>;
> +					ctrl-reg = <2>;
> +					freq-reg = <0x26>;
> +					reg = <1 0x70 2>;
> +				};
> +			};
> +		};
> +	};
> +};
> -- 
> 1.7.3.2
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

  parent reply	other threads:[~2011-02-16 21:44 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-24  4:28 Device tree on x86, part v3 Sebastian Andrzej Siewior
2011-01-24  4:28 ` Sebastian Andrzej Siewior
2011-01-24  4:28 ` [PATCH TIP 01/14] x86/e820: remove conditional early mapping in parse_e820_ext Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-02-03 20:57   ` Grant Likely
2011-01-24  4:28 ` [PATCH TIP 02/14] x86: Add device tree support Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-01-24  4:34   ` Sebastian Andrzej Siewior
2011-01-24  4:34     ` Sebastian Andrzej Siewior
2011-02-16 21:27     ` Grant Likely
2011-02-16 21:27       ` Grant Likely
2011-02-17 11:05       ` [sodaville] " Sebastian Andrzej Siewior
2011-02-17 11:05         ` Sebastian Andrzej Siewior
2011-02-16 21:26   ` Grant Likely
2011-02-17 11:03     ` Sebastian Andrzej Siewior
2011-02-17 11:03       ` Sebastian Andrzej Siewior
2011-02-16 21:31   ` Grant Likely
2011-02-16 21:31     ` Grant Likely
2011-02-17 11:31     ` [sodaville] " Sebastian Andrzej Siewior
2011-02-17 11:31       ` Sebastian Andrzej Siewior
2011-02-17 17:02       ` Grant Likely
2011-01-24  4:28 ` [PATCH TIP 03/14] x86/dtb: Add a device tree for CE4100 Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-01-27  5:00   ` David Gibson
2011-01-27  5:00     ` David Gibson
2011-01-27  9:11     ` Sebastian Andrzej Siewior
2011-01-27  9:11       ` Sebastian Andrzej Siewior
2011-02-03 20:59       ` Grant Likely
2011-02-03 21:32         ` Mitch Bradley
2011-02-03 21:32           ` Mitch Bradley
2011-02-04  9:40           ` Sebastian Andrzej Siewior
2011-02-04  9:40             ` Sebastian Andrzej Siewior
2011-02-02 18:58     ` [PATCH TIP v2 " Sebastian Andrzej Siewior
2011-02-02 18:58       ` Sebastian Andrzej Siewior
2011-02-03 21:07       ` Grant Likely
2011-02-03 21:07         ` Grant Likely
2011-02-04 10:06         ` Sebastian Andrzej Siewior
2011-02-04 10:06           ` Sebastian Andrzej Siewior
2011-02-16 21:44       ` Grant Likely [this message]
2011-02-16 21:44         ` Grant Likely
2011-02-22 11:21         ` [sodaville] " Sebastian Andrzej Siewior
2011-02-22 11:21           ` Sebastian Andrzej Siewior
2011-01-24  4:28 ` [PATCH TIP 04/14] x86/dtb: add irq domain abstraction Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-01-24  4:28 ` [PATCH TIP 05/14] x86/dtb: add early parsing of APIC and IO APIC Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-02-16 21:47   ` Grant Likely
2011-02-16 21:47     ` Grant Likely
2011-01-24  4:28 ` [PATCH TIP 06/14] x86/dtb: add support hpet Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-01-24  4:28 ` [PATCH OF 07/14] of: move of_irq_map_pci() into generic code Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-02-10 13:57   ` Michal Simek
2011-02-16 21:53   ` Grant Likely
2011-02-16 21:53     ` Grant Likely
2011-02-17  7:49     ` Michal Simek
2011-02-17  7:49       ` Michal Simek
2011-02-17  7:49       ` Michal Simek
2011-01-24  4:28 ` [PATCH TIP 08/14] x86/dtb: add support for PCI devices backed by dtb nodes Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-02-16 21:59   ` Grant Likely
2011-02-16 21:59     ` Grant Likely
2011-02-22 11:21     ` [sodaville] " Sebastian Andrzej Siewior
2011-02-22 11:21       ` Sebastian Andrzej Siewior
2011-01-24  4:28 ` [PATCH TIP 09/14] x86/dtb: Add generic bus probe Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-02-04 10:21   ` [PATCH v2 " Sebastian Andrzej Siewior
2011-02-04 10:21     ` Sebastian Andrzej Siewior
2011-02-16 22:04     ` Grant Likely
2011-02-16 22:04       ` Grant Likely
2011-01-24  4:28 ` [PATCH TIP 10/14] x86/ioapic: Add OF bindings for IO-APIC Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-02-16 22:04   ` Grant Likely
2011-01-24  4:28 ` [PATCH TIP 11/14] x86/ce4100: use OF for ioapic Sebastian Andrzej Siewior
2011-01-24  4:28   ` Sebastian Andrzej Siewior
2011-01-24  4:29 ` [PATCH OF 12/14] x86/rtc: don't register rtc if we the DT blob Sebastian Andrzej Siewior
2011-01-24  4:29   ` Sebastian Andrzej Siewior
2011-02-16 22:08   ` Grant Likely
2011-02-16 22:08     ` Grant Likely
2011-02-16 22:09   ` Grant Likely
2011-02-16 22:09     ` Grant Likely
2011-02-17 13:13     ` [sodaville] " Sebastian Andrzej Siewior
2011-02-17 13:13       ` Sebastian Andrzej Siewior
2011-01-24  4:29 ` [PATCH OF 13/14] rtc/cmos: add OF bindings Sebastian Andrzej Siewior
2011-01-24  4:29   ` Sebastian Andrzej Siewior
2011-01-24  4:38   ` Sebastian Andrzej Siewior
2011-01-24  4:38     ` Sebastian Andrzej Siewior
2011-02-16 22:11   ` Grant Likely
2011-02-16 22:11     ` Grant Likely
2011-02-17 13:26     ` [sodaville] " Sebastian Andrzej Siewior
2011-02-17 13:26       ` Sebastian Andrzej Siewior
2011-02-17 16:46       ` Grant Likely
2011-01-24  4:29 ` [PATCH TIP 14/14] x86/pci: remove warning Sebastian Andrzej Siewior
2011-01-24  4:29   ` Sebastian Andrzej Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110216214428.GD22837@angua.secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=bigeasy@linutronix.de \
    --cc=david@gibson.dropbear.id.au \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sodaville@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.