Messages in this thread | | | Subject | Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk | From | Lu Baolu <> | Date | Mon, 16 Nov 2015 10:18:42 +0800 |
| |
Hi,
On 11/13/2015 11:34 PM, Dmitry Malkin wrote: > On Mon, 9 Nov 2015 15:38:33 +0800, Lu Baolu wrote: >> On Intel platform, if the debug target is connected with debug >> host, enabling DCE bit in command register leads to a hung bus >> state. In the hung state, the host system will not see a port >> connected status bit set. Hence debug target fails to be probed. >> >> The state could be resolved by performing a port reset to the >> debug port from the host xHCI. This patch introduces this work >> around. > Is it correct to call this a "hung bus state"? Wouldn't calling it > "hung port state" more appropriate?
Yes, "hung port state" is more appropriate.
> > I have observed this DCE-enable-related hung port state, > but the reason seemed to be different in my case: > > Citing a note (sic!) from The Holy XHCI Spec, section 7.6.4.1: >> If a Debug Host attempts to attach to a Debug Target before the DCE flag is set, >> both ends of the link shall transition to the Inactive state. >> So a Debug Host should periodically issue a Warm Reset >> to ports that are Inactive to enable a connection to the DbC of the Debug Target.
Exactly. A formal workaround is to periodically issue Warm Resets to ports from debug host.
> Indeed, the inactive state is what I have observed (PLS field of port register PORTSC) > when the DCE bit is set to 1 with the cable already plugged in. > > Now, according to my interpretation of The Hole USB 3.1 spec, section 7.5.2, > which says: >> eSS.Inactive is a state where a link has failed Enhanced SuperSpeed operation. >> A downstream port can only exit from this state when directed, or upon detection of >> an absence of a far-end receiver termination (R RX-DC ) specified in Table 6-21, >> or upon a Warm Reset. > It follows, that since hosts without DBC cannot listen to upstream requests, > the debug target-originated port reset requests (both hot and warm) will be ignored > by the debug host.
As above, a formal workaround is to issue Warm Reset periodically from debug host, but that could cause much complexity. My quirk is to issue port reset just *before* setting DCE bit. This quirk seems to work on several platforms. (My debug host doesn't have DBC.)
> > This is the essence of the "hung port state" that I was able to observe. > > Note, that this roadblock doesn't appear if you attach the cable /after/ enabling the DCE bit,
Yes.
> or, alternatively, if the host has DBC.
Really? I haven't tried it yet.
> > And indeed, your quirk will work in the latter case, since the debug host hub > will be able to see the upstream reset request.
This quirk works as well if debug host doesn't have DBC. I didn't try a DBC-capable debug host yet.
> > -- > with best regards, > Dmitry Malkin
Thank you. -Baolu
> -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
| |