On Fri, 3 Feb 2012 12:42:22 -0700 (MST) Paul Walmsley [off-list ref] wrote:

On Fri, 3 Feb 2012, Grazvydas Ignotas wrote:

quoted

On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown [off-list ref] wrote:

quoted

On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley [off-list ref] wrote:

quoted

On Fri, 3 Feb 2012, NeilBrown wrote:

quoted

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120204/4c79c062/attachment.sig>