Hi, On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote: > Yes fine, But there are scenarios even before first runtime_suspend happens, > > ex: uart_port_configure -> get_sync -> pm_generic_runtime_resume > (omap_device_enable in this case) debug printk -> console_write -> get_sync. > > there are numerous such scenarios where we end from runtime context > to runtime api context again, or jumping from one uart port operation > to uart print operation. calling pm_runtime_get_sync() should not be a problem. It should only increase the usage counters... This sounds like a race condition on the driver, no ? What you're experiencing, if I understood correctly, is a deadlock ? In that case, can you try to track the locking mechanism on the omap-serial driver to try to find if there isn't anything obviously wrong ? > So either we should not have those prints from pm_generic layers or suppress > them(seems pretty much a problem for a clean design within the driver > using console_lock/unlock for every get_sync, and for > runtime_put we cannot suppress the prints as it gets scheduled later) > > or if other folks who really need those prints form pm_generic* layers > to debug and analysis then we have no other choice rather control > the clk_enable/disable from outside driver code in idle path. yeah, none of these would be nice :-( I think this needs more debugging to be sure what's exactly going on. What's exactly causing the deadlock ? Which lock is held and never released ? -- balbi
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
