On Fri, Aug 17, 2012 at 2:35 PM, Benoît Thébaudeau benoit.thebaudeau@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.