Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751937AbbKPLaG (ORCPT ); Mon, 16 Nov 2015 06:30:06 -0500 Received: from mail-yk0-f169.google.com ([209.85.160.169]:32795 "EHLO mail-yk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751523AbbKPLaD (ORCPT ); Mon, 16 Nov 2015 06:30:03 -0500 MIME-Version: 1.0 In-Reply-To: <56488E6F.3090109@linux.intel.com> References: <56488E6F.3090109@linux.intel.com> Date: Mon, 16 Nov 2015 12:30:02 +0100 Message-ID: Subject: Re: [PATCH v3] MMC/SDIO: enable SDIO device to suspend/resume asynchronously From: Ulf Hansson To: "Fu, Zhonghui" Cc: Adrian Hunter , Neil Brown , Jaehoon Chung , Andreas Fenkart , Joe Perches , linux-mmc , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2780 Lines: 72 On 15 November 2015 at 14:53, Fu, Zhonghui wrote: > Now, PM core supports asynchronous suspend/resume mode for devices > during system suspend/resume, and the power state transition of one > device may be completed in separate kernel thread. PM core ensures > all power state transition timing dependency between devices. This > patch enables SDIO card and function devices to suspend/resume > asynchronously. This will take advantage of multicore and improve > system suspend/resume speed. After enabling the SDIO devices and all > their child devices to suspend/resume asynchronously on ASUS T100TA, > the system suspend-to-idle time is reduced from 1645ms to 1119ms, and > the system resume time is reduced from 940ms to 918ms. > > Signed-off-by: Zhonghui Fu I think this is an interesting change, but I wonder if you really understand how this affects the order of how devices may be suspended/resumed? Also, I believe you didn't answer my question for the earlier version of the patch, so let me try again. There are a strict dependency chain when suspending/resuming devices that must be maintained. Currently this is controlled via device registration/probe order. An SDIO func driver/device must always be suspended *before* the SDIO card device. Additionally the corresponding MMC host, must be suspended after the SDIO card device. Vice verse applies to the resume sequence. As this patch enables asynchronous suspend, I am worried that it will break this dependency chain. What do you think? Kind regards Ulf Hansson > --- > Changes in v3: > - Add test result in commit message > > drivers/mmc/core/sdio.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c > index 16d838e..530ce88 100644 > --- a/drivers/mmc/core/sdio.c > +++ b/drivers/mmc/core/sdio.c > @@ -1113,6 +1113,8 @@ int mmc_attach_sdio(struct mmc_host *host) > pm_runtime_enable(&card->dev); > } > > + device_enable_async_suspend(&card->dev); > + > /* > * The number of functions on the card is encoded inside > * the ocr. > @@ -1133,6 +1135,8 @@ int mmc_attach_sdio(struct mmc_host *host) > */ > if (host->caps & MMC_CAP_POWER_OFF_CARD) > pm_runtime_enable(&card->sdio_func[i]->dev); > + > + device_enable_async_suspend(&card->sdio_func[i]->dev); > } > > /* > -- 1.7.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/