ARM: DT: tegra: Add Colibri T20 512MB COM

This adds the device tree include file for the Toradex Colibri T20 Computer on Module (COM). It's only valid for the 512MB RAM version of the module, as the 256MB version needs different EMC tables and flash configuration. To make this clear the suffix -512 was added to the board compatible string.

The Colibri T20 uses a Tegra2 SoC and has onboard USB Ethernet and AC97 sound.

Still some things like onboard NAND support missing, but should be a good base for further development.

arch/arm/boot/dts/tegra20-colibri-512.dtsi +23 -0

+	i2c at 7000c000 {
+		clock-frequency = <400000>;
+	};
+
+	i2c_ddc: i2c at 7000c400 {
+		clock-frequency = <100000>;
+	};
+
+	i2c at 7000c500 {
+		clock-frequency = <400000>;
+	};
 
+	serial at 70006000 {
+		clock-frequency = <216000000>;
+	};
+
+	serial at 70006300 {
+		clock-frequency = <216000000>;
+	};
+
+	usb at c5000000 {
+		dr_mode = "otg";
+	};
+

Quoted 11 lines

This adds the device tree include file for the Toradex Colibri T20 Computer on Module (COM). It's only valid for the 512MB RAM version of the module, as the 256MB version needs different EMC tables and flash configuration. To make this clear the suffix -512 was added to the board compatible string.

The Colibri T20 uses a Tegra2 SoC and has onboard USB Ethernet and AC97 sound.

Still some things like onboard NAND support missing, but should be a good base for further development.

arch/arm/boot/dts/tegra20-colibri-512.dtsi line 359

