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

[Basavaraj Natikar <bnatikar@amd.com>]

On 4/18/2023 8:55 PM, Greg KH wrote:
> On Tue, Apr 18, 2023 at 07:38:17PM +0530, Basavaraj Natikar wrote:
>> xHC system resume time may increase due to a 120ms delay.
> I'm sorry, but I can not understand this sentence.  Is the delay 120ms
> too long?  Or too short?  Or will it change to be always at least 120ms?
> Or something else?

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

This patch will prevent 120 ms for each XHCI controller during system
resume.

>
>> A PME# signal
>> will trigger the xHC host to resume runtime, and the host must wait for a
>> missed U3 LFPS wake signal before re-checking for port activity. It may
>> be necessary to wait only for auto-resume cases. Add a check only for
>> runtime resume to avoid the delay for other PM events so that the resume
>> time can be improved.

Once XHCI controller in runtime suspended state (D3), on USB device hotplug
controller will resume (D0) and check for pending port events if no events,
wait for 120 ms to re-check for port activity i.e. the first wake signalling
failed is handled in below changes.

https://lore.kernel.org/all/20210311115353.2137560-3-mathias.nyman@linux.intel.com/

This check adds delay to system resume case as well, which may be only required for
runtime resume (auto resume) case.

So added an extra check to handle the runtime resume case only.

Will retry to reword accordingly as above.

If you have any input, please let me know.  

Thanks,
--
Basavaraj

> I also can not understand these last two sentences, can you try to
> reword it a bit differently?
>
> thanks,
>
> greg k-h