> -----Original Message----- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Wednesday, January 15, 2014 9:28 PM > To: Liu, Chuansheng > Cc: gre...@linuxfoundation.org; Brown, Len; pa...@ucw.cz; > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Li, Zhuangzhi > Subject: Re: [PATCH] PM: Enable asynchronous noirq resume threads to save > the resuming time > > On Wednesday, January 15, 2014 12:35:16 AM Liu, Chuansheng wrote: > > Hello Rafael, > > > > > -----Original Message----- > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > > Sent: Wednesday, January 15, 2014 6:55 AM > > > To: Liu, Chuansheng > > > Cc: gre...@linuxfoundation.org; Brown, Len; pa...@ucw.cz; > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Li, Zhuangzhi > > > Subject: Re: [PATCH] PM: Enable asynchronous noirq resume threads to > save > > > the resuming time > > > > > > On Tuesday, January 14, 2014 03:18:08 PM Chuansheng Liu wrote: > > > > > > > > Currently, the dpm_resume_noirq() is done synchronously, and for PCI > devices > > > > pci_pm_resume_noirq(): > > > > > > > > pci_pm_resume_noirq() > > > > pci_pm_default_resume_early() > > > > pci_power_up() > > > > pci_raw_set_power_state() > > > > Which set the device from D3hot to D0 mostly, for every device, there > > > > will > > > > be one 10ms(pci_pm_d3_delay) to wait. > > > > > > > > Hence normally dpm_resume_noirq() will cost > 100ms, which is bigger > for > > > mobile > > > > platform. > > > > > > pci_pm_d3_delay usually is not 10 ms. What is 10 ms is dev->d3_delay, > but > > > that also is not on every platform now. > > Yes, it is d3_delay exactly, thanks your correction. > > > > > > > > That said the approach here makes sense, but I have two questions: > > > > > > 1. On what systems has it been tested? > > I have been tested on Baytrail platform, and at the beginning the d3_delay > > is > set to 0, > > but we really meet the HANG issue if we operate the device immediately > sometimes, > > so currently most PCI devices in Baytrail has the 10ms delay. > > And it caused the whole resume time bigger than Clovertrail platform; > > Does setting d3_delay to something smaller that 10 ms work on BayTrail? > > You can try to set 5 ms and then 2.5 ms if that works and so on. That still > would be an improvement from the 10 ms. Yes, for most devices in Baytrail platform, we already set the default value to 3ms, it works well now, but for rare device, we set the d3_delay to 10ms. So with this patch, the noirq execution time is 10ms;
> > > > 2. What about suspend_late/resume_early? If the _noirq things are to be > > > executed asynchronously, those should be too. > > I noticed it just taken little time often, and I cannot find out some > > reasons for > changing them > > in theory, so if you like it, I will update them into patch V2 also:) > > Yes, please do that. Will do it, thanks.
