Messages in this thread Patch in this message | | | Subject | Re: XHCI vs PCM2903B/PCM2904 part 2 | From | Rik van Riel <> | Date | Tue, 30 Jun 2020 14:52:01 -0400 |
| |
On Tue, 2020-06-30 at 17:27 +0300, Mathias Nyman wrote: > On 30.6.2020 16.08, Rik van Riel wrote: > > I misread the code, it's not a bitfield, so state 1 means an > > endpoint marked with running state. The next urb is never getting a > > response, though. > > > > However, the xhci spec says an endpoint is halted upon a babble > > error. > > I was looking at the same, so according to specs this state shouldn't > be possible.
The PCM2903B chip, and potentially the hub it is behind, are USB2 devices, though. Does USB2 know about halted endpoints?
> > The code right above the babble handling case adds halted into the > > endpoint state itself. Does the code handling the babble error need > > to do something similar to trigger cleanup elsewhere? > > It's a flag to prevent ringing the doorbell for a halted endpoint. > Anyway, reset endpoint is meant to recover an endpoint in a halted > state. > Resetting non-halted endpoints will just lead to a context state > error, and > besides, isoc endpoints shouldn't halt. > > Anyways, I haven't got any better idea at the moment. > You can try and see what a forced reset does with:
So close. Looks like something in the XHCI/USB stack isn't doing the reset because something is in an unexpected state?
[ 51.706798] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [ 51.706802] got overflow, ep->flags = 2 [ 51.932550] usb 3-9.7.5: reset high-speed USB device number 18 using xhci_hcd [ 68.830396] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [ 68.830409] got overflow, ep->flags = 2 [ 70.077981] rfkill: input handler disabled [ 157.992374] got overflow, ep->flags = 2 [ 157.992406] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci- > ring.c > index 2c255d0620b0..d79aca0df6d4 100644 > --- a/drivers/usb/host/xhci-ring.c > +++ b/drivers/usb/host/xhci-ring.c > @@ -1900,8 +1900,7 @@ static int > xhci_requires_manual_halt_cleanup(struct xhci_hcd *xhci, > * endpoint anyway. Check if a babble halted the > * endpoint. > */ > - if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_HALTED) > - return 1; > + return 1; > > return 0; > } > > Traces also showed thet endpoint doorbell was rang after th babble > error, so > we know that didn't help restarting the endpoint. > > -Mathias > -- All Rights Reversed. [unhandled content-type:application/pgp-signature] | |