Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2280878ybd; Mon, 24 Jun 2019 03:52:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqxMpjszZVCYZxzbiV1wCUdjZXt3g78hWsehjvBBm6qtny9EOKDgPmBCRn04y4ofBSlkKTln X-Received: by 2002:a17:902:934a:: with SMTP id g10mr138122554plp.18.1561373520586; Mon, 24 Jun 2019 03:52:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561373520; cv=none; d=google.com; s=arc-20160816; b=tQaKOAJpnIEK51hz6+ZdfOsdVmpPDo1NOGE+ns+WjBysK+eNspkJJbzOZKNWmCsys4 3a4geBYbZxHHcr4pFQBaE8XzIWV5fBaJ+ahO8DM9iLvDIaNAiFv8moLR677RbzCxagA1 EmPvlbmb2JW+xjx84dCNcY4FqBnrstBdqSP1BPc3PSbYjTo19EWNPkKLiQQbQbHTJmkf 5Dk31ItCKwGbEXDvZ3uZ3exd5urih9e6niPEE7egtucUEkqpzG7Q+IYsSPNlbq0Mr4X2 CLtmlY0YRssaNZJnThMVSjUUbJ5YCJJp6f8ndgLKUKEfCtupEoGfqZre9lif4bXy3Qmh ICxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=t2vNhPqnjovK4zG9TO7OvRbTUDaxPdCfrbFcCQ4/rec=; b=tvkehObcCIIRlKoSh0ekHKcV5kjhQb/afTKrOkdgYqyASzcgQNx3LvfQlkqEHctHip s/28LysXFSBV30xO67gFfrjwV6vsHrjn25OKozkRRTfgxv6IWywzyGi2fJJGzMUxAtVI KJJna+Ndt9JM9QG30BanEYgyys3NgTn4K5KYatmiZQDsS6Qxhh/OzAAeukE2HUQTnZpQ dobQZTFNdpbRjsfxyzBjl7gopzVP3pKS65w+zp3B23lLVrwjRDUkKxyKlroE4r6H+oBX JHkfOSGUqsMWy6D1aGbxNDs0a3o+JxEefxLNBKQv46fpE5+2CRTf217dfGFvR2YhY9WO 4K+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i9si10402402pfr.6.2019.06.24.03.51.44; Mon, 24 Jun 2019 03:52:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729452AbfFXKvj (ORCPT + 99 others); Mon, 24 Jun 2019 06:51:39 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:41557 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728654AbfFXKvh (ORCPT ); Mon, 24 Jun 2019 06:51:37 -0400 Received: by mail-ed1-f67.google.com with SMTP id p15so21092186eds.8 for ; Mon, 24 Jun 2019 03:51:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=t2vNhPqnjovK4zG9TO7OvRbTUDaxPdCfrbFcCQ4/rec=; b=PiWtPD82DbGjyLvrbpRxB0Rdyz1v0DLdrfijbCTxtSj1pKiiaaYvcW2Q9fH1q7sT7b NgmfkThWFbh7DIwLpoLUki6VXmFqUloGn+IE2t4+64RlK758f9iBTVMy1UnFw3BT1W3e uPy1i19U8gpSCQJ7QzCDbzqZn3PFvLWU+OD2t8QumHeXsQOuUStN6/2+GjDqn4pcaOD8 japjhGNzrRyCx1l3g6zlQsMwCYY6fxYzNAEzrUOZ6iymMVK738Sae9v4T8RtRRIp3ACg pryRLuH/h/hdK+synwV2XiJJkg+meh87SWkieXmyXUfnblg2J6VoaAWOAZDPkAndk3JZ VcIw== X-Gm-Message-State: APjAAAVlblafqmm7UPUgY7pRS8CxOVnqn/IhESVlg1Z60VNrq98i0KAM 5Xda/tMxETAMkVkPprD7p3IG+Q== X-Received: by 2002:a50:8b9c:: with SMTP id m28mr121540476edm.53.1561373494788; Mon, 24 Jun 2019 03:51:34 -0700 (PDT) Received: from shalem.localdomain (84-106-84-65.cable.dynamic.v4.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id w17sm3539385edi.15.2019.06.24.03.51.33 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 03:51:34 -0700 (PDT) Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT To: "Rafael J. Wysocki" , "Robert R. Howell" Cc: Kai-Heng Feng , "lenb@kernel.org" , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Mika Westerberg References: <20190403054352.30120-1-kai.heng.feng@canonical.com> <1588383.bXYZMuyLB9@kreacher> <2830645.pXxymQ5XCC@kreacher> From: Hans de Goede Message-ID: Date: Mon, 24 Jun 2019 12:51:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <2830645.pXxymQ5XCC@kreacher> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafael, > Sorry for the long delay. > > I haven't dropped this issue on the floor, I hope that you are still able to follow up here. > > Can you please test the appended patch instead of the previous one? > > I have found some inconsistencies in the handling of hibernation in the ACPI PM domain > and the LPSS driver that should be covered by this patch. I know this is just a testing patch for now, but still I've given it a quick look, some comments inline. > --- > drivers/acpi/acpi_lpss.c | 63 +++++++++++++++++++++++++++++++++++------------ > drivers/acpi/device_pm.c | 30 ++++++++++++++++++++-- > include/linux/acpi.h | 4 ++ > 3 files changed, 79 insertions(+), 18 deletions(-) > > Index: linux-pm/drivers/acpi/device_pm.c > =================================================================== > --- linux-pm.orig/drivers/acpi/device_pm.c > +++ linux-pm/drivers/acpi/device_pm.c > @@ -1171,6 +1171,32 @@ int acpi_subsys_thaw_noirq(struct device > return pm_generic_thaw_noirq(dev); > } > EXPORT_SYMBOL_GPL(acpi_subsys_thaw_noirq); > + > +/** > + * acpi_subsys_restore_noirq - Run the device driver's "noirq" restore callback. > + * @dev: Device to handle. > + */ > +int acpi_subsys_restore_noirq(struct device *dev) > +{ > + /* This is analogous to what acpi_subsys_resune_noirq() does. */ > + if (dev_pm_smart_suspend_and_suspended(dev)) > + pm_runtime_set_active(dev); > + > + return pm_generic_restore_noirq(dev); > +} > +EXPORT_SYMBOL_GPL(acpi_subsys_restore_noirq); > + > +/** > + * acpi_subsys_restore_early - Restore device using ACPI. > + * @dev: Device to restore. > + */ > +int acpi_subsys_restore_early(struct device *dev) > +{ > + int ret = acpi_dev_resume(dev); > + return ret ? ret : pm_generic_restore_early(dev); > +} > +EXPORT_SYMBOL_GPL(acpi_subsys_restore_early); > + > #endif /* CONFIG_PM_SLEEP */ > > static struct dev_pm_domain acpi_general_pm_domain = { > @@ -1192,8 +1218,8 @@ static struct dev_pm_domain acpi_general > .poweroff = acpi_subsys_suspend, > .poweroff_late = acpi_subsys_suspend_late, > .poweroff_noirq = acpi_subsys_suspend_noirq, > - .restore_noirq = acpi_subsys_resume_noirq, > - .restore_early = acpi_subsys_resume_early, > + .restore_noirq = acpi_subsys_restore_noirq, > + .restore_early = acpi_subsys_restore_early, > #endif > }, > }; > Index: linux-pm/drivers/acpi/acpi_lpss.c > =================================================================== > --- linux-pm.orig/drivers/acpi/acpi_lpss.c > +++ linux-pm/drivers/acpi/acpi_lpss.c > @@ -1069,36 +1069,67 @@ static int acpi_lpss_suspend_noirq(struc > return acpi_subsys_suspend_noirq(dev); > } > > -static int acpi_lpss_do_resume_early(struct device *dev) > +static int acpi_lpss_resume_noirq(struct device *dev) > { > - int ret = acpi_lpss_resume(dev); > + struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev)); > + > + /* Follow acpi_subsys_resune_noirq(). */ > + if (dev_pm_may_skip_resume(dev)) > + return 0; > + > + if (dev_pm_smart_suspend_and_suspended(dev)) > + pm_runtime_set_active(dev); > > - return ret ? ret : pm_generic_resume_early(dev); > + if (pdata->dev_desc->resume_from_noirq) { > + int ret = acpi_lpss_resume(dev); > + if (ret) > + return ret; > + } > + > + return pm_generic_resume_noirq(dev); > } Hmm, normally acpi_lpss_resume runs at resume_early time, AFAIK the order of resume callbacks calling is: resume_noirq, resume_early, resume So normally our call order is: ---noirq-phase--- pm_generic_resume_noirq() ---early-phase--- acpi_lpss_resume() pm_generic_resume_early() My patch adding the resume_from_noirq flag, move the calling of acpi_lpss_resume() to the resume_noirq phase (if the flag is set) but kept the generic order, so the call order with the flag set currently is: ---noirq-phase--- pm_generic_resume_noirq() acpi_lpss_resume() ---early-phase--- pm_generic_resume_early() So the order of the 3 calls relative to each other did not change. You are changing this to: ---noirq-phase--- acpi_lpss_resume() pm_generic_resume_noirq() ---early-phase--- pm_generic_resume_early() So now when the flag is set acpi_lpss_resume() runs before pm_generic_resume_noirq(). Is this intentional ? Regards, Hans > > static int acpi_lpss_resume_early(struct device *dev) > { > struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev)); > > - if (pdata->dev_desc->resume_from_noirq) > - return 0; > + if (!pdata->dev_desc->resume_from_noirq) { > + int ret = acpi_lpss_resume(dev); > + if (ret) > + return ret; > + } > > - return acpi_lpss_do_resume_early(dev); > + return pm_generic_resume_early(dev); > } > > -static int acpi_lpss_resume_noirq(struct device *dev) > +static int acpi_lpss_restore_noirq(struct device *dev) > { > struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev)); > - int ret; > > - ret = acpi_subsys_resume_noirq(dev); > - if (ret) > - return ret; > + /* Follow acpi_subsys_restore_noirq(). */ > + if (dev_pm_smart_suspend_and_suspended(dev)) > + pm_runtime_set_active(dev); > + > + if (pdata->dev_desc->resume_from_noirq) { > + int ret = acpi_lpss_resume(dev); > + if (ret) > + return ret; > + } > + > + return pm_generic_restore_noirq(dev); > +} > + > +static int acpi_lpss_restore_early(struct device *dev) > +{ > + struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev)); > > - if (!dev_pm_may_skip_resume(dev) && pdata->dev_desc->resume_from_noirq) > - ret = acpi_lpss_do_resume_early(dev); > + if (!pdata->dev_desc->resume_from_noirq) { > + int ret = acpi_lpss_resume(dev); > + if (ret) > + return ret; > + } > > - return ret; > + return pm_generic_restore_early(dev); > } > > #endif /* CONFIG_PM_SLEEP */ > @@ -1140,8 +1171,8 @@ static struct dev_pm_domain acpi_lpss_pm > .poweroff = acpi_subsys_suspend, > .poweroff_late = acpi_lpss_suspend_late, > .poweroff_noirq = acpi_lpss_suspend_noirq, > - .restore_noirq = acpi_lpss_resume_noirq, > - .restore_early = acpi_lpss_resume_early, > + .restore_noirq = acpi_lpss_restore_noirq, > + .restore_early = acpi_lpss_restore_early, > #endif > .runtime_suspend = acpi_lpss_runtime_suspend, > .runtime_resume = acpi_lpss_runtime_resume, > Index: linux-pm/include/linux/acpi.h > =================================================================== > --- linux-pm.orig/include/linux/acpi.h > +++ linux-pm/include/linux/acpi.h > @@ -925,6 +925,8 @@ int acpi_subsys_freeze(struct device *de > int acpi_subsys_freeze_late(struct device *dev); > int acpi_subsys_freeze_noirq(struct device *dev); > int acpi_subsys_thaw_noirq(struct device *dev); > +int acpi_subsys_restore_noirq(struct device *dev); > +int acpi_subsys_restore_early(struct device *dev); > #else > static inline int acpi_dev_resume_early(struct device *dev) { return 0; } > static inline int acpi_subsys_prepare(struct device *dev) { return 0; } > @@ -938,6 +940,8 @@ static inline int acpi_subsys_freeze(str > static inline int acpi_subsys_freeze_late(struct device *dev) { return 0; } > static inline int acpi_subsys_freeze_noirq(struct device *dev) { return 0; } > static inline int acpi_subsys_thaw_noirq(struct device *dev) { return 0; } > +static inline int acpi_subsys_restore_noirq(struct device *dev) { return 0; } > +static inline int acpi_subsys_restore_early(struct device *dev) { return 0; } > #endif > > #ifdef CONFIG_ACPI > > >