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

[Simon Glass]

Hi Stephen,

On Sat, Jan 26, 2013 at 11:10 AM, Stephen Warren <swarren at nvidia.com> wrote:
> 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.
>

Yes, downstream. In fact from memory only the UARTs and one i2c port
actually cared on T20 - the rest just used default funcmux.  But we
did agree at the time to omit this 'funcmux' FDT binding from mainline
since there was an expectation that the kernel would soon have FDT
pinmux and we would use that in U-Boot. Now that it is available I
think we should use the kernel's FDT binding instead of static
table-based pinmux.

Regards,
Simon