[PATCH] nvme-pci: set some AMD PCIe downstream storage device to D3 for s2idle
Keith Busch
kbusch at kernel.org
Tue May 25 12:55:43 PDT 2021
On Tue, May 25, 2021 at 06:27:52PM +0000, Limonciello, Mario wrote:
> [AMD Official Use Only]
>
> > > 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.
> >
> > I don't think you mean APST. That feature enables controller power state
> > autonomy, and we do not messed with that on the driver's suspend path.
>
> Relying upon the drive to go into the appropriate low power state via APST is one
> aspect of it, and then ASPM for the PCIe link state.
That's not quite accurate. The driver has no use for APST in the s2idle
path. We use explicit host managed power settings here, and this works
the same with controllers that don't even support the optional APST
feature.
> > We do use the explicit nvme specific host managed power state feature,
> > though.
> >
> > But I also don't see why this is specific to nvme. Are you saying that
> > if a some other protocol device was in the same slot, it would be okay
> > to use its protocol specific power settings? That doesn't sound right
>
> Maybe Prike can comment more here, but all of these s2idle designs we're talking
> about are mobile designs without external PCIe. OEMs make the decisions on
> what PCIe devices are chosen and how they go into the lowest state.
While assuming nvme might be a plausible design choice, for any device
type occupying the slot, any driver bound to it needs to make the device
ready for cold before letting the s2idle process proceed. That's why the
quirk shouldn't be nvme driver specific.
More information about the Linux-nvme
mailing list