From: Mathias Nyman <mathias.nyman@linux.intel.com> To: Rik van Riel <riel@surriel.com>, Alan Stern <stern@rowland.harvard.edu> Cc: linux-usb <linux-usb@vger.kernel.org>, alsa-devel@alsa-project.org, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Mathias Nyman <mathias.nyman@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com> Subject: Re: XHCI vs PCM2903B/PCM2904 part 2 Date: Tue, 30 Jun 2020 17:27:10 +0300 [thread overview] Message-ID: <4a463fe0-f1af-a0f9-af2e-e36c060e8105@linux.intel.com> (raw) In-Reply-To: <90D456E4-328F-49F7-99C4-D729E38FA04E@surriel.com> 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 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: 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
WARNING: multiple messages have this Message-ID (diff)
From: Mathias Nyman <mathias.nyman@linux.intel.com> To: Rik van Riel <riel@surriel.com>, Alan Stern <stern@rowland.harvard.edu> Cc: alsa-devel@alsa-project.org, Mathias Nyman <mathias.nyman@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-usb <linux-usb@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Takashi Iwai <tiwai@suse.com> Subject: Re: XHCI vs PCM2903B/PCM2904 part 2 Date: Tue, 30 Jun 2020 17:27:10 +0300 [thread overview] Message-ID: <4a463fe0-f1af-a0f9-af2e-e36c060e8105@linux.intel.com> (raw) In-Reply-To: <90D456E4-328F-49F7-99C4-D729E38FA04E@surriel.com> 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 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: 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
next prev parent reply other threads:[~2020-06-30 14:24 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-20 11:26 XHCI vs PCM2903B/PCM2904 part 2 Rik van Riel 2020-05-20 11:26 ` Rik van Riel 2020-05-20 11:41 ` Takashi Iwai 2020-05-20 11:41 ` Takashi Iwai 2020-05-20 13:50 ` Mathias Nyman 2020-05-20 13:50 ` Mathias Nyman 2020-05-20 19:53 ` Rik van Riel 2020-05-20 19:53 ` Rik van Riel 2020-05-20 16:38 ` Alan Stern 2020-05-20 16:38 ` Alan Stern 2020-05-20 19:21 ` Rik van Riel 2020-05-20 19:21 ` Rik van Riel 2020-05-20 20:34 ` Alan Stern 2020-05-20 20:34 ` Alan Stern 2020-05-21 3:45 ` Rik van Riel 2020-05-21 3:45 ` Rik van Riel 2020-05-25 9:37 ` Mathias Nyman 2020-05-25 9:37 ` Mathias Nyman 2020-06-30 3:21 ` Rik van Riel 2020-06-30 3:55 ` Rik van Riel [not found] ` <90D456E4-328F-49F7-99C4-D729E38FA04E@surriel.com> 2020-06-30 14:27 ` Mathias Nyman [this message] 2020-06-30 14:27 ` Mathias Nyman 2020-06-30 18:52 ` Rik van Riel
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=4a463fe0-f1af-a0f9-af2e-e36c060e8105@linux.intel.com \ --to=mathias.nyman@linux.intel.com \ --cc=alsa-devel@alsa-project.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=mathias.nyman@intel.com \ --cc=perex@perex.cz \ --cc=riel@surriel.com \ --cc=stern@rowland.harvard.edu \ --cc=tiwai@suse.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.