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

Hi, Thinh Nguyen writes: >>> If it fails for over 5 times in a row, then we should probably wait for >>> the next XferNotReady to get the frame_number again. Also 5 is an >>> arbitrary number I came up without any testing, we can probably decide >>> on a better number. What do you think? >> I ha

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

On 11/14/2018 12:42 AM, Felipe Balbi wrote: > Hi, > > Thinh Nguyen writes: >>> Felipe Balbi writes: In the case of interval of 1ms, it will start on the next interval. > frame_number + max(4, interval) will start at least 4 uframes in the > future. > > In any case, what abou

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

Hi, Thinh Nguyen writes: >> Felipe Balbi writes: >>> In the case of interval of 1ms, it will start on the next interval. frame_number + max(4, interval) will start at least 4 uframes in the future. In any case, what about immediately retry the START_TRANSFER command wi

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

Hi Felipe, On 11/9/2018 3:04 AM, Felipe Balbi wrote: > Hi again, > > Felipe Balbi writes: >> In the case of interval of 1ms, it will start on the next interval. >>> frame_number + max(4, interval) will start at least 4 uframes in the future. >>> >>> In any case, what about immediately retry the S

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

Hi, Thinh Nguyen writes: diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d8c7ad0c22e8..00fe01a01977 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1268,12 +1268,22 @@ static int __dwc3_gadget_get_frame(struct dwc3 >>>

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

Hi again, Felipe Balbi writes: > In the case of interval of 1ms, it will start on the next interval. >> frame_number + max(4, interval) will start at least 4 uframes in the future. >> >> In any case, what about immediately retry the START_TRANSFER command >> with a new frame_number + (interval*r

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

Hi Felipe, On 11/8/2018 11:11 PM, Felipe Balbi wrote: > Hi, > > Thinh Nguyen writes: >> On 11/7/2018 10:58 PM, 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 star

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

Hi, Thinh Nguyen writes: > On 11/7/2018 10:58 PM, 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 tran

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

Hi Felipe, On 11/7/2018 10:58 PM, 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 how m

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

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 how much time has elapsed since dep->frame_number was updated and mak