On Tue, 24 Sep 2013, vichy wrote: > hi Alan: > > > 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? > > > > We do exactly that if URB_ISO_ASAP isn't set. But first the routine > > has to check and see if the schedule is already full, and it prints a > > debugging message if all the assigned microframes have already expired. > Does below source show us what you mean? > if (unlikely(start < period)) { > ehci_dbg(ehci, "iso sched full %p (%u-%u < %u mod %u)\n", > urb, stream->next_uframe, base, > period, mod); > status = -ENOSPC; > goto fail; > } That's the first part (checking if the schedule is already full). This is the second part (printing a debug message if all the assigned microframes have already expired): /* * Not ASAP: Use the next slot in the stream, * no matter what. */ else if (start + span - period < now2) { ehci_dbg(ehci, "iso underrun %p (%u+%u < %u)\n", urb, start + base, span - period, now2 + base); } > if so, I have one question, why we use ( (last scan frame and last > schedule frame) < end point interval) to determine schedule is full? If start < period, it means that the last packet on the schedule (which is assigned to uframe start - period) comes before base. The only way this can happen is if the packets occupy the entire schedule and wrap around. 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 500, and suppose the schedule really is full. Then there will be packets scheduled for uframes 507, 515, ..., 8187, 3, 11, ..., 491, 499 (note that 499 is slightly before 500), and stream->next_uframe will be 507. So start will be set to (507 - 500) & 8191 = 7. The fact that 7 < 8 indicates the schedule is full. 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 491, so stream->next_uframe is equal to 499. Then start will be set to (499 - 500) & 8191 = 8191. The fact that 8191 >= 8 indicates the schedule isn't full. 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 - 500) & 8191 = 15, and the fact that 15 >= 8 indicates the schedule isn't full. Does this help? > 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). Alan Stern -- 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