hi Alan: 2013/9/7 Alan Stern <st...@rowland.harvard.edu>: > On Sat, 7 Sep 2013, vichy wrote: > >> hi all: >> when I trace linux ehci driver source code. >> I have some questions >> 1. in itd_slot_ok, why we have to >> uframe %= period; >> and use this uframe to calculate the bandwidth? >> >> suppose start passed to itd_slot_ok is 537, period, usb->interval, is 8. >> that mean we want to know whether bandwidth of microframe 537 is enough. >> Not want to know whether 537%8 =1 >> the bandwidth of microframe 1 is enough. > > In fact you need to know both. If an isochronous endpoint has interval > 8 and it uses microframe 537, then it's also going to use microframes > 545, 553, 561, ..., 8177, 8185, 1, 9, ..., 529. So at first time stream is scheduled, we have to make sure all possible microframe bandwidth is enough, right?
> >> 2. Below is part of message excerpted from usb mon log: >> db1e2000 81051026 S Zi:1:002:6 -115:8:5327 1 -18:0:132 132 < >> db1e2000 81058043 C Zi:1:002:6 0:8:5391:0 1 0:0:4 132 = 2efd82fd >> 0cfeffff 84feb3ff 98fec4fb 08ffdaf8 060059fb 8b01d2ff db02de01 >> >> why these 2 ep->start_frame are different, 5327 in "-115:8:5327" and >> 5391 in "0:8:5391:0"? >> >> The log is captured with the same urb, for submitting and completing. >> That mean ep->start_frame=urb->start_frame in submit and complete >> should be the same, right? > > No. The value in urb->start_frame during submission is meaningless. > Usually it is left over from the last time urb was used. After the URB > is submitted, the host controller driver stores the correct value in > urb->start_frame, and usbmon shows the correct value during completion. I got it. BTW, I have another question about iso_stream_schedule. When if (likely (!list_empty (&stream->td_list))) happen, why don't we just take last scheduled microframe, stream->next_uframe as start point directly? appreciate your kind help, -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
