[PATCH 0/2] ARM: OMAP2+: PM: code consolidation for 3.4

Kevin Hilman khilman at ti.com
Fri Mar 9 10:23:16 EST 2012


Luciano Coelho <coelho at ti.com> writes:

> Hi Kevin,
>
> On Thu, 2012-03-08 at 13:21 -0800, Kevin Hilman wrote: 
>> Luciano Coelho <coelho at ti.com> writes:
>> 
>> [...]
>> 
>> > Thanks, Paul! I was just chatting with Kevin about this on IRC.  With
>> > your patch and no_console_suspend, it works. :)
>> 
>> Just FYI... I've queued this patch from Paul and it's now queued by Tony
>> for v3.4 in his cleanup-pm branch.
>
> Great, thanks for the info!
>
> BTW, you and Paul said that it was not recommended to use
> no_console_suspend, but Ido (on CC) said that it can be useful for us,
> because we need to see if our own (wireless) stuff goes into suspend
> correctly.

no_console_suspend should not be needed there.  It is really only
intended as a *temporary* debug feature when suspend fails.

Since the console is disabled during suspend, if suspend fails, you
might not see the reason for failure.  So in this case, you enable
no_console_suspend just to see the suspend output, and why it's failing.

If suspend/resume succeed, you will see all the console output after
resume because even though the console is disabled, the printks are
buffered, so you will see them eventually.

So with a working suspend/resume, you will eventually see all the
console output.

So basically, any usage of no_console_suspend should be temporary, until
you figure out why suspend if failing. 

> Are there any real problems with no_console_suspend besides power
> consumption? Is it safe for us to simply apply Paul's patch when we need
> it?

There are important side effects of leaving the console enabled.
Namely, the console UART will stay clocked, and thus prevent it's
surrounding powerdomain from reaching a low power state.  UARTs can be
in either the PER or CORE powerdomains, so preventing them from reaching
the low powerstate will affect other drivers in those powerdomains.

For example, if your device is in the same powerdomain as the UART, it
will not be clock gated (or power gated) so the context save/restore
paths of those devices will not be exercised.


Kevin



More information about the linux-arm-kernel mailing list