Patchwork [12/14] ARM: tegra: tec: Add PCIe support

login
register
mail settings
Submitter Thierry Reding
Date Jan. 9, 2013, 8:43 p.m.
Message ID <1357764194-12677-13-git-send-email-thierry.reding@avionic-design.de>
Download mbox | patch
Permalink /patch/210854/
State Not Applicable
Headers show

Comments

Thierry Reding - Jan. 9, 2013, 8:43 p.m.
Enable the first PCIe root port which is connected to an FPGA on the
Tamonten Evaluation Carrier and add device nodes for each of the PCI
endpoints available in the standard configuration.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
 arch/arm/boot/dts/tegra20-tec.dts | 198 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 198 insertions(+)
Stephen Warren - Jan. 11, 2013, 12:22 a.m.
On 01/09/2013 01:43 PM, Thierry Reding wrote:
> Enable the first PCIe root port which is connected to an FPGA on the
> Tamonten Evaluation Carrier and add device nodes for each of the PCI
> endpoints available in the standard configuration.

> diff --git a/arch/arm/boot/dts/tegra20-tec.dts b/arch/arm/boot/dts/tegra20-tec.dts

> +	pcie-controller {
> +		vdd-supply = <&pci_vdd_reg>;
> +		pex-clk-supply = <&pci_clk_reg>;
> +		status = "okay";

Sorry this is also really picky. I'd prefer properties that exist in
/include/d files and are overidden here to appear first, followed by new
properties. In other words, move the status property to be first. I
believe/hope all the other (Tegra) .dts files follow this convention.

> +		pci@1,0 {
> +			bus-range = <0x01 0x0a>;
> +			status = "okay";
> +
> +			pci@0,0 {
> +				reg = <0x010000 0 0 0 0>;

Hmm. The unit address in that node name doesn't match the address in the
reg property, although I suppose there's nothing we can do about it
since those formats are both defined by the standard PCI binding?

What do the numbers "0,0" represent here; device/function? Is the same
true for the "0,0" in the child nodes?

> +				bus-range = <0x02 0x0a>;
> +
> +				compatible = "plda,pcie";

Are there DT binding documents for all these devices; plda,pcie,
ad,pcie, ad,pcie-test, etc.?

> +				pci@4,0 {
> +					reg = <0x022000 0 0 0 0>;
> +					bus-range = <0x07 0x07>;
> +
> +					compatible = "ad,pcie";
> +					device_type = "pci";
> +
> +					#address-cells = <3>;
> +					#size-cells = <2>;
> +
> +					pci@0,0 {
> +						compatible = "opencores,uart";
> +						reg = <0x070000 0 0 0 0>;
> +					};
> +				};

Do you need to include a node for the UART; I can see you need to for
the SPI/I2C controllers so you can instantiate the appropriate devices
on non-probe-able buses, but I think you can just let regular PCI device
probing find the UART, Ethernet MAC, etc., can't you?
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thierry Reding - Jan. 11, 2013, 4:34 a.m.
On Thu, Jan 10, 2013 at 05:22:30PM -0700, Stephen Warren wrote:
> On 01/09/2013 01:43 PM, Thierry Reding wrote:
> > Enable the first PCIe root port which is connected to an FPGA on the
> > Tamonten Evaluation Carrier and add device nodes for each of the PCI
> > endpoints available in the standard configuration.
> 
> > diff --git a/arch/arm/boot/dts/tegra20-tec.dts b/arch/arm/boot/dts/tegra20-tec.dts
> 
> > +	pcie-controller {
> > +		vdd-supply = <&pci_vdd_reg>;
> > +		pex-clk-supply = <&pci_clk_reg>;
> > +		status = "okay";
> 
> Sorry this is also really picky. I'd prefer properties that exist in
> /include/d files and are overidden here to appear first, followed by new
> properties. In other words, move the status property to be first. I
> believe/hope all the other (Tegra) .dts files follow this convention.

Okay, I'll fix that.

> > +		pci@1,0 {
> > +			bus-range = <0x01 0x0a>;
> > +			status = "okay";
> > +
> > +			pci@0,0 {
> > +				reg = <0x010000 0 0 0 0>;
> 
> Hmm. The unit address in that node name doesn't match the address in the
> reg property, although I suppose there's nothing we can do about it
> since those formats are both defined by the standard PCI binding?

That's the standard encoding for unit addresses for PCI devices. The
first cell in the reg property encodes bus/device/function (amongst
other things) and the node name is supposed to be pci@<dev>,<fn>.

> What do the numbers "0,0" represent here; device/function? Is the same
> true for the "0,0" in the child nodes?

Yes, exactly.

> > +				bus-range = <0x02 0x0a>;
> > +
> > +				compatible = "plda,pcie";
> 
> Are there DT binding documents for all these devices; plda,pcie,
> ad,pcie, ad,pcie-test, etc.?

No. To be honest I don't quite know how to handle this. For the PLDA
things aren't so bad since it has a proper PCI ID, but the other cores
don't since they are custom IP or taken from opencores.org and made
available via PCIe. We're still in the process of obtaining our own PCI
vendor ID so that these can be properly assigned.

Also, as you have guessed, most of these are not required. I just wanted
to include them here for completeness (and maybe reference in case
somebody else, myself included, needs a working example to base other
work on).

> > +				pci@4,0 {
> > +					reg = <0x022000 0 0 0 0>;
> > +					bus-range = <0x07 0x07>;
> > +
> > +					compatible = "ad,pcie";
> > +					device_type = "pci";
> > +
> > +					#address-cells = <3>;
> > +					#size-cells = <2>;
> > +
> > +					pci@0,0 {
> > +						compatible = "opencores,uart";
> > +						reg = <0x070000 0 0 0 0>;
> > +					};
> > +				};
> 
> Do you need to include a node for the UART; I can see you need to for
> the SPI/I2C controllers so you can instantiate the appropriate devices
> on non-probe-able buses, but I think you can just let regular PCI device
> probing find the UART, Ethernet MAC, etc., can't you?

Yes, that's correct. Only SPI and I2C actually require these nodes. I'm
not sure if the PCI binding requires all nodes to be present or not.
Other examples I've seen (e.g. arch/x86/platform/ce4100/falconfalls.dts)
contain nodes for everything, most of which don't seem to be necessary
for things to work.

One other thing that I've seen is the usage of the more standard pci*
values for the compatible property. None of them are very descriptive
which is why I used a vendor,device type of value instead.

Going over the PCI binding again, however, it looks like there's no
requirement to make the node name pci@dev,fn and pci can be anything.
Making it uart@0,0 and then adjusting the compatible value to be as the
binding requires could be an option. In that case I suppose even the
bindings documentation shouldn't be necessary.

That doesn't cover the nodes where non-standard properties are needed
(I2C and SPI), which do need binding documents. I wouldn't know how to
name them, though. I'm not sure going with the current convention would
be any good since it'll be hard to find the right document if you have
to look it up by matching vendor and device IDs or PCI class.

Thierry

Patch

diff --git a/arch/arm/boot/dts/tegra20-tec.dts b/arch/arm/boot/dts/tegra20-tec.dts
index 25f70ee..b75f979 100644
--- a/arch/arm/boot/dts/tegra20-tec.dts
+++ b/arch/arm/boot/dts/tegra20-tec.dts
@@ -60,6 +60,204 @@ 
 		};
 	};
 
+	pcie-controller {
+		vdd-supply = <&pci_vdd_reg>;
+		pex-clk-supply = <&pci_clk_reg>;
+		status = "okay";
+
+		pci@1,0 {
+			bus-range = <0x01 0x0a>;
+			status = "okay";
+
+			pci@0,0 {
+				reg = <0x010000 0 0 0 0>;
+				bus-range = <0x02 0x0a>;
+
+				compatible = "plda,pcie";
+				device_type = "pci";
+
+				#address-cells = <3>;
+				#size-cells = <2>;
+
+				pci@0,0 {
+					reg = <0x020000 0 0 0 0>;
+					bus-range = <0x03 0x03>;
+
+					compatible = "ad,pcie";
+					device_type = "pci";
+
+					#address-cells = <3>;
+					#size-cells = <2>;
+
+					pci-test-ep@0,0 {
+						compatible = "ad,pcietest";
+						reg = <0x030000 0 0 0 0>;
+					};
+				};
+
+				pci@1,0 {
+					reg = <0x020800 0 0 0 0>;
+					bus-range = <0x04 0x04>;
+
+					compatible = "ad,pcie";
+					device_type = "pci";
+
+					#address-cells = <3>;
+					#size-cells = <2>;
+
+					pci@0,0 {
+						compatible = "opencores,spi";
+						reg = <0x040000 0 0 0 0>;
+
+						#address-cells = <1>;
+						#size-cells = <0>;
+
+						clock-frequency = <66000000>;
+
+						m25p80@0 {
+							compatible = "m25p80";
+							reg = <0>;
+
+							spi-max-frequency = <25000000>;
+
+							#address-cells = <1>;
+							#size-cells = <1>;
+
+							partition@0 {
+								reg = <0x00000000 0x00400000>;
+								label = "FPGA";
+							};
+
+							partition@400000 {
+								reg = <0x00400000 0x00400000>;
+								label = "FPGA (gold)";
+								read-only;
+							};
+						};
+					};
+				};
+
+				pci@2,0 {
+					reg = <0x021000 0 0 0 0>;
+					bus-range = <0x05 0x05>;
+
+					compatible = "ad,pcie";
+					device_type = "pci";
+
+					#address-cells = <3>;
+					#size-cells = <2>;
+
+					pci-i2c-ep@0,0 {
+						compatible = "opencores,i2c";
+						reg = <0x050000 0 0 0 0>;
+
+						clock-frequency = <66000000>;
+						reg-io-width = <4>;
+						reg-shift = <3>;
+					};
+				};
+
+				pci@3,0 {
+					reg = <0x021800 0 0 0 0>;
+					bus-range = <0x06 0x06>;
+
+					compatible = "ad,pcie";
+					device_type = "pci";
+
+					#address-cells = <3>;
+					#size-cells = <2>;
+
+					pci@0,0 {
+						compatible = "ad,gpio-ad64p";
+						reg = <0x060000 0 0 0 0>;
+
+						gpio-controller;
+						#gpio-cells = <2>;
+
+						interrupt-controller;
+						#interrupt-cells = <2>;
+					};
+				};
+
+				pci@4,0 {
+					reg = <0x022000 0 0 0 0>;
+					bus-range = <0x07 0x07>;
+
+					compatible = "ad,pcie";
+					device_type = "pci";
+
+					#address-cells = <3>;
+					#size-cells = <2>;
+
+					pci@0,0 {
+						compatible = "opencores,uart";
+						reg = <0x070000 0 0 0 0>;
+					};
+				};
+
+				pci@5,0 {
+					reg = <0x022800 0 0 0 0>;
+					bus-range = <0x08 0x08>;
+
+					compatible = "ad,pcie";
+					device_type = "pci";
+
+					#address-cells = <3>;
+					#size-cells = <2>;
+
+					pci@0,0 {
+						compatible = "opencores,ethmac";
+						reg = <0x080000 0 0 0 0>;
+					};
+				};
+
+				pci@6,0 {
+					reg = <0x023000 0 0 0 0>;
+					bus-range = <0x09 0x09>;
+
+					compatible = "ad,pcie";
+					device_type = "pci";
+
+					#address-cells = <3>;
+					#size-cells = <2>;
+
+					pci@0,0 {
+						compatible = "opencores,can";
+						reg = <0x090000 0 0 0 0>;
+					};
+				};
+
+				pci@7,0 {
+					reg = <0x023800 0 0 0 0>;
+					bus-range = <0x0a 0x0a>;
+
+					compatible = "ad,pcie";
+					device_type = "pci";
+
+					#address-cells = <3>;
+					#size-cells = <2>;
+
+					pci@0,0 {
+						compatible = "opencores,can";
+						reg = <0x0a0000 0 0 0 0>;
+					};
+				};
+			};
+		};
+	};
+
+	regulators {
+		pci_vdd_reg: regulator@1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "vdd_1v05";
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			gpio = <&pmic 2 0>;
+			enable-active-high;
+		};
+	};
+
 	sound {
 		compatible = "ad,tegra-audio-wm8903-tec",
 			     "nvidia,tegra-audio-wm8903";