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