Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752085AbaAOAhk (ORCPT ); Tue, 14 Jan 2014 19:37:40 -0500 Received: from mga02.intel.com ([134.134.136.20]:34300 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750880AbaAOAhi (ORCPT ); Tue, 14 Jan 2014 19:37:38 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.95,659,1384329600"; d="scan'208";a="466758261" From: "Liu, Chuansheng" To: "Rafael J. Wysocki" CC: "gregkh@linuxfoundation.org" , "Brown, Len" , "pavel@ucw.cz" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Li, Zhuangzhi" Subject: RE: [PATCH] PM: Enable asynchronous noirq resume threads to save the resuming time Thread-Topic: [PATCH] PM: Enable asynchronous noirq resume threads to save the resuming time Thread-Index: AQHPEXmxHJZk4e3zx0694YnUG8KNkpqE7cOA Date: Wed, 15 Jan 2014 00:35:16 +0000 Message-ID: <27240C0AC20F114CBF8149A2696CBE4A01C02047@SHSMSX101.ccr.corp.intel.com> References: <1389683888.3650.78.camel@cliu38-desktop-build> <1746120.u7vbF1Vtmp@vostro.rjw.lan> In-Reply-To: <1746120.u7vbF1Vtmp@vostro.rjw.lan> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id s0F0bkC8004792 Hello Rafael, > -----Original Message----- > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net] > Sent: Wednesday, January 15, 2014 6:55 AM > To: Liu, Chuansheng > Cc: gregkh@linuxfoundation.org; Brown, Len; pavel@ucw.cz; > linux-pm@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; > 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:) ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?