From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: John Youn <John.Youn@synopsys.com>
Cc: linux-usb@vger.kernel.org
Subject: [RFC] Sorting out dwc3 ISOC endpoints once and for all
Date: Fri, 07 Jun 2019 12:50:00 +0300 [thread overview]
Message-ID: <87a7etd8s7.fsf@linux.intel.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]
Hi John,
Now that we have dwc3_gadget_start_isoc_quirk() which figures out the
correct combination for the top-most 2 bits in the frame number, why
don't we just use that to start isochronous transfers and never, again,
have Bus Expiry problems?
I mean something along the lines of below diff (completely untested):
modified drivers/usb/dwc3/gadget.c
@@ -1369,9 +1369,8 @@ static int dwc3_gadget_start_isoc_quirk(struct dwc3_ep *dep)
else if (test0 && test1)
dep->combo_num = 0;
- dep->frame_number &= 0x3fff;
dep->frame_number |= dep->combo_num << 14;
- dep->frame_number += max_t(u32, 4, dep->interval);
+ dep->frame_number = DWC3_ALIGN_FRAME(dep, 1);
/* Reinitialize test variables */
dep->start_cmd_status = 0;
@@ -1383,33 +1382,16 @@ static int dwc3_gadget_start_isoc_quirk(struct dwc3_ep *dep)
static int __dwc3_gadget_start_isoc(struct dwc3_ep *dep)
{
struct dwc3 *dwc = dep->dwc;
- int ret;
- int i;
if (list_empty(&dep->pending_list)) {
dep->flags |= DWC3_EP_PENDING_REQUEST;
return -EAGAIN;
}
- if (!dwc->dis_start_transfer_quirk && dwc3_is_usb31(dwc) &&
- (dwc->revision <= DWC3_USB31_REVISION_160A ||
- (dwc->revision == DWC3_USB31_REVISION_170A &&
- dwc->version_type >= DWC31_VERSIONTYPE_EA01 &&
- dwc->version_type <= DWC31_VERSIONTYPE_EA06))) {
-
- if (dwc->gadget.speed <= USB_SPEED_HIGH && dep->direction)
- return dwc3_gadget_start_isoc_quirk(dep);
- }
-
- for (i = 0; i < DWC3_ISOC_MAX_RETRIES; i++) {
- dep->frame_number = DWC3_ALIGN_FRAME(dep, i + 1);
+ dep->frame_number = __dwc3_gadget_get_frame(dwc);
+ dep->frame_number = DWC3_ALIGN_FRAME(dep, 1);
- ret = __dwc3_gadget_kick_transfer(dep);
- if (ret != -EAGAIN)
- break;
- }
-
- return ret;
+ return dwc3_gadget_start_isoc_quirk(dep);
}
static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
Would there be any obvious draw-back to going down this route? The thing
is that, as it is, it seems like we will *always* have some corner case
where we can't guarantee that we can even start a transfer since there's
no upper-bound between XferNotReady and gadget driver finally queueing a
request. Also, I can't simply read DSTS for the frame number because of
top-most 2 bits.
best
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next reply other threads:[~2019-06-07 9:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-07 9:50 Felipe Balbi [this message]
2019-06-17 17:37 ` [RFC] Sorting out dwc3 ISOC endpoints once and for all John Youn
2019-06-17 19:08 ` Thinh Nguyen
2019-06-17 20:44 ` John Youn
2019-06-18 7:20 ` Felipe Balbi
2019-06-18 18:15 ` Thinh Nguyen
2019-06-18 19:58 ` Thinh Nguyen
2019-06-19 6:28 ` Felipe Balbi
2019-06-19 16:55 ` John Youn
2019-06-19 18:56 ` Thinh Nguyen
2019-06-20 17:58 ` Thinh Nguyen
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=87a7etd8s7.fsf@linux.intel.com \
--to=felipe.balbi@linux.intel.com \
--cc=John.Youn@synopsys.com \
--cc=linux-usb@vger.kernel.org \
/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).