"Dong, Chuanxiao" <chuanxiao.dong@xxxxxxxxx> writes: [...] >> >> Basially, the question is: can the driver be reworked such that a system >> suspend does not need to runtime resume the device? For most devices, >> we kind of expect that if the device is runtime suspended, a system >> suspend will have nothing extra to do, but this driver runtime resumes >> the device during system suspend in order to do "stuff", which I >> admitedly don't fully undestand. >> >> Ideally, the "stuff" needed for runtime suspend and system suspend could >> be made to be common such that a system suspend of a runtime suspended >> device would be a noop. >> >> Is this possible? >> >> Kevin > > During system suspended patch, a callback named .prepare will be first > done before .suspend is called, and .complete callback will be called > after .resume is called. These two callbacks are in pair. If driver > can implement the .prepare and hold the usage count in this callback, > then runtime pm suspend/resume will not happen during device > suspending. So there will be no need to add pm_runtime_get* and > pm_runtime_put* in .suspend/.resume. That doesn't avoid the problem, since the device is still runtime resumed and then re-suspended during system suspend. My basic question is this: why does this device need to be runtime resumed during system suspend? Why can't it just stay runtime suspended? 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
