[9front] [PATCH] usbxhci: wait for reset to complete before continuing initialization

[9front] [PATCH] usbxhci: wait for reset to complete before continuing initialization

[Michael Forney]

The xhci spec says that the HCRST bit is cleared once the reset is
complete, and that no operational or runtime registers shall be
written while the bit is set.

Waiting for the reset to complete fixes initialization of some host
controllers, such as the ASMedia ASM1142, which otherwise enter an
endless init-recover loop.

Also, add a comment about the reason for the 1ms delay. This appears
to work around a system hang bug in intel chipsets through the 400
series (see errata 15 in [0]).

[0] https://cdrdv2-public.intel.com/620856/620856-009.pdf
---
I was trying to figure out why the two USB 3.1 ports on my system
didn't work, and adding some debug prints in init() appeared to
provide enough delay that it started working. I believe the root
cause is not waiting for HCRST to clear, which is what xhci drivers
in other operating systems do.

diff a39eb30ffa2138a817bd787fdfd25eb65927e7d4 7fdb19aa0098ee41192d1a478db8dfed3514c706
--- a/sys/src/9/port/usbxhci.c
+++ b/sys/src/9/port/usbxhci.c
@@ -481,7 +481,10 @@
 		tsleep(&up->sleep, return0, nil, 10);
 
 	ctlr->opr[USBCMD] = HCRST;
+	/* some intel controllers require 1ms delay after reset */
 	delay(1);
+	for(i=0; (ctlr->opr[USBCMD] & HCRST) != 0 && i<100; i++)
+		tsleep(&up->sleep, return0, nil, 10);
 	for(i=0; (ctlr->opr[USBSTS] & (CNR|HCH)) != HCH && i<100; i++)
 		tsleep(&up->sleep, return0, nil, 10);
 

Re: [9front] [PATCH] usbxhci: wait for reset to complete before continuing initialization

[ori]

Quoth Michael Forney <mforney@mforney.org>:
> 
> The xhci spec says that the HCRST bit is cleared once the reset is
> complete, and that no operational or runtime registers shall be
> written while the bit is set.
> 
> Waiting for the reset to complete fixes initialization of some host
> controllers, such as the ASMedia ASM1142, which otherwise enter an
> endless init-recover loop.
> 
> Also, add a comment about the reason for the 1ms delay. This appears
> to work around a system hang bug in intel chipsets through the 400
> series (see errata 15 in [0]).
> 

looks good to me, doesn't cause any problemms for my systems.