All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Limonciello, Mario" <Mario.Limonciello@amd.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Hans de Goede <hdegoede@redhat.com>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"Liang, Prike" <Prike.Liang@amd.com>,
	"kbusch@kernel.org" <kbusch@kernel.org>,
	"axboe@fb.com" <axboe@fb.com>,
	"sagi@grimberg.me" <sagi@grimberg.me>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"S-k, Shyam-sundar" <Shyam-sundar.S-k@amd.com>
Subject: RE: [PATCH] nvme-pci: set some AMD PCIe downstream storage device to D3 for s2idle
Date: Tue, 25 May 2021 15:18:46 +0000	[thread overview]
Message-ID: <BYAPR12MB26939EE6323113FA9C43E875E2259@BYAPR12MB2693.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20210525141631.GA12576@lst.de>

[Public]

> 
> I think what we're all missing here is that the concept of requring devices
> to go to D3 for suspend to idle is a higher level concept.  

Ah.. so your argument being we should keep it a higher level concept in Linux
kernel too.  IOW maybe even nvme_acpi_storage_d3 shouldn't be living 
in drivers/nvme/host/pci.c, but somewhere else more acpi platform oriented.

>AFAIK this
> comes from this microsoft document:
> 
> https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
> 
> and spread from there.  Note that this document explicitly mentions AHCI
> in addition to NVMe.  It also has some issues that I can spot:
> 
>  - PCIe slots are not specific to storage device, so this really needs to
>    apply to all devices

I don't disagree here but I'll point out that on the Windows side that page
mentions that there is also:
1) A "global" registry key option
2) A hardcoded allowlist

>  - it generall is a rather bad idea to start with as each shutdown not
>    only causes media progam/erase cycles, but also is not very power
>    efficient.
> 
> So what we need is a way for a driver to figure out if for a given
> device it should shut down the device fully or just do something that
> is efficient for saving as much as possible power.  That can be either
> in form of a flag 

So how about a publishing a notification chain that a platform driver can
optionally pick up and set that flag when the device is probed?  Coming
back to my idea to throw this in amd-pmc, that could also potentially
mean moving out the Lenovo DMI quirk and let something like
thinkpad-acpi behave as a notifier and handle it too.

Hans, would appreciate your thoughts here.

> or by splitting the suspend method in different ones
> for different use cases.  Platform-specific code (right now for Intel
> and AMD) can then make sure drivers do get the right requests instead of
> hardcoding platform information in every driver that wants to be able
> to implement intelligent suspend behavior.

This seems like a gross assumption though that evicting the quirks into a
central place that every driver needs to behave the same.  AMD's case is
specific to NVME, particularly because APST will be used otherwise.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2021-05-25 15:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25  2:48 [PATCH] nvme-pci: set some AMD PCIe downstream storage device to D3 for s2idle Prike Liang
2021-05-25  6:21 ` Christoph Hellwig
2021-05-25 12:11   ` Liang, Prike
2021-05-25 12:15     ` Christoph Hellwig
2021-05-25 13:39   ` Deucher, Alexander
2021-05-25 13:54     ` Hans de Goede
2021-05-25 14:06       ` Limonciello, Mario
2021-05-25 14:16         ` Christoph Hellwig
2021-05-25 15:18           ` Limonciello, Mario [this message]
2021-05-25 17:45             ` Keith Busch
2021-05-25 18:27               ` Limonciello, Mario
2021-05-25 19:55                 ` Keith Busch
2021-05-25 20:02                 ` Chaitanya Kulkarni
2021-05-26  8:52             ` Hans de Goede
2021-05-26 13:02               ` Christoph Hellwig
2021-05-26 14:45               ` Keith Busch
2021-05-26 14:55                 ` Rafael J. Wysocki
2021-05-26 17:02                   ` Limonciello, Mario
2021-05-26 17:27                     ` Rafael J. Wysocki
2021-05-26 17:32                       ` Limonciello, Mario
2021-05-26 17:42                       ` Limonciello, Mario
2021-05-25 19:59         ` Keith Busch
2021-05-25 20:09           ` Limonciello, Mario
2021-05-25 20:24             ` Keith Busch
2021-05-25 21:51               ` Limonciello, Mario
2021-05-25 14:09       ` Deucher, Alexander

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=BYAPR12MB26939EE6323113FA9C43E875E2259@BYAPR12MB2693.namprd12.prod.outlook.com \
    --to=mario.limonciello@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Prike.Liang@amd.com \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=axboe@fb.com \
    --cc=hch@lst.de \
    --cc=hdegoede@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.