From: kbusch@kernel.org (Keith Busch)
Subject: [PATCHv2 6/6] nvme-pci: Use host managed power state for suspend
Date: Thu, 16 May 2019 08:24:11 -0600 [thread overview]
Message-ID: <20190516142411.GC23333@localhost.localdomain> (raw)
In-Reply-To: <20190516062528.GA29930@lst.de>
On Wed, May 15, 2019@11:25:28PM -0700, Christoph Hellwig wrote:
> >
> > #ifdef CONFIG_PM_SLEEP
> > +static int nvme_deep_state(struct nvme_dev *dev)
> > +{
> > + struct pci_dev *pdev = to_pci_dev(dev->dev);
> > + struct nvme_ctrl *ctrl = &dev->ctrl;
> > + int ret = -EBUSY;;
> > +
> > + nvme_start_freeze(ctrl);
> > + nvme_wait_freeze(ctrl);
> > + nvme_sync_queues(ctrl);
> > +
> > + if (ctrl->state != NVME_CTRL_LIVE &&
> > + ctrl->state != NVME_CTRL_ADMIN_ONLY)
> > + goto unfreeze;
> > +
> > + if (dev->host_mem_descs) {
> > + ret = nvme_set_host_mem(dev, 0);
> > + if (ret < 0)
> > + goto unfreeze;
> > + }
>
> I've still not heard an explanation of anyone why we need to disable
> the HMB here. Even if there are states where we have to disable it
> we need to restrict it to just those system power states where we have
> to, as reclaiming and recreating the HMB is very costly for the device.
We're not really reclaiming the HMB here. We're just telling the
controller to stop using it for a moment, and we return it back to the
device in the same condition it left it via NVME_HOST_MEM_RETURN. That
should minimize bringup latency.
But also I don't think we should have to do this, or would at least like
to see something more authoritative explaining which device or platform
power states require disabling HMB.
> > + if (ret) {
> > + /*
> > + * Clearing npss forces a controller reset on resume. The
> > + * correct value will be resdicovered then.
> > + */
> > + ctrl->npss = 0;
> > + nvme_dev_disable(dev, true);
>
> Can't we just reuse the nvme_dev_disable call in the caller?
We could, but it looks less pleasent for the caller since needs to handle
three return possibilities: success, disable, and abort suspend.
> > + if (dev->host_mem_descs) {
> > + ret = nvme_setup_host_mem(dev);
> > + if (ret)
> > + goto reset;
> > + }
>
> This call could/should set the Memory Return bit in the Set Features
> call to enable the HMB.
Yep.
> > 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() && ndev->ctrl.npss)
> > + return nvme_deep_state(ndev);
>
> And this still needs a comment why we try to just meddle with the
> power state and queues instead of turning the device off only if
> not suspended via firmware.
Sure thing.
next prev parent reply other threads:[~2019-05-16 14:24 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-15 16:36 [PATCH 1/6] nvme-pci: Fix controller freeze wait disabling Keith Busch
2019-05-15 16:36 ` [PATCH 2/6] nvme-pci: Don't disable on timeout in reset state Keith Busch
2019-05-16 3:07 ` Ming Lei
2019-05-16 14:33 ` Keith Busch
2019-05-16 6:27 ` Christoph Hellwig
2019-05-15 16:36 ` [PATCH 3/6] nvme-pci: Unblock reset_work on IO failure Keith Busch
2019-05-16 3:13 ` Ming Lei
2019-05-16 14:14 ` Keith Busch
2019-05-17 2:31 ` Ming Lei
2019-05-16 6:28 ` Christoph Hellwig
2019-05-15 16:36 ` [PATCH 4/6] nvme-pci: Sync queues on reset Keith Busch
2019-05-16 3:34 ` Ming Lei
2019-05-16 6:29 ` Christoph Hellwig
2019-05-16 14:08 ` Keith Busch
2019-05-16 13:43 ` Minwoo Im
2019-05-15 16:36 ` [PATCH 5/6] nvme: Export get and set features Keith Busch
2019-05-16 6:26 ` Christoph Hellwig
2019-05-16 13:47 ` Minwoo Im
2019-05-15 16:36 ` [PATCHv2 6/6] nvme-pci: Use host managed power state for suspend Keith Busch
2019-05-15 19:33 ` Mario.Limonciello
2019-05-15 19:34 ` Keith Busch
2019-05-15 19:43 ` Mario.Limonciello
2019-05-16 6:25 ` Christoph Hellwig
2019-05-16 14:24 ` Keith Busch [this message]
2019-05-17 9:08 ` Christoph Hellwig
2019-05-16 9:29 ` Rafael J. Wysocki
2019-05-16 14:26 ` Keith Busch
2019-05-16 18:27 ` Kai-Heng Feng
2019-05-16 18:33 ` Mario.Limonciello
2019-05-16 19:38 ` Keith Busch
2019-05-16 20:25 ` Rafael J. Wysocki
2019-05-16 20:39 ` Keith Busch
2019-05-16 20:56 ` Rafael J. Wysocki
2019-05-17 8:39 ` Rafael J. Wysocki
2019-05-17 9:05 ` Christoph Hellwig
2019-05-17 9:17 ` Rafael J. Wysocki
2019-05-17 9:35 ` Christoph Hellwig
2019-05-17 10:34 ` Rafael J. Wysocki
2019-05-22 6:47 ` Kai Heng Feng
2019-05-22 15:52 ` Christoph Hellwig
2019-05-22 16:02 ` Keith Busch
2019-05-22 16:35 ` Mario.Limonciello
2019-05-22 16:56 ` Keith Busch
2019-05-22 23:08 ` Keith Busch
2019-05-23 15:27 ` Keith Busch
2019-05-17 9:22 ` Kai-Heng Feng
2019-05-17 9:32 ` Rafael J. Wysocki
2019-05-16 20:24 ` Rafael J. Wysocki
2019-05-16 2:43 ` [PATCH 1/6] nvme-pci: Fix controller freeze wait disabling Ming Lei
2019-05-17 18:40 ` Keith Busch
2019-05-16 6:27 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190516142411.GC23333@localhost.localdomain \
--to=kbusch@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox