Skip to contentSkip to conversation

usb: dwc3: gadget: check if dep->frame_number is still valid

PATCH New Felipe Balbi 1 participant 1 message Aug 23, 2018 USB

lore
Share & tools
lore
#0 lore raw

PATCH 2/4 usb: dwc3: gadget: check if dep->frame_number is still valid

Hi,

Quoted 46 lines · Thinh Nguyen
Quoted 45 lines · Felipe Balbi

Gadget driver may take an unbounded amount of time to queue requests after XferNotReady. This is important for isochronous endpoints which need to be started for a specific (micro-)frame.

Before kicking the transfer, let's check if current frame number is still less than our aligned frame number that we got from the previous XferNotReady. If it isn't, then we'll increment dep->frame_number to make sure it's ahead of current frame number.

---
 drivers/usb/dwc3/core.h   |  2 ++
 drivers/usb/dwc3/gadget.c | 11 +++++++++++
 2 files changed, 13 insertions(+)
drivers/usb/dwc3/core.h +2 -0
index 285ce0ef3b91..3acf8788a680 100644
@@ -685,6 +685,8 @@ struct dwc3_ep {
 	u8			type;
 	u8			resource_index;
 	u32			frame_number;
+#define DWC3_EP_FRAME_NUMBER_MASK 0x3fff
+
 	u32			interval;
 
 	char			name[20];
drivers/usb/dwc3/gadget.c +3 -0
index f61a4250c883..0bac9b02f28b 100644
@@ -1257,6 +1257,9 @@ static int __dwc3_gadget_get_frame(struct dwc3 *dwc)
 
 static int __dwc3_gadget_start_isoc(struct dwc3_ep *dep)
 {
+	u16 current_frame_number;
+	u16 frame_number;
+
 	if (list_empty(&dep->pending_list)) {
 		dev_info(dep->dwc->dev, "%s: ran out of requests\n",
 				dep->name);
@@ -1265,6 +1268,14 @@ static int __dwc3_gadget_start_isoc(struct dwc3_ep *dep)
 	}
 
Quoted 10 lines

drivers/usb/dwc3/gadget.c static int __dwc3_gadget_start_isoc(struct dwc3_ep *dep) · line 1274

Quoted 5 lines
drivers/usb/dwc3/gadget.c +4 -0
 	dep->frame_number = DWC3_ALIGN_FRAME(dep);
+	current_frame_number = __dwc3_gadget_get_frame(dep->dwc);
+	frame_number = dep->frame_number & DWC3_EP_FRAME_NUMBER_MASK;
+
+	if (frame_number <= current_frame_number) {

This is not right. You're comparing (what should be a 16-bit but masked) frame_number to a 14-bit current_frame_number.
If the current frame number is 2+ seconds ahead of dep->frame_number, then this calculation is wrong.

According to docs, the numbers are the same and the top 2 bits are used internally by the IP. I.E. they're not part of the frame number. This is described in table 6-51 on databook 2.60a.

In any case, there's no other way to account for the overflow since the HW doesn't give me all the bits I need in DSTS. Any ideas?