On Thu, Jul 20, 2023 at 07:55:09PM +0530, Manivannan Sadhasivam wrote: > On Tue, Jul 18, 2023 at 03:34:26PM +0530, Manivannan Sadhasivam wrote: > > On Mon, Jul 17, 2023 at 02:36:19PM -0400, Frank Li wrote: > > > On Mon, Jul 17, 2023 at 10:15:26PM +0530, Manivannan Sadhasivam wrote: > > > > On Wed, Apr 19, 2023 at 12:41:17PM -0400, Frank Li wrote: > > > > > Introduced helper function dw_pcie_get_ltssm to retrieve SMLH_LTSS_STATE. > > > > > Added API pme_turn_off and exit_from_l2 for managing L2/L3 state transitions. > > > > > > > > > > Typical L2 entry workflow: > > > > > > > > > > 1. Transmit PME turn off signal to PCI devices. > > > > > 2. Await link entering L2_IDLE state. > > > > > > > > AFAIK, typical workflow is to wait for PME_To_Ack. > > > > > > 1 Already wait for PME_to_ACK, 2, just wait for link actual enter L2. > > > I think PCI RC needs some time to set link enter L2 after get ACK from > > > PME. > > > > > One more comment. If you transition the device to L2/L3, then it can loose power > if Vaux was not provided. In that case, can all the devices work after resume? > Most notably NVMe? I have not hardware to do such test, NVMe driver will reinit everything after resume if no L1.1\L1.2 support. If there are L1.1\L1.2, NVME expect it leave at L1.2 at suspend to get better resume latency. This API help remove duplicate codes and it can be improved gradually. > > - Mani > > > -- > மணிவண்ணன் சதாசிவம்
