On Mon, Apr 2, 2012 at 6:07 PM, Joe Woodward <jw@xxxxxxxxxxxxxx> wrote: > > > -----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. > yes, only if we are in non-dma mode with wakeup disabled. > Will similar problems exist when in DMA-mode (as we I set the DMA flag it seemed to work ok)? In dma mode we might not need MPU for uart fifo ops and while in irq mode we need MPU for fifo ops, while mpu is hitting low power states way to get mpu qos for uart ops is by generating module level wakeup events, if module level wakeups are disabled and if uart does relies on mpu for fifo ops we have to prevent MPU from hitting low power states. > > 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? > -- 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
