On 02/24/2015 04:44 PM, Simon Glass wrote:
Hi Stephen,
On 24 February 2015 at 14:08, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
This series performs a few small cleanups to or parameterizations of the existing Tegra pinmux driver, and adds Tegra210 support. The Tegra210 code isn't actually used yet, since the balance of the Tegra210 support is not yet present. However, it should start appearing soon.
I've at least compile-tested this by over-writing the Tegra124 pinmux driver and Jetson TK1 board pinmux data tables with the Tegra210 versions.
TomW, note I made a couple minor tweaks since the latest version I sent internally; let's apply this version upstream.
Stephen Warren (9): ARM: tegra: pinmux: add note re: drive group field defines ARM: tegra: pinmux: simplify some defines ARM: tegra: pinmux: handle feature removal on newer SoCs ARM: tegra: pinmux: move some type definitions ARM: tegra: pinmux: partially handle varying register layouts ARM: tegra: pinmux: support hsm/schmitt on pins ARM: tegra: pinmux: account for different drivegroup base registers ARM: tegra: pinmux: support Tegra210's e_io_hv pin option ARM: tegra: pinmux: add Tegra210 support
Does the Linux side look similar to this? The use of #defines seem like a potential temporary solution but I hope it doesn't stay that way.
It feels like maybe we need to define an API that would suit all Tegra chips?
The Linux side was already a bit more parameterized, so the Tegra210 support series doesn't have as many patches as the U-Boot series. However, that comes at the cost of the per-SoC "drivers" having much larger data tables, so I don't expect we'd want to adopt in U-Boot the same level of driver parameterization as Linux.
You can find the kernel patches on the linux-tegra mailing list; I posted them roughly the same time as the U-Boot patches.
The U-Boot API to the pinmux driver is already identical across all chips (at least Tegra114+; Tegra20 and perhaps Tegra30 boards might use some more fine-grained APIs in what I'd assert is a legacy fashion); the board file simply calls gpio_config_table(), pinmux_config_pingrp_table(), and pinmux_config_drvgrp_table(), passing the relevant data table to each. The only difference between SoCs is the set of fields in the data table, since each SoC has a different feature set. While we could reduce the number of ifdefs and unify the structs across chips, this would be at the cost of bloating structs with fields that aren't supported, and including functions to apply settings that will never be used by any pin's data table entries, thus using more .text and .rodata space without good reason.