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
