ARM: OMAP2+: PM: code consolidation for 3.4
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
Quoted 13 lines · Luciano Coelho
Hi Kevin,
Quoted 9 lines · Kevin Hilman
Luciano Coelho <[email protected]> writes:
[...]
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 3 lines
Are there any real problems with
no_console_suspendbesides 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