[U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux

[Stephen Warren <swarren@nvidia.com>]

On 01/25/2013 01:57 PM, Lucas Stach wrote:
> Am Samstag, den 26.01.2013, 10:49 +1300 schrieb Simon Glass:
> [...]
>>> But yes in the end we want to pack this information into the DT files.
>>> But even then it would be nice if people would test this pachset, as I
>>> imagine DT based pinmux is the same as tablebased pinmux, just in a
>>> slightly different flavour. ;) So if people test the tablebased config
>>> now, we can do the conversion to DT based with a lot more confidence.
>>>
>>> I'll look into using the kernel pinmux binding minus the MUX stuff, as I
>>> think there's no real reason to have this in U-Boot.
>>
>> Well I would rather than we get that running than switch to
>> table-driven mux, assuming it is not too big a job?
>>
>> I imagine perhaps naively that a function could be written which
>> parses the pinmux and sets it up in U-Boot - effectively using the FDT
>> as the pinmux table.
> 
> That's my plan. But still even if we keep the binding the same, the
> actual pinmux config would differ between the kernel and U-Boot (a lot
> more pads kept in tristate in U-Boot). So as the FDT would effectively
> resemble the same tables I included in this patchset, some testing
> coverage of that would smoothen the transition.

Why wouldn't the pinmux tables in the FDT passed to U-Boot either be
identical to (a) the kernel, or (b) the small subset of the pinmux
options that U-Boot used to program via code? I don't see any reason for
U-Boot to program all the pingroups to TRISTATE etc.; if it's
programming those pingroups at all, it may as well just program the
correct final value.