[PATCH 1/2] ARM: DT: tegra: Add Colibri T20 512MB COM

[Lucas Stach]

Am Donnerstag, den 17.01.2013, 15:13 -0700 schrieb Stephen Warren:
> On 01/17/2013 02:29 PM, Lucas Stach wrote:
> > Am Donnerstag, den 17.01.2013, 13:55 -0700 schrieb Stephen Warren:
> >> On 01/17/2013 04:59 AM, Lucas Stach wrote:
> >>> 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 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 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.

> >>> +	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.