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

[Felipe Balbi <felipe.balbi@linux.intel.com>]

Hi,

Thinh Nguyen <Thinh.Nguyen@synopsys.com> writes:
> On 8/20/2018 3:34 AM, Felipe Balbi wrote:
>> 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.
>>
>> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>> ---
>>  drivers/usb/dwc3/core.h   |  2 ++
>>  drivers/usb/dwc3/gadget.c | 11 +++++++++++
>>  2 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 285ce0ef3b91..3acf8788a680 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -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];
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index f61a4250c883..0bac9b02f28b 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -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)
>>  	}
>>  
>>  	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?