Re: [RFC] Sorting out dwc3 ISOC endpoints once and for all

Hi, Thinh Nguyen wrote: > Felipe Balbi wrote: >> Hi, >> >> Thinh Nguyen writes: >>> 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

Re: [RFC] Sorting out dwc3 ISOC endpoints once and for all

Felipe Balbi wrote: > Hi, > > Thinh Nguyen writes: >> 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 >> n

RE: [RFC] Sorting out dwc3 ISOC endpoints once and for all

> -Original Message- > From: linux-usb-ow...@vger.kernel.org On > Behalf Of Felipe Balbi > Sent: Tuesday, June 18, 2019 11:29 PM > To: Thinh Nguyen ; Thinh Nguyen > ; John Youn > Cc: linux-usb@vger.kernel.org > Subject: Re: [RFC] Sorting out dwc3 ISOC en

Re: [RFC] Sorting out dwc3 ISOC endpoints once and for all

Hi, Thinh Nguyen writes: > 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 XferNo

Re: [RFC] Sorting out dwc3 ISOC endpoints once and for all

Thinh Nguyen wrote: > Felipe Balbi wrote: >> Hi, >> >> Thinh Nguyen writes: > 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 lik

Re: [RFC] Sorting out dwc3 ISOC endpoints once and for all

Felipe Balbi wrote: > Hi, > > Thinh Nguyen writes: 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 co

Re: [RFC] Sorting out dwc3 ISOC endpoints once and for all

Hi, Thinh Nguyen writes: >>> >>> 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

RE: [RFC] Sorting out dwc3 ISOC endpoints once and for all

> -Original Message- > From: Thinh Nguyen > Sent: Monday, June 17, 2019 12:09 PM > To: John Youn ; Felipe Balbi > ; John Youn > Cc: linux-usb@vger.kernel.org > Subject: Re: [RFC] Sorting out dwc3 ISOC endpoints once and for all > > Hi, > > John Youn

Re: [RFC] Sorting out dwc3 ISOC endpoints once and for all

Hi, John Youn wrote: >> -Original Message- >> From: Felipe Balbi >> Sent: Friday, June 7, 2019 2:50 AM >> To: John Youn >> Cc: linux-usb@vger.kernel.org >> Subject: [RFC] Sorting out dwc3 ISOC endpoints once and for all >> > ++ Thinh

RE: [RFC] Sorting out dwc3 ISOC endpoints once and for all

> -Original Message- > From: Felipe Balbi > Sent: Friday, June 7, 2019 2:50 AM > To: John Youn > Cc: linux-usb@vger.kernel.org > Subject: [RFC] Sorting out dwc3 ISOC endpoints once and for all > ++ Thinh Hi Felipe, Sorry, missed this e-mail

[RFC] Sorting out dwc3 ISOC endpoints once and for all

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 (co