Re: [PATCH 2/2] xhci: Improve the XHCI resume time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/20/2023 10:33 PM, Mark Hasemeyer wrote:
>> It may be necessary to wait only for auto-resume cases.
> I find this comment misleading as the patch assumes that it's only necessary to
> wait for auto-resume cases. Are there any cases where the driver should wait
> during system-resume?

Only in case of auto-resume (runtime resume).

Rewording the commit message as follows.

Each XHCI controller while xhci_resumes by default takes 120 ms more if
there is no activity on the ports or no ports connected. Therefore, if
there are more USB controllers on the system, 120 ms more per controller
will add delay to system resume from suspended states like s2idle, S3 or
S4 states.

Once the XHCI controller is in runtime suspended state (D3 state), on USB
device hotplug controller will runtime resume (D0 state) and check for
pending port events if no events, wait for 120 ms to re-check for port
activity to handle missed wake signal. 

A delay of 120 ms more to re-check for port activity is needed only in
auto-resume (runtime resume) cases. Hence, add a check only for runtime
resume from runtime suspend (D3->D0) to avoid the 120ms more delay for
other PM events (system resume from suspend states like s2idle, S3 or S4
states) so that the system resume time can be improved.

Please let me know if any inputs.

>
> Also, the commit title could specifically mention "system resume".

Sure will change title "Improve the XHCI system resume time"

Thanks,
--
Basavaraj




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux