> 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 :) ). 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
