From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 25 Jan 2013 14:10:05 -0800 Subject: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux In-Reply-To: References: <1359046100-19385-1-git-send-email-dev@lynxeye.de> <1359046100-19385-7-git-send-email-dev@lynxeye.de> <1359051762.1540.70.camel@tellur> <1359149898.1540.86.camel@tellur> Message-ID: <510302BD.3040909@nvidia.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 01/25/2013 01:49 PM, Simon Glass wrote: > Hi Lucas, > > On Sat, Jan 26, 2013 at 10:38 AM, Lucas Stach 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 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 wrote: >>>>>> Init pinmux in one shot, in order to avoid any conflicts. >>>>>> >>>>>> Signed-off-by: Lucas Stach >>>>>> --- >>>>>> 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.