From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69F58C04AB1 for ; Thu, 9 May 2019 21:40:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3AFB22177B for ; Thu, 9 May 2019 21:40:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557438004; bh=h0vamqYqgeYBxehRh0DXqKVcaFd/9IQkmJmfb7YuCY8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=HTcWPF1VrHjqsyYOXxCQ51hWs9dzhzuA1ieuc2DHdoBD3pfMEUKOcK5PpavT2/+iw Qb6MfePfsjw+2mDwV49zI8T1AuIDHaaUL4tKyG6YGb55jwSWu4CUkDh19Iso+HkEFj +YoZ53FnxUMQtuM9M4+ZhBhn28t/vkhVbpZjsqe8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726853AbfEIVkD (ORCPT ); Thu, 9 May 2019 17:40:03 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:42511 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726219AbfEIVkC (ORCPT ); Thu, 9 May 2019 17:40:02 -0400 Received: by mail-oi1-f195.google.com with SMTP id k9so3056636oig.9; Thu, 09 May 2019 14:40:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rWqUG/1Q13/Mgi8WYJUSOwOl7Nvw/G1FqiVogS2PJUU=; b=LFEtzodD7pm6u/S9cgqcjmWu4IoOF6tDGg734x3h8Bjq2RKSs1UyB4/A7aOwPLdsOr dmKEvg1Lf0ZNIc8c3u/fY4BOOLV73SzUI0b4zTLa7Vk1Dvzoe0aLURF/ze+Zl+nnHSqb oODTpv2m2GCYYGV4VNsyI/QlHnfG6lfvPs4JgHTMUYAPOYOPtkcxtQw9kJQW90Di+I1g wXxmQJ9x0SwsTJmGzN6KbU3L6XeHfeSTEbMJPo21GqGpeCPAzU9lAhZtKkvgXh3igcDn cREPrbSVm8tzblININGRky6LHTWSFSm8xqZwVjXGkXXD4bJkmNV/nvKBQvW9hqo0IGuk LXcA== X-Gm-Message-State: APjAAAV3yms4BoeIbdDO2UysgYJLcc9s3mG+OFWzVjXPSKXwzVm19NRM fz8yTKEpOrb/sl9N4DhZZFfT7TikHl/CcDa6ovw= X-Google-Smtp-Source: APXvYqyKl5SlkcDFgO5vnRTd1pL4AcZ5QulP6DrlxtnNmeZsn1LLArtlg5CH58bHUEjFNoX4LuDOC98A5i+IaWekgTQ= X-Received: by 2002:aca:f4c3:: with SMTP id s186mr2791143oih.68.1557438002008; Thu, 09 May 2019 14:40:02 -0700 (PDT) MIME-Version: 1.0 References: <064701C3-2BD4-4D93-891D-B7FBB5040FC4@canonical.com> <20190509095601.GA19041@lst.de> <225CF4F7-C8E1-4C66-B362-97E84596A54E@canonical.com> <20190509103142.GA19550@lst.de> <31b7d7959bf94c15a04bab0ced518444@AUSX13MPC101.AMER.DELL.COM> <20190509192807.GB9675@localhost.localdomain> <20190509211608.GC9675@localhost.localdomain> In-Reply-To: <20190509211608.GC9675@localhost.localdomain> From: "Rafael J. Wysocki" Date: Thu, 9 May 2019 23:39:50 +0200 Message-ID: Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle To: Keith Busch Cc: "Rafael J. Wysocki" , Mario Limonciello , Kai-Heng Feng , Christoph Hellwig , Jens Axboe , Sagi Grimberg , Linux PM , Rafael Wysocki , Linux Kernel Mailing List , linux-nvme , Keith Busch Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 9, 2019 at 11:21 PM Keith Busch wrote: > > On Thu, May 09, 2019 at 10:54:04PM +0200, Rafael J. Wysocki wrote: > > On Thu, May 9, 2019 at 9:33 PM Keith Busch wrote: > > > #include > > > @@ -2851,6 +2852,8 @@ static int nvme_suspend(struct device *dev) > > > struct pci_dev *pdev = to_pci_dev(dev); > > > struct nvme_dev *ndev = pci_get_drvdata(pdev); > > > > > > + if (!pm_suspend_via_firmware()) > > > + return nvme_set_power(&ndev->ctrl, ndev->ctrl.npss); > > > > You probably want to call pci_save_state(pdev) in the branch above to > > prevent pci_pm_suspend_noirq() from calling pci_prepare_to_sleep() > > going forward, so I would write this routine as > > > > if (pm_suspend_via_firmware()) { > > nvme_dev_disable(ndev, true); > > return 0; > > } > > > > pci_save_state(pdev) > > return nvme_set_power(&ndev->ctrl, ndev->ctrl.npss); > > Ah, good point. I'll make sure that's added and will wait to see hear if > there's any other feedback. > > I am trying to test the paths by faking out PS capabilities, and have > a question on how to force each: > > Running "rtcwake -m freeze ...", that takes the !pm_suspend_via_firmware() > path as I expected. > > But trying to test the original path, I thought using "-m mem" would > have been a suspend via firmware, but that is still returning false. > > Is that expected? Yes, if s2idle is the default on that platform. You should be able to switch over to S3 by writing "deep" into /sys/power/mem_sleep as long as it is supported on that platform at all. > I've only tried this on one platform so far, so might > just be this particular one is missing a firmware capability. You can check that by looking into /sys/power/mem_sleep (if there is only "[s2idle]" in there, S3 is not supported).