On Wed, 2016-09-28 at 16:09 +0800, Chen Yu wrote:
> Thanks for your reply. Do you mean we should add the logic to pm core?
> There is already one if the driver's
> .prepare() returns a positive number(aka, RPM_SUSPENDED), then pm core will
> keep
Yes, that makes sense.
Sorry
Hi Oliver,
On Wed, Sep 28, 2016 at 09:42:54AM +0200, Oliver Neukum wrote:
> On Wed, 2016-09-28 at 11:28 +0800, Chen Yu wrote:
> > So first try is to use pm_request_resume() instead, to make the
> > runtime
> > resume process asynchronously. Unfortunately the asynchronous runtime
> > resume relies o
On Wed, 2016-09-28 at 11:28 +0800, Chen Yu wrote:
> So first try is to use pm_request_resume() instead, to make the
> runtime
> resume process asynchronously. Unfortunately the asynchronous runtime
> resume relies on pm_wq, which is freezed at early stage. So we choose
> another method, that is to
We have report that the intel_lpss_prepare() takes too much time during
suspend, and this is because we first resume the devices from runtime
suspend by resume_lpss_device(), to make sure they are in proper state
before system suspend, which takes 100ms for each LPSS devices(PCI power
state from D3
4 matches
Mail list logo
