On Sat, 4 Feb 2012, NeilBrown wrote: > On Fri, 3 Feb 2012 12:42:22 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> wrote: > > > Case 1 is expected and is almost certainly not a bug. As Neil mentioned > > it should be bps-rate dependent. It occurs when the first character > > transmitted to the OMAP wakes the chip up via I/O ring/chain wakeup. > > I/O ring/chain wakeup is driven by a 32KiHz clock and is therefore > > relatively high-latency. So this could easily cause the first character > > or first few characters to be lost or corrupted, depending on the exact > > sequence of events, the low power state that the chip was in, etc. > > A 32KiHz cycles every 30mSec. > At 115200 bps, there is one bit every 8.7 microseconds. > > When I type "return" - which looks like 0101100001111... on the wire, > I see '0xC3' which looks like 011000011111... on the wire. > So we lost exactly 2 bits, or a delay around 17 microseconds. > > I find it hard to reconcile that delay with the cause being a 32KiHZ clock. If you're not disabling the HF clock oscillator via the AUTOEXTCLKMODE bits, the wakeup logic may be getting clocked by the sys_clk, which is quite a bit faster. That might explain the corruption patterns you're seeing. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
