On Thu, Mar 29, 2012 at 5:10 PM, Joe Woodward <jw@xxxxxxxxxxxxxx> wrote: > > > -----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... Is the patch shared earlier causing this issue of getting 0x00 from rx randomly ? -- Thanks, Govindraj.R -- 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
