On Fri, Jul 29, 2011 at 5:07 PM, Felipe Balbi <balbi@xxxxxx> wrote: > Hi, > > On Fri, Jul 29, 2011 at 04:54:44PM +0530, Govindraj wrote: >> On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> > Hi, >> > >> >> Thanks for replying. >> >> > On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote: >> >> Proposal: >> >> -------- >> >> 1. For the UART, follow the current approach of locking the console in >> >> Idle/Suspend path before cutting the clock but using pm_runtime_putsync. >> >> That is, continue using the prepare/resume Idle calls in idle path. >> > >> > I believe you should be using ->prepare() to prevent that any other >> > work on UART won't trigger a console_write() right now. Maybe only >> > queueing the work for after ->complete() or, maybe, just ignoring the >> > work and loosing some prints, dunno. >> > >> >> Yes true, for suspend path but for Idle path we don't have any such >> mechanism. > > aha... good point ;-) > >> I have done clock gating in idle path integrating irq chaining patches. >> hosted in gitorious here[1]. >> >> Was consolidating whether this approach is OK, >> or >> Are there any other approaches that I should consider? > > why don't you also start queueing writes after the first call to > runtime_suspend() and flush them after the first call runtime_resume()?? > 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. 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. -- Thanks Govindraj.R *pm_generic layers for omap, referring to omap_device/omap_hwmod layers which does low level clock handling. -- 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
