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

[Stephen Warren]

On 01/25/2013 01:49 PM, Simon Glass wrote:
> Hi Lucas,
> 
> On Sat, Jan 26, 2013 at 10:38 AM, Lucas Stach <dev at lynxeye.de> wrote:
>> Hello Simon,
>>
>> Am Samstag, den 26.01.2013, 10:20 +1300 schrieb Simon Glass:
>>> Hi Lucas,
>>>
>>> On Fri, Jan 25, 2013 at 7:22 AM, Lucas Stach <dev at lynxeye.de> wrote:
>>>> Am Freitag, den 25.01.2013, 06:54 +1300 schrieb Simon Glass:
>>>>> Hi Lucas,
>>>>>
>>>>> On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach <dev at lynxeye.de> wrote:
>>>>>> Init pinmux in one shot, in order to avoid any conflicts.
>>>>>>
>>>>>> Signed-off-by: Lucas Stach <dev at lynxeye.de>
>>>>>> ---
>>>>>>  board/nvidia/seaboard/seaboard.c | 133 +++++++++++++++++++++++++++++++++------
>>>>>>  include/configs/seaboard.h       |   3 +
>>>>>>  include/configs/ventana.h        |   3 +
>>>>>>  3 files changed, 121 insertions(+), 18 deletions(-)
>>>>>
>>>>> This seems like a lot of code and presumably quite a bit of
>>>>> duplication between boards. What sort of conflicts does this avoid,
>>>>> and is it the only way of avoiding them?
>>>>>
>>>> I don't see it as duplication, but as explicitly spelling out how the
>>>> pinmux configuration should be set up on a certain board.
>>>
>>> I mean that the table is very similar for different boards, so looks
>>> like duplicated coded (133 very similar lines for each board).
>>>
>>> Also, this seems to break FDT use. At present it is possible (I think)
>>> to boot the same U-Boot on any board, with the device tree specifying
>>> the config. With your change that is no longer possible, I think?
>>>
>>> Looking ahead to T114 I see a similar problem. The funcmux approach
>>> was a compromise in that we could just select appropriate values for
>>> each function - there was no agreement on how to put this in the FDT
>>> though (my intention was that it would depend on the kernel binding,
>>> but that is now defined, so what excuse do we have for not
>>> implementing it in U-Boot?).
>>>
>> That Tegra30 doesn't do so either. ;) But I agree, that's no valid
>> excuse and we should resolve this before Tegra114 introduces more of
>> this stuff. See below.
>>>>
>>>> Before this change we would leave some pads uninitialised in their
>>>> (random) reset configuration. For example on the Colibri this leads to
>>>> NAND not working as it's wired up to the KBC pads. If we only configure
>>>> those, ATC will remain in it's reset state and would be also configured
>>>> to the NAND function, which leads to fail. Having an explicit, known to
>>>> be conflict free configuration for all pads avoids all those unpleasant
>>>> surprises.
>>>
>>> Well yes, but we seem to be right back to where we started, with the
>>> FDT unable to describe a key feature of the boards (pinmux).
>>>
>> I see your point now. The obvious answer for now is: it's not regressing
>> functionality, as we were never able to boot the same U-Boot image by
>> just changing the DT.
> 
> Well, kind of. In fact we were able to boot at 3 different T20 boards
> just by adding a 'funcmux' property to the device's node to select the
> required mux option for that driver. This code is no use on T30/T114,
> and was only a stop-gap anyway.

??? I don't believe U-Boot supports any "funcmux" property in the device
tree. Are you referring to some downstream U-Boot? Such a branch
wouldn't be relevant to a patch for upstream U-Boot.