RE: [RFC PATCH] ata: ahci: Enable DEVSLP by default on x86 modern standby platform

[Mario.Limonciello]

> -----Original Message-----
> From: Srinivas Pandruvada [mailto:srinivas.pandruvada@xxxxxxxxxxxxxxx]
> Sent: Monday, July 2, 2018 5:09 PM
> To: Hans de Goede; Tejun Heo
> Cc: rjw@xxxxxxxxxxxxx; alan.cox@xxxxxxxxx; linux-ide@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx; Limonciello, Mario
> Subject: Re: [RFC PATCH] ata: ahci: Enable DEVSLP by default on x86 modern
> standby platform
> 
> Hi Hans,
> 
> On Mon, 2018-07-02 at 23:27 +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 02-07-18 22:21, Tejun Heo wrote:
> > > On Mon, Jul 02, 2018 at 12:08:45PM -0700, Srinivas Pandruvada
> > > wrote:
> > > > From: Srinivas <srinivas.pandruvada@xxxxxxxxxxxxxxx>
> > > >
> > > > One of the requirement for modern x86 system to enter lowest
> > > > power mode
> > > > (SLP_S0) is SATA IP block to be off. This is true even during
> > > > when
> > > > platform is suspended to idle and not only in opportunistic
> > > > (runtime)
> > > > suspend.
> > > >
> > > > Several of these system don't have traditional ACPI S3, so it is
> > > > important that they enter SLP_S0 state, to avoid draining battery
> > > > even
> > > > during suspend even with out of the box Linux installation.
> >
> > Question can systems which do have S3 not also enter SLP_S0 state
> > during
> > normal operation to save power?
> S3 systems don't enter SLP_S0. When in suspend via S3 all devices are
> simply turn off all except some for wakeup.
> 
> >
> > I guess the change of that happening without being in a suspend like
> > state
> > (screen turned off, etc), is very small because there will always be
> > something blocking entering of SLP_S0, so that it is not worth
> > bothering looking into SLP_S0 on systems which use S3 for suspend ?
> >
> SLP_S0 is suspend like state without big exit latency. To achieve this
> state the IP blocks, clocks and voltage rails needs to be in certain
> predefined state. If anyone of those constraints not met, the system
> will not reach this state. Unlike S3, we need to make sure that devices
> reach right suspend state. In S3 we wouldn't have cared much, as
> BIOS/ACPI will take action and turn off anyway.
> If you achieve SLP_S0, the power will be lower or equal to S3 but will
> be immediately able to resume.
> 
> 
> > > > SATA IP block doesn't get turned off till SATA is in DEVSLP mode.
> > > > Here
> > > > user has to either use scsi-host sysfs or tools like powertop to
> > > > set
> > > > the sata-host link_power_management_policy to min_power.
> > > >
> > > > This change sets by default link power management policy to
> > > > min_power
> > > > for some platforms.  To avoid regressions, the following
> > > > conditions
> > > > are used:
> > > > - The kernel config is already set to use med_power_with_dipm or
> > > > deeper
> > > > - System is a modern standby system using ACPI low power idle
> > > > flag
> > > > - The platform is not blacklisted for Suspend to Idle and suspend
> > > > to idle is used instead of S3
> > > > This combination will make sure that systems are fairly recent
> > > > and
> > > > since getting shipped with modern standby standby, the DEVSLP
> > > > function
> > > > is already validated.
> > > >
> > > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxx
> > > > el.com>
> > >
> > > Seems sane to me.  Hans, what do you think?
> >
> > I think this is going in the right direction, but min_power enables
> > both DEVSLP and HIPM, AFAIK Windows at least in the past did not
> > enable HIPM be default.
> 
> Windows and Linux will need to meet the same criteria to reach SLP_S0
> state. OS is not deciding whether we meet criteria or not, it is
> firmware deciding, and it will look for SATA IP to be in certain
> predefined state, before generating this SLP_S0 signal.
> 
> 
> > Srinivas can you figure out what Windows does wrt HIPM?
> 
> We can see that under Windows the SATA rail voltage is dropped. I don't
> know if there is any other method other than DEVSLP configuration. But
> I will surely check around.

Something to keep in mind is that on Windows most systems are shipped
with RAID ON rather than AHCI.  So Windows defaults for AHCI link power management
can't apply in the RAID ON case.  It would rather be Intel RST driver behaviors
for how it internally manages DIPM , HIPM, DEVSLEEP.

So I checked a few things today.

1) On a system with modern standby with SATA SSD set to AHCI; link power management
isn't even exposed in power options GUI. (Maybe to prevent problems with SLPS0?)
I didn't see it in powercfg /q (which is supposed to list configurable options too)

I found out how to unhide it with powercfg and after unhiding it I found that this is the
option exposed:
https://docs.microsoft.com/en-us/windows-hardware/customize/power-settings/disk-settings-link-power-management-mode---hipm-dipm

It's got 5 indexes:
Active,
HIPM
HIPM+DIPM
DIPM
Lowest

2) With some internal folks and they tell me that HIPM and DIPM are defaulting
on with RST driver, however this can be changed with registry key as necessary.

> 
> 
> > We may need a new med_power_with_dipm_and_devslp level if windows
> > does
> > not enable HIPM by default on these systems. In hind sight we really
> > should have separate bools for each, rather then coding this in
> > a single level, ah well.
> Agree. We can certainly do this for even safer implementation.

Microsoft documentation above doesn't seem to mention DEVSLP but random forums
(http://mywindowshub.com/add-ahci-link-power-management-hipmdipm-power-options-windows-10/)
seem to indicate that Lowest is "HIPM, DIPM and DEVSLP" (if supported by storage device).