On Fri, Mar 30, 2012 at 1:23 PM, Joe Woodward <jw@xxxxxxxxxxxxxx> wrote: > -----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. > Disabling module level wakeup by default on bootup in previous shared patch in serial.c in omap_uart_idle_init => omap_uart_disable_module_wakeup might be causing this issue and probably this should be left enabled by default and be disabled only when requested from sysfs on suspend. Could you please try attached patch and let me know if this solves the rx issue as well, without using dma mode. -- Thanks, Govindraj.R
Attachment:
0001-OMAP2-UART-Correct-the-module-level-wakeup-enable-di.patch
Description: Binary data
