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

[Simon Glass]

Hi Stephen,

On 24 February 2015 at 17:06, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 02/24/2015 04:44 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 24 February 2015 at 14:08, Stephen Warren <swarren at wwwdotorg.org>
>> wrote:
>>>
>>> From: Stephen Warren <swarren at 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.

I see - do you know how much bigger the tables are?

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

OK, well that's up to you, I suppose I was talking about the
lower-level API, and probably that ties in with the discussion about a
pinctl layer. Let's see what happens in the future.

Regards,
Simon