[U-Boot] [PATCH 0/9] ARM: tegra: pinmux: Tegra210 support

[Stephen Warren <swarren@wwwdotorg.org>]

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.