On Tue, 13 Mar 2018 06:11:06 +0000, Minas Harutyunyan <Minas.Harutyunyan@xxxxxxxxxxxx> wrote: > Hi Paul, > > On 3/13/2018 2:39 AM, Paul Zimmerman wrote: > > On Mon, 12 Mar 2018 12:06:55 +0000, Minas Harutyunyan <Minas.Harutyunyan@xxxxxxxxxxxx> wrote: > > > >> Hi Paul, > >> > >> Nice to hear you again! Hope you are doing well. > > > > Thanks, same to you. > > > >> On 3/8/2018 1:51 PM, Paul Zimmerman wrote: > >>> On 03/06/2018 09:09 AM, Minas Harutyunyan wrote: > >>>> Driver debug log not required. > >>>> Based on lsusb output: to dwc2 port connected "Standard Microsystems > >>>> Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp. > >>>> Ultra". Because of connected HUB, which have periodic endpoint > >>>> (Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask > >>>> SOF interrupts. > >>> > >>> Hmm. It seems to me that for hubs, where the interrupt EP is only used to > >>> poll for connection changes (so the accuracy of the polling interval is not > >>> important), an OS timer could be used instead of enabling SOF interrupts. > >>> > >>> I have a Raspberry Pi 3 around here somewhere, maybe I'll dig it out and > >>> try playing around with this idea. No promises though! > >>> > >> > >> As I correctly understand, you suggest to mask SOF's and schedule in > >> dwc2 timer with expiration time 125us*interval. Based on timer > >> expiration get first urb from periodic queue and start transfer on > >> Interrupt IN EPn. In this case interrupt count will be decreased by > >> 'interval' times. But how you going to recognized inside dwc2 that this > >> Interrupt IN EPn is HUB endpoint or not? > > > > Yes, you understand correctly. But on second thought, we would need to treat > > *all* interrupt EPs this way, since things like mice and keyboards also have > > interrupt EPs. But I'm not sure if any device really needs highly accurate > > polling intervals on their interrupt EPs, so my idea may still work. > > > > In any case, I have my RPI3 set up and I can build a working kernel for it > > (sort of, but that's another story), so I will start experimenting with this. > > > > Idea is really good, but I'm not sure it's will work or no. See, if > interrupt IN transfers target frame is N. Due to timer can't be very > accurate it can will expire in N-1 or N+1 uframe and if we will start > transfer in that uframes, then not clear how will behave device if IN > token will received in not exact expecting uframe. > BTW, your suggestion only for Interrupt IN or OUT also? The USB spec says the device "can depend only on the fact that the host will ensure that the time duration between two transaction attempts with the endpoint will be no longer than the desired period. Note that errors on the bus can prevent an interrupt transaction from being successfully delivered over the bus and consequently exceed the desired period. Also, the endpoint is only polled when the software client has an IRP for an interrupt transfer pending". So the device can't be that picky about the exact uframe the transfer is requested. I will do both Interrupt IN and OUT. And if an Interrupt EP with a very short interval is submitted, or an Isoch EP, then I will revert to unmasking the SOF interrupt and handling all periodic EPs the old way. Yeah, I'm not sure this will work either, but I'll give it a try. -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
