Re: some questions about ehci period scheduling

[vichy]

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):
Does this expired come from (controller frame pointer) 
(stream-next_uframe)?
Suppose controller frame pointer = 640 and stream-next_uframe = 600.
And that mean Controller have scan our last schedule uframe?


 /*
  * 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.
base in your example base should be 8's multiple, right?
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), 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.

(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 =
 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?


(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.

 Does this help?
Yes, it did help me a lot. :)


 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);

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

Re: some questions about ehci period scheduling

[Alan Stern]

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

Re: some questions about ehci period scheduling

[vichy]

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;
}

if so, I have one question, why we use ( (last scan frame and last
schedule frame)  end point interval) to determine schedule is full?

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?

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

Re: some questions about ehci period scheduling

[Alan Stern]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: some questions about ehci period scheduling

[vichy]

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
 0cfe 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

Re: some questions about ehci period scheduling

[Alan Stern]

On Sun, 8 Sep 2013, vichy wrote:

  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?

That's right.

 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.

 appreciate your kind help,

You're welcome.

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

some questions about ehci period scheduling

[vichy]

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.


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
0cfe 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?

appreciate your help in advance,
--
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