On Tue, 15 Oct 2013, vichy wrote: > > This is the second part (printing a debug message if all the assigned > > microframes have already expired): > Does this "expired" come from (controller frame pointer) > > (stream->next_uframe)?
It comes from frame_pointer > next_uframe + period * (number_of_packets - 1). Note that period * (number_of_packets - 1) is the same as span - period. > Suppose controller frame pointer = 640 and stream->next_uframe = 600. > And that mean Controller have scan our last schedule uframe? If the period was 16 and the number of packets was 3, those packets would be scheduled for uframes 600, 616, and 632. Since all three values are < 640, they have already expired. However if there were 4 packets then they would be scheduled for uframes 600, 616, 632, and 648. Since 640 < 648, not all the assigned uframes would be expired. > if so, I try to rewrite your example. > (if anything wrong, please correct me) > > > (rewrite version) > If you think about a few examples, you'll understand. Suppose the > endpoint's interval is 8 uframes, starting from uframe 3. Suppose base > is 496, and suppose the schedule really is full. Then there will be > packets scheduled for uframes 507, 515, ..., 8187, 3, 11, ..., 491, 499 > (note that 491 is slightly before 496), That's not quite right. If base if 496 then the first scheduled packet will be for uframe 499 and the last will be for 491. Packets cannot be scheduled more than 8192 uframes in advance of base. > and stream->next_uframe will be > 499. So start will be set to (499 - 496) & 8191 = 3. The fact that 3 > < 8 indicates the schedule is full. Right. > (rewrite version) > Now suppose everything else is the same, but the schedule isn't > completely full. For this example, let's suppose the last scheduled > packet is in uframe 483, so stream->next_uframe is equal to 491. Then > start will be set to (491 - 496) & 8191 = 8196. The fact that 8196 >= (491 - 496) & 8191 = 8187, not 8196. > 8 indicates the schedule isn't full. > > In above case, driver should try to stop this urb if it try to > schedule more than 1 packet, right? Yes. > (rewrite version) > Consider one more example: Everything else is the same, but there's > only one packet in the schedule. It is assigned to uframe 507, and > stream->next_uframe is 515. Then start will be set to (515 - 496) & > 8191 = 19, and the fact that 19 >= 8 indicates the schedule isn't full. Right. > >> Below is where we handle URB_ISO_ASAP, > >> if (urb->transfer_flags & URB_ISO_ASAP) > >> start += (next - start + period - 1) & -period; > >> > >> Why don't we just use start as next? > > > > If start < next then we don't want to use it. Packets scheduled before > > next might not be seen by the hardware, because of the isochronous > > scheduling threshold (see section 4.7.2.1 in the EHCI spec). > when we calculate next, we have already put isochronous scheduling threshold. > if (ehci->i_thresh) > next = now + ehci->i_thresh; /* uframe cache */ > else > next = (now + 2 + 7) & ~0x07; /* full frame cache */ > > so when handling URB_ISO_ASAP, is it possible to change as below > if (urb->transfer_flags & URB_ISO_ASAP) > - start += (next - start + period - 1) & -period; > + start = (next + base); next + base might not be one of the uframes assigned to this endpoint. For example, suppose period is 8, base is 496, next_uframe is 491, and next is 501. Then we don't want start to be set to 501, because that's not one of the uframes in the endpoint's schedule. The endpoint is only allowed to use uframes 3, 11, ..., 491, 499, 507, ... We want start to be set to the first uframe available to the endpoint after 501, which is 507. Alan Stern -- 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
