> > > >>> Otherwise I think we should use a "no-op" suspend, just leaving the > >>> power management to the device, or a simple setting the device to the > >>> deepest power state for everything else, where everything else is > >>> suspend, or suspend to idle. > >> > >> I am not sure I get your idea. Does this “no-op” suspend happen in NVMe > >> driver or PM core? > > > > no-op means we don't want to do anything in nvme. If that happens > > by not calling nvme or stubbing out the method for that particular > > case does not matter. > > Ok, but we still need to figure out how to prevent the device device from > tradition to D3.
This so-called no-op was something that we had experimented with while developing this patch, but found that it would not help power consumption on all drives. That's why we have explicit call to go into deepest power state in current patch. > > > > >>> And of course than we have windows modern standby actually mandating > >>> runtime D3 in some case, and vague handwaving mentions of this being > >>> forced on the platforms, which I'm not entirely sure how they fit > >>> into the above picture. > >> > >> I was told that Windows doesn’t use runtime D3, APST is used exclusively. > > > > As far as I know the default power management modes in the Microsoft > > NVMe driver is explicit power management transitions, and in the Intel > > RST driver that is commonly used it is APST. But both could still > > be comined with runtime D3 in theory, I'm just not sure if they are. > > > > Microsoft has been pushing for aggressive runtime D3 for a while, but > > I don't know if that includes NVMe devices. > > Ok, I’ll check with vendors about this. > No, current Windows versions don't transition to D3 with inbox NVME driver. You're correct, it's explicit state transitions even if APST was enabled (as this patch is currently doing as well).