Re: Suspend broken on 3.3?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




-----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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux