[U-Boot] [PATCH] mx5: add iomux-mx51.h include

[Matt Sealey]

On Fri, Aug 17, 2012 at 2:35 PM, Benoît Thébaudeau
<benoit.thebaudeau at advansee.com> wrote:
> Dear Matt Sealey,
>
>> If you want to "correct" years of reliable operation in U-Boot, go
>> ahead, and fix Linux while you're at it. I'm just porting the status
>> quo.
>
> I'm just saying that from experience. I've already seen issues related to that
> kind of things.

And I agree with you on the electrical aspect of it.

However our initial goal here is;

* port the code from Linux so it matches the implementation in U-Boot for i.MX6
* if we can get away with not changing the behavior or pad settings
(i.e. old config and iomux-mx51 config are identical), leave it that
way for now as this has a very long-lived legacy

It was important from our testing on Efika MX boards that if we used
the iomux-mx51 pad that it worked, and where possible it was NOT
different to the one in the old code. For UART the pad settings are
identical to the old board-file setup method (the same one you removed
in your patch). For ATA pads, there are differences, but those drive
strength changes were simply for extremely old boards that don't boot
with mainline U-Boot anymore. It would not make any difference to add
the NEW_PAD_CTRL() functionality to those pads and preserve the
settings but it doesn't make any sense to us.

So, in terms of just porting to the new framework, we got "lucky" in
that the broken UART pad settings are and have been broken and we
didn't write the code so we're throwing our hands in the air - not our
problem. That said, I will gladly write a patch to copy your UART and
SPI RX/TX setting differences into the new file (minus the redundant
ODE setting which has zero effect and is a waste of space), and test
that next week, and modify our Linux device tree to match, and test
that, before any other boards port to the new iomux-mx51 file or MX53
boards appear recreating the effect. For now, configuring UART the
same as it was configured before, the same as it was configured on
EVK, SabreLite etc. seems reasonable to me.

If we went through and tested every pad to the best of our ability
we'd be here for months cross-referencing the manual. I did spend
significant time checking this with JTAG with the board halted and
confirmed all the settings, which is why I nitpicked the re-setting of
those particular MUX_MODE, but if you are right (and you are) then
these pads need fixing anyway so changing them from their POR defaults
to more reliable settings is worthwhile.

So far I am confident that nothing is so different that it will cause
the end of the world or a burned board (or I'd have a stack of burned
boards on my desk with broken UART). We did notice that in moving to
the new iomux-mx51 file and porting the code, despite the exact same
pad settings, we get more reliable serial output ("yyyya..." on serial
between reboots goes away, so yes, we noticed the effect you're
talking about, but it was only a minor inconvenience). I don't know if
this is due to more efficient pad setting code or not, but it's
certainly not reproducible for us at this moment.

-- 
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.