Re: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

On Tuesday 16 August 2011, Stephen Warren wrote:

Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM:

quoted

On Monday 15 August 2011, Stephen Warren wrote:

quoted

The contents of this file seem to be specific to even just one
version of the tegra chip, and might be completely different for
tegra30 and later, right?

The general concepts are the same between tegra20 and tegra30.

Tegra30 has a different set of mux and drive pingroups.

Tegra30 has more functions that can be assigned to pins.

Tegra30 has three more options per mux pingroup, although I haven't
Investigated whether any of those would need to be represented in DT;
I suspect at least one will, possibly all.

Thanks for the info!
 

Two things to note about Tegra that might not apply to all SoCs:

* There are separate groups of pins for Muxing (plus some config) vs.
drive-strength (and related config). Some SoCs might use the same set
of groups for both. Perhaps some SoC might even have three or more types
of groups! I expect this to have some impact on the binding; I created
explicit mux-groups and drive-groups sub-nodes to represent this.

* Tegra's pinmux apply settings to groups of pins instead of individual
pins. Some SoCs might allow each setting to be configurable per-pin.
I don't expect this to have any impact as far as the bindings go though;
it'll simply impact the names of the available pin "groups"; some SoCs
will name groups, others pins.

ok, makes sense. So if we want to have a general binding that applies
to all, we really need to cover a lot of different ways to set these up.

quoted

quoted

+Each mux pin group is represented as a sub-node of the nvidia,mux-groups node.
+The name of the sub-node should be the name of the mux pingroup. The following
+names are valid:
+
+	ata
+	atb
+	atc
+	atd
+	ate
+	cdev1
+	cdev2
...

I noticed that each board you define has a complete list of these. Would
it be possible to move a generic list into a tegra20-pinmux.dtsi file and
just override the pins in the per-board .dts file that require some special
setup?

I'm not sure how much commonality there will really be.

Certainly, many boards are based off our reference designs and so will
have many similarities that could be shared.

That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows
a lot of differences. It seems a lot less error-prone to just completely
describe the entire pinmux state in each board's .dts file, rather than
trying to represent half the information as default in the SoC .dtsi file,
and just the diff in the board .dts file. I suppose perhaps if we put the
hardware's own default settings in tegra20.dtsi, that'd make sense, since
people are presumably reasonably aware of the delta relative to that.

We'd need to add new properties to override defaults, like:

nvidia,tristate --> nvidia,drive
nvidia,pull-*   --> nvidia,no-pull

The split I had in mind is more to the effect that the .dtsi file
describes the set of pins that is there with their names and addresses,
while the board specific file describes how they are set up. Does that
make sense? I think I'm still missing some essential aspect of what the
pinmux code actually does ;-)

I now saw that you have the full description in the
arch/arm/mach-tegra/pinmux-t2-tables.c and arch/arm/mach-tegra/pinmux.c
files, with all the names again, and apparently your patch set leaves
these around. Do you think it's possible to actually move the static
tables from there into the device tree and do the entire setup based
on that?

	Arnd