On Fri, 3 Feb 2012 12:42:22 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> wrote: > On Fri, 3 Feb 2012, Grazvydas Ignotas wrote: > > > On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown <neilb@xxxxxxx> wrote: > > > On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> wrote: > > >> On Fri, 3 Feb 2012, NeilBrown wrote: > > >> > > >> > then CPUIDLE enters lower states and I think it uses less power but I > > >> > sometimes lose the first char I type (that is known) but also I sometimes get > > >> > corruption on output. > > >> > > >> I don't see any output corruption on 35xx BeagleBoard, either with or > > >> without these patches. So this is presumably a 37xx-centric problem, and > > >> unrelated to these patches, I would guess. > > > > > > Maybe it is 37xx specific. I think this is a DM3730. > > > > Not sure if it's the same problem but with 3530 on 3.2 with > > sleep_timeout set, I usually get first char dropped (as expected) but > > sometimes I get corrupted char instead too. Corrupt char seems to > > almost always happen if I set cpufreq to powersave, on performace it's > > almost always ok, so maybe it's some timing problem, > > OK so let's distinguish between two corruption situations: > > 1. The first character transmitted to the OMAP UART in a serial console > when the UART powerdomain is in a non-functional, low power state (e.g., > RET or below) is corrupted. This is not actually output corruption, this > is input corruption. > > 2. Characters are corrupted while the OMAP UART is transmitting data, but > there has been no recent data sent to the OMAP. > > 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 the first char I type is a space (0x20 or 0000001001111111) then the character received is 0x90 (0000010011111) which is exactly 1 bit missing, so an 8 or 9 usec delay. If the first char I type is 'o' (0x6f, or 0111101101111111) then the character received is 0xfb (01101111111111) which misses 5 bits. I think it misses the first bit, then waits for a start bit (0), then takes the next 8 bits. At 230400 bps, I always lose at least 2 bits. At 460800 bps, I seem lose at least 3 bits. (above there, nothing works at all ... could be my USB/serial cable at fault). So it looks a lot like a delay which is a small number of microseconds. Could be the wake-up latency in the I/O ring/chain, but doesn't look like the 32 KiHz clock :-) > > Case 2 is not expected. That is likely a bug somewhere. Neil, this is > what I understood that you are experiencing. Is that correct? Correct. Thanks, NeilBrown > > Gražvydas, are you seeing case 1 or 2 (or something completely different > ;-) ? > > > - Paul
Attachment:
signature.asc
Description: PGP signature
