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

[Simon Glass]

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.

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

Regards,
Simon

>
> Regards,
> Lucas
>