-----Original Message----- From: "Raja, Govindraj" <govindraj.raja@xxxxxx> To: Joe Woodward <jw@xxxxxxxxxxxxxx> Cc: Paul Walmsley <paul@xxxxxxxxx>, Kevin Hilman <khilman@xxxxxx>, linux-omap@xxxxxxxxxxxxxxx, Felipe Balbi <balbi@xxxxxx>, neilb@xxxxxxx Date: Thu, 29 Mar 2012 19:59:54 +0530 Subject: Re: Suspend broken on 3.3? > 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 ? > In short, yes. I've gone back to a stock 3.3 kernel and the serial ports give the correct data, but suspend fails (due to not being able to disable wake-from-serial). I then applied your patch and could disable wakeup on the serial ports and suspend correctly, but the (non-console) serial port starts to misbehave. Forcing the driver to be DMA-enabled caused everything to work again. So something in the patch is causing the (default) interrupt-enabled serial driver to occassionally fail. Sorry for the goose chase yesterday. I didn't even think to check if the patch caused the issue as it seemed a bit unrelated. Cheers, Joe > -- > 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 -- 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
