Hi, On Fri, Jul 29, 2011 at 04:54:44PM +0530, Govindraj wrote: > On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi <ba...@ti.com> 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()?? -- balbi
signature.asc
Description: Digital signature
