-----Original Message----- From: "Joe Woodward" <jw@xxxxxxxxxxxxxx> To: "Paul Walmsley" <paul@xxxxxxxxx> Cc: "Kevin Hilman" <khilman@xxxxxx>, "Raja\\, Govindraj" <govindraj.raja@xxxxxx>, linux-omap@xxxxxxxxxxxxxxx, "Felipe Balbi" <balbi@xxxxxx>, neilb@xxxxxxx Date: Thu, 29 Mar 2012 12:27:55 +0100 Subject: Re: Suspend broken on 3.3? > > Hello Joe, > > > > thanks for reporting this. Some thoughts -- really just pure > > speculation > > -- but I hope some of it might be useful for you... > > > > On Thu, 29 Mar 2012, Joe Woodward wrote: > > > > > After digging a bit further I found that the problem isn't lost > > characters or character corruption at all... > > > > > > The UART is actually at 430KBaud (not 900KBaud as I mentioned > > earlier). > > > > 430Kbps? Could you confirm this? OMAP UARTs don't support that rate > > as > > far as I know - the closest is 460Kbps (OMAP34xx TRM vZR Table 17-1 > > "UART > > Mode Baud Rates, Divisor Values, and Error Rates). If one was > > desperate, > > it might be possible to get 430Kbps by tweaking other parts of the > > clock > > tree though... > > Sorry for the confusion... It's 460KBaud - the 430 was just a typo in > my previous mail... > > > > > > The data received is very bursty (i.e. sets of messages every > second > > or > > > so), containing a sync sequence to indicate a start of packet. > > > > > > The received bytes should be: 0x01, 0x52, 0x41 ....rest of packet. > > > > > > This works 100% of the time on 3.2, but on 3.3 I sometimes (but not > > always) get: 0x01, 0x00, 0x52, 0x41. > > > > > > i.e. there is a NULL/0x00 inserted after the first character. > > > > Is this on the serial console, or on a non-console serial port? > > > > Looking at drivers/tty/serial/omap-serial.c:receive_chars(), I wonder > > if > > the driver is somehow reading bytes from the RX FIFO when it's empty. > > > It's unclear to me how this could happen. But you might want to try > > doing > > an LSR read right before entering the loop in > > drivers/tty/serial/omap-serial.c:receive_chars(). In stock v3.3, > this > > would mean adding > > > > lsr = serial_in(up, UART_LSR); > > > > at line 190 of drivers/tty/serial/omap-serial.c. > > > > Adding this is made no obvious difference. > > > > > You might also try the DMA path as an experiment. This will totally > > wedge > > power management due to an insanely low timer expiration in that > path, > > but > > at least might help narrow the problem down. To do so with a quick > > hack, > > you could set omap_serial_default_info.dma_enabled to true instead of > > false at arch/arm/mach-omap2/serial.c:76. > > > > This did the trick (I've added it in addition to the LSR read above, > i'll back out the LSR read and see if it still works). > When DMA is enabled the behaviour (as seen from my application in > userspace) is the same as on the stock 3.2 kernel (i.e. for me it works > :) ). > I've just realised that if anyone has joined this thread late, then I'm running in a state with Govindraj's patch in a previous mail in this thread applied to serial.c to fix the suspend issues due to the UART wakeup's not being correctly changed from userspace via sysfs. It may actually by this patch that is causing the interrupt-enabled serial driver to have broken? The tty that is causing me a problem does have wake-from-suspend disabled for it from userspace... Cheers, Joe > Cheers, > Joe > > > > > And one other thing to try: does the behavior change if you set > > uart_debug > > to true at arch/arm/mach-omap2/serial.c:278 ? > > > > > > - 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 > > > -- > 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 -- 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
