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

[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?).

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

>
>> Also, how does this deal with drivers that want to support different
>> configurations, such as 4/8 bit MMC, UART flow control, etc.? How does
>> this fit with what the device tree pinmux specifies in the kernel, and
>> why would we not move to using that?
>
> This is just the pinmux. You have to make sure to match the pinmux with
> your driver configuration. This tablebased approach is the same thing as
> what is done with Tegra30 in U-Boot.
>
> It's not as runtime flexible as the pinmux used in the Linux kernel, but
> also quite a fair bit simpler. I don't see any platform that would need
> anything other than the default configuration in U-Boot, so we don't
> need the muxing stuff provided by the pinmux framework in the kernel.

Fair enough, simple is good, but I'm not sure it will do the job. If
we create different variants of a board, how exactly will we describe
the differences other than by creating a new config, separate U-Boot
build, etc.?

>
> While running U-Boot we want to keep most of the pads in tristate and
> just enable the ones used by U-Boot itself (boot devices, GPIOs, LCD
> pins, etc.), so using the plain kernel pinmux config isn't going to
> work. So I think the table based approach is a good compromise between
> the need of having an comprehensively defined pinmux, simplicity and
> effort needed to define the pinmux.

OK. Can you think of a way to implement this so that we have:

board/nvidia/common/tegra20_dt.c

and the resulting image can run on all T20 boards (given an appropriate DT)?

Regards,
Simon

>
> Regards,
> Lucas
>
>