On Wed, Nov 29, 2023 at 01:47:16PM -0500, Phillip Susi wrote: > Niklas Cassel <Niklas.Cassel@xxxxxxx> writes: > > > The reason why many platforms do this override, is because: > > "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." > > > > "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." Note that I copied this text from the original patch authored by someone at Intel. I've seen similar claims from people at AMD. > > What? I'm confused. Here are several things that come to mind that > when taken together with this statement confuse me. Perhaps I am wrong > about one or more of them? > > 1) DEVSLP is an odd thing they invented to have ACPI twiggle a GPIO bit > to cut the power rails to CDROM drives that aren't in active use. > > 2) SATA ALPM has the SATA controller automatically transition the sata > link to lower power states when it isn't being used, and back again on > use. Yes, the HBA can initiate a transition to DevSleep automatically using ALPM, however, the specs says that: -DevSleep is disabled by the device on power up (and has to be enabled by a SET FEATURES command). -PxDEVSLP.ADSE (Aggressive Device Sleep Enable) for the port is 0 on reset (the kernel resets the HBA on boot, so ADSE will be disabled for the port). (DevSleep is never initiated by the device.) The kernel will only do: -SET FEATURES to enable the DevSleep feature on the device, and -Set PxDEVSLP.ADSE to 1 If _all_ of the following are true: 1) SADM and SDS bits are set in the HBA 2) the device reports that it supports DevSleep 3) PxDEVSLP.DSP is set for the port 4) the kernel LPM policy is either ATA_LPM_MIN_POWER or ATA_LPM_MIN_POWER_WITH_PARTIAL See: https://github.com/torvalds/linux/blob/v6.7-rc3/drivers/ata/libahci.c#L2322-L2324 This means that if any of 1-5 it not true, the HBA ALPM will never transition the device into DevSleep state. AFAICT, the HBA asserts the DEVSLP signal as long as being in DevSleep state. To exit from DevSleep state you can just issue an I/O like normal using PxCI, or write to PxCMD.ICC to force a state change. > 3) The SATA controller can not be suspended until all of its ports are > suspended. > > 4) Suspending a SATA port does not happen during ALPM, but rather only > either during system suspend, or when you enable runtime pm on the disk > and the ata port in sysfs ( both are disabled by default ). > > A quick google led me to this: https://smarthdd.com/device_sleep.htm > > Which indicates that this DEVSLP thing is now being used to send an OOB > signal to a SATA SSD so that it can power down its PHY completely, but > isn't that what ATA SLEEP is for? aka. hdparm -Y. That command tells > the drive that it can power down its PHY and then the host can power > down its PHY and it takes a sata link reset to wake the drive back up. > The link reset is easy to detect with minimum circuitry that is far > simpler than the full sata PHY. > > It sounds like somebody decided to hack an OOB signal into ALPM rather > than use ATA SLEEP, but why? I guess you need to ask Intel. I assume that their firmware simply requires the DEVSLP signal to be asserted in order to enter lower CPU power states. If you have a signal, it is easy for the HW logic to detect if the signal is set or not. If you just send a command to the device, if it not easy for HW logic to determine which state is in. It would need to read some registers or similar. Sounds way more complex than just having a logic gate. Kind regards, Niklas
