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

On 01/17/2013 02:29 PM, Lucas Stach wrote:

quoted

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

quoted

On 01/17/2013 04:59 AM, Lucas Stach wrote:

quoted

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.
+
+	sdhci@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 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?

It's not a GPIO anymore as soon as it hits the COM<->carrier connector.
The connector pin assignment is strictly specified. There are a lot of
freely assignable GPIOs on the connector, everything related to a
specific function is not part of this.

The Colibri specification dictates which pin to use if you want to
realize a SDcard CD. This is done so that modules and carrier boards are
interchangeable. In fact you can just as well run a new Colibri T30
module on a years old carrier designed for the ColibriPXA series of
modules.

quoted

quoted

quoted

+	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"),

Hm, ok. Keeping some space in between module and carrier regulator
addresses should do as well.