On Thu, Jan 14, 2021 at 10:12:13AM +0000, claudiu.bez...@microchip.com wrote: > Up to this moment we treat this backup mode as S2R mode since the memory > was kept in self-refresh mode. Each driver was saving/restoring in/from RAM > the content of associated registers in the suspend/resume phase.
This is exactly what suspend-to-RAM is. The system is largely powered down with the state saved in RAM, and the RAM placed in self-refresh mode. Some devices or parts of devices may remain powered up if needed to be a wake-up source. > The questions that arries this topic (Heiner, Russel, anyone involved in > the discussion, correct me if I wrongly understood): > 1/ is it OK to still treat this backup mode as a S2R mode or as a hibernate > mode? Since hibernate would treat the devices (including Ethernet PHY in > this case) as they were just powered and restore the registers content but > taking into account that in backup mode we keep the RAM in self-refresh? Hibernate mode is a deeper power-saving mode, where all that applies with suspend-to-ram applies, plus the critical contents of the RAM is stored to non-volatile media, and the RAM powered down in addition to what would also be powered down in the suspend-to-ram case. If you are placing the RAM in self-refresh and powering the system down, you are in suspend-to-ram mode, not hibernate mode. > 2/ is it OK to have these kind of reconfiguration of one device that end up > in suspend mode with no power (in this case the Ethernet PHY) due to a > system power cut off (in this case CPU + PMIC)? You have nothing out of the ordinary here. Going back years, the Assabet/Neponest (SA1110 based platform) does this. When the CPU enters suspend mode, a pin on the processor indicates to the external world that has happened, and that cuts power to most of the system including the smc91x and integrated PHY. (it doesn't use phylib.) So there's really nothing special about your situation; from what you have described, it's a pretty standard suspend-to-ram implementation. As I've said, if phylib/PHY driver is not restoring the state of the PHY on resume from suspend-to-ram, then that's an issue with phylib and/or the phy driver. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