Quoted 4 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi +2 -0

 
+		temperature-sensor at 4c {
+			compatible = "national,lm95245";

You should probably add that compatible value to Documentation/devicetree/bindings/i2c/trivial-devices.txt.

Quoted 24 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi +23 -0

+	i2c at 7000c000 {
+		clock-frequency = <400000>;
+	};
+
+	i2c_ddc: i2c at 7000c400 {
+		clock-frequency = <100000>;
+	};
+
+	i2c at 7000c500 {
+		clock-frequency = <400000>;
+	};
 
+	serial at 70006000 {
+		clock-frequency = <216000000>;
+	};
+
+	serial at 70006300 {
+		clock-frequency = <216000000>;
+	};
+
+	usb at c5000000 {
+		dr_mode = "otg";
+	};
+

arch/arm/boot/dts/tegra20-colibri-512.dtsi line 284

Quoted 10 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi +10 -0

+	usb at c5004000 {
+		status = "okay";
+		nvidia,phy-reset-gpio = <&gpio 169 0>; /* gpio PV1 */
+	};
+
+	sdhci at c8000600 {
+		cd-gpios = <&gpio 23 0>; /* gpio PC7 */
+		vmmc-supply = <&ldo5_reg>;
+		vqmmc-supply = <&vcc_sd_reg>;
+	};

I assume that all of those nodes are meant to have status="okay"?

Oh, I see those are in the top-level board .dts file. You may as well put all the properties there; stuff like the GPIOs and regulators at least would be purely specific to the individual board, and not the COM.

I guess we should really move the serial node's clock-frequency property in the SoC .dtsi files.

arch/arm/boot/dts/tegra20-colibri-512.dtsi line 479

Quoted 1 line

arch/arm/boot/dts/tegra20-colibri-512.dtsi +1 -0

+	com_regulators {

I think just call that "regulators"; the final board .dts file can easily add more sub-nodes to this node, so there's no need to try and avoid any naming conflict here. See Cardhu as an example.

Am Donnerstag, den 17.01.2013, 13:55 -0700 schrieb Stephen Warren:

Quoted 13 lines · Lucas Stach

Quoted 11 lines

This adds the device tree include file for the Toradex Colibri T20 Computer on Module (COM). It's only valid for the 512MB RAM version of the module, as the 256MB version needs different EMC tables and flash configuration. To make this clear the suffix -512 was added to the board compatible string.

The Colibri T20 uses a Tegra2 SoC and has onboard USB Ethernet and AC97 sound.

Still some things like onboard NAND support missing, but should be a good base for further development.

Quoted 8 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi line 359

Quoted 4 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi +2 -0

 
+		temperature-sensor at 4c {
+			compatible = "national,lm95245";

You should probably add that compatible value to Documentation/devicetree/bindings/i2c/trivial-devices.txt.

Yep, will send a separate patch for this.

Quoted 37 lines

Quoted 24 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi +23 -0

+	i2c at 7000c000 {
+		clock-frequency = <400000>;
+	};
+
+	i2c_ddc: i2c at 7000c400 {
+		clock-frequency = <100000>;
+	};
+
+	i2c at 7000c500 {
+		clock-frequency = <400000>;
+	};
 
+	serial at 70006000 {
+		clock-frequency = <216000000>;
+	};
+
+	serial at 70006300 {
+		clock-frequency = <216000000>;
+	};
+
+	usb at c5000000 {
+		dr_mode = "otg";
+	};
+

arch/arm/boot/dts/tegra20-colibri-512.dtsi line 284

Quoted 10 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi +10 -0

+	usb at c5004000 {
+		status = "okay";
+		nvidia,phy-reset-gpio = <&gpio 169 0>; /* gpio PV1 */
+	};
+
+	sdhci at c8000600 {
+		cd-gpios = <&gpio 23 0>; /* gpio PC7 */
+		vmmc-supply = <&ldo5_reg>;
+		vqmmc-supply = <&vcc_sd_reg>;
+	};

I assume that all of those nodes are meant to have status="okay"?

Quoted 3 lines

Oh, I see those are in the top-level board .dts file. You may as well put all the properties there; stuff like the GPIOs and regulators at least would be purely specific to the individual board, and not the COM.

I would like to keep everything that is defined by the COM to reside in the COM dtsi. You are right that the regulator in this case is board specific and should be moved to the board file, I missed this while splitting things out. But at least the GPIO is defined by the fixed COM pinout.

Quoted 5 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi line 479

Quoted 1 line

arch/arm/boot/dts/tegra20-colibri-512.dtsi +1 -0

+	com_regulators {

I think just call that "regulators"; the final board .dts file can easily add more sub-nodes to this node, so there's no need to try and avoid any naming conflict here. See Cardhu as an example.

I don't really see the benefit of merging those nodes. They are separate regulators, some are located on the COM, others on the carrier board. So I would like to keep them in separate nodes, unless you have strong feelings to change this.

Quoted 26 lines

Am Donnerstag, den 17.01.2013, 13:55 -0700 schrieb Stephen Warren:

Quoted 21 lines · Lucas Stach

Quoted 11 lines

This adds the device tree include file for the Toradex Colibri T20 Computer on Module (COM). It's only valid for the 512MB RAM version of the module, as the 256MB version needs different EMC tables and flash configuration. To make this clear the suffix -512 was added to the board compatible string.

The Colibri T20 uses a Tegra2 SoC and has onboard USB Ethernet and AC97 sound.

Still some things like onboard NAND support missing, but should be a good base for further development.

arch/arm/boot/dts/tegra20-colibri-512.dtsi line 462

Quoted 6 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi new file +6 -0

+
+	sdhci at c8000600 {
+		cd-gpios = <&gpio 23 0>; /* gpio PC7 */
+		vmmc-supply = <&ldo5_reg>;
+		vqmmc-supply = <&vcc_sd_reg>;
+	};

I assume that all of those nodes are meant to have status="okay"?

Quoted 3 lines

Oh, I see those are in the top-level board .dts file. You may as well put all the properties there; stuff like the GPIOs and regulators at least would be purely specific to the individual board, and not the COM.

Quoted 5 lines

I would like to keep everything that is defined by the COM to reside in the COM dtsi. You are right that the regulator in this case is board specific and should be moved to the board file, I missed this while splitting things out. But at least the GPIO is defined by the fixed COM pinout.

If these are really defined by the COM itself, it does indeed make sense for the COM .dtsi file to define those properties. But, I have a hard time understanding how the COM design can force the carrier module into using a particular GPIO for the SD controller CD functionality; couldn't the carrier use any GPIO passed through the COM<->carrier connector for any purpose?

Quoted 10 lines

Quoted 5 lines

arch/arm/boot/dts/tegra20-colibri-512.dtsi line 479

Quoted 1 line

arch/arm/boot/dts/tegra20-colibri-512.dtsi new file +1 -0

+	com_regulators {

I think just call that "regulators"; the final board .dts file can easily add more sub-nodes to this node, so there's no need to try and avoid any naming conflict here. See Cardhu as an example.

I don't really see the benefit of merging those nodes. They are separate regulators, some are located on the COM, others on the carrier board. So I would like to keep them in separate nodes, unless you have strong feelings to change this.

The issue here is that if we don't do this, we end up with wierd node names; plain "regulators" is a fairly canonical name for what the name contains, and purely indicates the type of the node. "com_regulators" is unusual, and starts to encode identity into the node name itself, which is something not usually done in the node name (differentiation between identities is usually done using the unit address; "@nnn"),

No Tegra Platform is running PLL_P at another rate than 216MHz, nor is any using an other PLL as UART source clock. Move attribute into SoC level dtsi file to slim down board DT files.