Luciano Coelho <coelho@xxxxxx> writes: > Hi Kevin, > > On Thu, 2012-03-08 at 13:21 -0800, Kevin Hilman wrote: >> Luciano Coelho <coelho@xxxxxx> 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 -- 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
