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@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.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
