On Fri, Mar 30, 2012 at 5:54 PM, Raja, Govindraj <govindraj.r...@ti.com> wrote: > On Fri, Mar 30, 2012 at 4:34 PM, Joe Woodward <j...@terrafix.co.uk> wrote: >> >> >> -----Original Message----- >> From: "Raja, Govindraj" <govindraj.r...@ti.com> >> To: Joe Woodward <j...@terrafix.co.uk> >> Cc: Paul Walmsley <p...@pwsan.com>, Kevin Hilman <khil...@ti.com>, >> linux-omap@vger.kernel.org, Felipe Balbi <ba...@ti.com>, ne...@suse.de >> Date: Fri, 30 Mar 2012 15:45:19 +0530 >> Subject: Re: Suspend broken on 3.3? >> >>> On Fri, Mar 30, 2012 at 2:56 PM, Joe Woodward <j...@terrafix.co.uk> >>> wrote: >>> > ...[snip]... >>> >> >>> >> Could you please try attached patch and let me know if this solves >>> the >>> >> rx issue as well, >>> >> without using dma mode. >>> >> >>> > >>> > Right, >>> > >>> > I think we've getting closer, but still not quite there... >>> > >>> > Firstly, the patch adds an include to "iomap.h" - but this doesn't >>> exist in stock 3.3. Simply removing this include seemed to allow the >>> compile to complete >>> > successfully. >>> >>> Sorry I forgot to specify this is needed for latest mainline. >>> >>> > >>> > With this patch applied (and not in DMA mode) I now get the >>> following: >>> > - If I leave wake-from-suspend enabled for the serial port then it >>> works correctly (i.e. no lost/extra 0x00 characters). >>> > - If I disable wake-from-suspend for the serial port and go through >>> a suspend cycle (i.e. suspend and then wake), then the serial port >>> starts to misbehave as >>> > before. >>> > - If I then re-enable wake-from-suspend and go through a suspend >>> cycle it starts to work correctly again. >>> > >>> > So the problem is still that if wake-from-suspend is disabled for a >>> serial port, and a suspend cycle is performed then when woken the >>> serial port will not function >>> > correctly if operating in interrupt-mode. >>> >>> I tried it on my 3430sdp but strangely I don't see a 0x00 char read >>> after disabling uart wakeups >>> and waking up by keypad press. >>> >>> Probably as a quick try we can try doing uart_insert_char only if data >>> was read from rx fifo >>> (Attached patch) >>> >> >> Sadly the patch makes no difference. >> >> I'm suprised you aren't seeing similar effects. >> >> I've done more testing, and a simplified test case is as follows: >> - take a stock 3.3 kernel and apply your patch to allow disabling of >> wake-from-suspend for the serial ports. >> - disable wake-from-suspend for the console tty: >> echo disable > /sys/devices/platform/omap/omap_uart.2/power/wakeup >> - perform a suspend (you'll need a button or something to wake you now that >> the console wont). >> echo mem > /sys/power/state >> >> At this point the console is noticable/painfully slow. No characters are >> lost, but it's obvious something isn't right! > > > Yes I see this behavior with console now it becomes very slow after we > disable module level wakeups. > > One difference to note is : > > in 3.2 => full system PM is prevented in idle path if uart is active > i.e, MPU will not hit retention > > in 3.3 => MPU will hit retention independently of uart is active or not. > I think the way to get MPU qos for uart port activity > while in irq mode is to use PM_WKEN1 > reg settings, meaning enabling module level wakeup event > generation. Disabling it is causing this > slow response. > > Checking if we can workaround this scenario.
As of now what I can think of is to update qos reqest to prevent MPU from transitioning in case of port activity if wakeup capability for port is disabled. -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
