[U-Boot] [PATCH v3 4/4] ARM: tegra: Add support for nyan board

[Stephen Warren]

On 11/23/2014 10:02 AM, Simon Glass wrote:
> Hi,
>
> On 23 November 2014 at 09:12, Simon Glass <sjg at chromium.org> wrote:
>>
>> From: Allen Martin <amartin at nvidia.com>
>>
>> Nyan is a Tegra124 clamshell board that is very similar to venice2, but it
>> has a different panel, the sdcard cd and wp sense are flipped, and it has
>> a different revision of the AS3722 PMIC.
>>
>> This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
>> Tegra K1, 2GB). The display is not currently supported, so it should
>> boot on other nyan-based Chromebooks also, but only the device tree for
>> nyan-big is provided here.
>>
>> The device tree file is from Linux but with features removed which are
>> unlikely to be supported in U-Boot soon (regulators, pinmux). Also the
>> addresses are updated to 32-bit.
>>
>> Signed-off-by: Allen Martin <amartin at nvidia.com>
>> Signed-off-by: Simon Glass <sjg at chromium.org>
>> (rebase, change to 'nyan', fix pinmux that resets nyan)
>>
>> ---
>>
>> Changes in v3:
>> - Rename to nyan from norrin
>> - Bring in device tree file from Linux v3.18-rc5
>> - Generate pinmux file from tegra-pinmux-scripts
>
> I should say that I'm not thrilled with this approach, particularly as
> the files it generate have no mentioned that they are auto-generated.
> Here we have a case where Nyan and Norrin apparently different by one
> pixmux setting but there is no way to exploit this commonality.
>
> I think this was discussed a while ago (the idea of static pinmux
> being set up at start of day). If I recall I expressed my objections
> at the time. If U-Boot headed this way in general it would be
> unfortunate. You get a whole load of pinmux settings with no idea what
> they are for, and no idea how to change them for your board. It almost
> feels similar to a 'binary blob'.

That's the entire point; people should not be randomly fiddling with the 
pinmux data in U-Boot for any reason.

The model for Tegra boards is that whoever designs the boards fills out 
a spreadsheet to define the pinmux for the board. That spreadsheet is 
coded to detect and avoid a lot of mistakes (such as multiple pins muxed 
to/from the same signal, redundant pull-ups enabled on board and SoC, 
pins used for purposes incompatible with what the SoC supports, etc.). 
Any pinmux changes should be made in that spreadsheet, and all SW should 
use the values exported from or derived from the spreadsheet. There's no 
reason to modify the values afterwards.

This is similar to a binary blob in that the data shouldn't be modified.

This is quite different from a binary blob in that it's quite obvious 
exactly what the data represents semantically; it's a quite "plain-text" 
format. with non-obfuscated code to implement it, which directly maps to 
reasonably well documented hardware.

> I recently saw a patch to (from what I can tell) remove all the pinmux
> information from the device tree in Linux, presumably on the
> assumption it can never be changed except very early in the boot. If
> this is a limitation of Tegra then it seems unfortunate to me.

It's to avoid redundant work. Bootloaders are expected to set up 100% of 
the pinmux[1]. Given that, there's no point the kernel repeating the 
process of setting up the exact same configuration.

[1] This is the only sane way to avoid conflicts between mux settings of 
different pins. Only partially programming the pinmux can leave other 
pins muxed to the same controller/signal for example. Resolving that 
requires hit-and-miss testing or complex table lookups to reprogram pins 
that conflict that otherwise wouldn't be programmed. That approach could 
cause undesired glitches on pins as they're continually reprogrammed 
between different states to avoid conflicts. The simplest and only 100% 
guaranteed way to avoid this is to simply program everything directly to 
the desired final configuration. This issue isn't anything Tegra 
specific either, but applies to any pinmux controller where the same 
signal can be routed to multiple pins/pads. I believe the only reason 
this hasn't been so explicitly addressed before is that people just 
haven't thought it through at this level.