-----Original Message----- From: "Raja, Govindraj" <govindraj.raja@xxxxxx> To: Joe Woodward <jw@xxxxxxxxxxxxxx>, Kevin Hilman <khilman@xxxxxx> Cc: Paul Walmsley <paul@xxxxxxxxx>, linux-omap@xxxxxxxxxxxxxxx, Felipe Balbi <balbi@xxxxxx>, neilb@xxxxxxx Date: Mon, 2 Apr 2012 16:13:13 +0530 Subject: Re: Suspend broken on 3.3? > On Fri, Mar 30, 2012 at 5:54 PM, Raja, Govindraj > <govindraj.raja@xxxxxx> wrote: > > On Fri, Mar 30, 2012 at 4:34 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: 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 <jw@xxxxxxxxxxxxxx> > >>> 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. > Does that get us back to the same behaviour as in 3.2? If thats the best we can do, then I guess that'll have to do. Will similar problems exist when in DMA-mode (as we I set the DMA flag it seemed to work ok)? It does seem a little strange from my naive point of view: surely what peripherals/pins are used to wake the device from suspend should not affect how the device chooses to enable/disable clocks/power-domains to save power when running? 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
