From: Maximilian Luz <luzmaximilian@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: xhci: Increase timeout for HC halt
Date: Tue, 11 May 2021 10:42:14 +0200 [thread overview]
Message-ID: <c1b24d1a-497d-a303-7b54-e1d65402f08c@gmail.com> (raw)
In-Reply-To: <828bf140-1be6-9d92-1598-bfdf689bbdae@linux.intel.com>
On 5/11/21 9:19 AM, Mathias Nyman wrote:
> On 11.5.2021 3.29, Maximilian Luz wrote:
>> On some devices (specifically the SC8180x based Surface Pro X with
>> QCOM04A6) HC halt / xhci_halt() times out during boot. Manually binding
>> the xhci-hcd driver at some point later does not exhibit this behavior.
>> To work around this, double XHCI_MAX_HALT_USEC, which also resolves this
>> issue.
>>
>> Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
>> ---
>> drivers/usb/host/xhci-ext-caps.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
>> index fa59b242cd51..fb591e41cd50 100644
>> --- a/drivers/usb/host/xhci-ext-caps.h
>> +++ b/drivers/usb/host/xhci-ext-caps.h
>> @@ -7,8 +7,8 @@
>> * Author: Sarah Sharp
>> * Some code borrowed from the Linux EHCI driver.
>> */
>> -/* Up to 16 ms to halt an HC */
>> -#define XHCI_MAX_HALT_USEC (16*1000)
>> +/* Up to 32 ms to halt an HC */
>> +#define XHCI_MAX_HALT_USEC (32 * 1000)
>
> xHCI spec has a 16ms limit stated in several places, for example section 5.4.1
> "xHC is forced to halt within 16 ms. of software clearing the R/S bit to ‘0’,
> irrespective of any queued Transfer or Command Ring activity"
Right, thanks, I wasn't aware of this.
> To make sure hosts work we could increase it to 32, but comment could be
> changed to make sure it doean't get optimized back to 16 ms later.
>
> How about:
> /* HC should halt within 16 ms, but use 32 ms as some in reality take longer */
>
> If that's ok I can take this and modify the comment
That makes sense, yes. Please feel free to change that comment as you wish.
Regards,
Max
prev parent reply other threads:[~2021-05-11 8:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 0:29 [PATCH] usb: xhci: Increase timeout for HC halt Maximilian Luz
2021-05-11 6:26 ` Greg Kroah-Hartman
2021-05-11 8:40 ` Maximilian Luz
2021-05-11 7:19 ` Mathias Nyman
2021-05-11 8:42 ` Maximilian Luz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c1b24d1a-497d-a303-7b54-e1d65402f08c@gmail.com \
--to=luzmaximilian@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mathias.nyman@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).