Hi Jeffrey, On Fri, 5 Mar 2021 at 15:49, Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote: > > On 3/5/2021 7:09 AM, Loic Poulain wrote: > > mhi_cntrl->timeout_ms is set by the controller and indicates the > > maximum amount of time the controller device will take to be ready. > > In case of PCI modems, this value is quite high given modems can take > > up to 15 seconds from cold boot to be ready. > > > > Reusing this value in mhi_pm_resume can cause huge resuming latency > > and delay the whole system resume (in case of system wide suspend/ > > resume), leading to bad use experience. > > I think this needs more explanation. The timeout is a maximum value. > You indicate that 2 seconds is more than enough for any MHI device to > exit M3 (citation needed), but 15 seconds is too much? The difference > should only be apparent when the device doesn't transition in the timeout. > > Put another way, this doesn't say why 15 seconds is bad, if every device > only needs 2, given that wait_event_timeout() doesn't always wait for > the entire timeout value if the event occurs earlier. Yes, right that deserves an explanation: depending on the platform and the suspend type (deep, s2idle), the PCI device may or may not lose power. In case power is maintained, there is no problem and the controller is successfully moved to M0. But in case of power loss, the device is going to restart, and MHI resuming is going to timeout and fail since M0 will never be reached. On PCI side we simply reinitialize the controller in case of resume failure. So in other words, MHI resume is expected to fail in some cases and it should be handled with minimal impact on the system. Regards, Loic
