Dear Fabio, On Wed, 29 Jul 2015 08:47:37 +0200 David Jander <david@xxxxxxxxxxx> wrote: > On Tue, 28 Jul 2015 12:38:22 -0300 > Fabio Estevam <festevam@xxxxxxxxx> wrote: > > > Hi David, > > > > On Tue, Jul 28, 2015 at 11:10 AM, David Jander <david@xxxxxxxxxxx> wrote: > > > > >> Do you think this is acceptable? > > > > > > Yuck! No, of course not. Why is this? > > > I don't have this issue, and I'd really like to understand why you have > > > it? Can you explain what happens to the UART on your board exactly after > > > power-on until this? > > > > Here are the complete logs: > > http://pastebin.com/DvhHbLZu > > Thats pretty clear. Thanks. I just managed to reproduce this problem too. > Apparently it appears on 4.2-rc4+, but not on 4.1... weird. > I will investigate and fix this issue. Thanks a lot for your patience. I found and fixed the issue. Can you please check if the new patch works correctly for you also? The problem was that since kernel 4.2 the peripheral clock needs to be enabled (for a reason I didn't quite investigate, it was enabled at that point on 4.1) for the reset to work correctly. Your garbled output was due to the fact that the baud-rate was set to 805k (7 times higher than it should). This in turn was caused because the reset procedure probably did not start until the clock is first enabled later on during console init, and then configuration registers are being written while the UART is still resetting itself, so the baud rate is not properly set (the clock divider in UFCR actually). Thanks a lot for your help. Excuses for the trouble caused by the botched commit. Best regards, -- David Jander Protonic Holland. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
