Re: Suspend broken on 3.3?

["Raja, Govindraj" <govindraj.raja@ti.com>]

On Fri, Mar 30, 2012 at 5:54 PM, Raja, Govindraj <govindraj.raja@ti.com> wrote:
> On Fri, Mar 30, 2012 at 4:34 PM, Joe Woodward <jw@terrafix.co.uk> wrote:
>>
>>
>> -----Original Message-----
>> From: "Raja, Govindraj" <govindraj.raja@ti.com>
>> To: Joe Woodward <jw@terrafix.co.uk>
>> Cc: Paul Walmsley <paul@pwsan.com>, Kevin Hilman <khilman@ti.com>, linux-omap@vger.kernel.org, Felipe Balbi <balbi@ti.com>, neilb@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 <jw@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html