From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751635AbcI1IBI (ORCPT ); Wed, 28 Sep 2016 04:01:08 -0400 Received: from mga01.intel.com ([192.55.52.88]:32962 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750977AbcI1IBA (ORCPT ); Wed, 28 Sep 2016 04:01:00 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,409,1470726000"; d="scan'208";a="14123120" Date: Wed, 28 Sep 2016 16:09:07 +0800 From: Chen Yu To: Oliver Neukum Cc: linux-pm@vger.kernel.org, "Rafael J. Wysocki" , Len Brown , Pavel Machek , Lee Jones , linux-kernel@vger.kernel.org, Andy Shevchenko , Mika Westerberg , "Rafael J . Wysocki" Subject: Re: [PATCH 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily Message-ID: <20160928080907.GA4567@sharon> References: <6e14fa9659f23da041bc5e65edcd53c3e4845c74.1475032126.git.yu.c.chen@intel.com> <1475048574.4635.1.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1475048574.4635.1.camel@suse.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 on pm_wq, which is freezed at early stage. So we choose > > another method, that is to avoid resuming runtime-suspended devices, > > if they are already runtime suspended. This is safe because for LPSS > > driver, the runtime suspend and system suspend are of the same > > hook - i.e., intel_lpss_suspend(). And moreover, this device is > > neither runtime wakeup source nor system wakeup source. > > I agree with the reasoning but I don't see the specificity to LPSS. > Shouldn't this go into the core? > 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 this device in runtime-suspended during sleep. Documentation/power/runtime_pm.txt: "the PM core provides a mechanism allowing some coordination between different levels of device hierarchy. Namely, if a system suspend .prepare() callback returns RPM_SUSPENDED for a device, that indicates to the PM core that the device appears to be runtime-suspended and its state is fine, so it may be left in runtime suspend provided that all of its descendants are also left in runtime suspend. If that happens, the PM core will not execute any system suspend and resume callbacks for all of those devices, except for the complete callback, which is then entirely responsible for handling the device as appropriate. " Thanks, Yu