On Wed, 26 Oct 2011, Thomas Poussevin wrote:
> Le 26/10/2011 17:23, Alan Stern a �it :
> >> cat /dev/urandom | alsa_aplay -Dhw:2,0 -f S16_LE -c2&
> >> uframe 5 : usecs 164 unavailable (remains 9/0 on uframe 7)
> >> Note : On uframe 5 , the 164 usecs would be uframe 5 : 125, uframe 6 :
> >> 30, uframe 7 : 9,out of max
> >> uframe 4 : sheduled
> >>
> >>
> >> uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
> >> ----------------------------------------------------------------------
> >> max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
> >> ----------------------------------------------------------------------
> >> used usecs on a frame | 13 | 0 | 0 | 0 | 125 | 78 | 0 | 0 |
> >> ----------------------------------------------------------------------
> >
> > This is a very bad idea. ehci-hcd does not support isochronous-IN
> > CSPLIT transactions extending beyond a frame boundary. In practice
> > this means that no isochronous-IN transaction should ever be scheduled
> > in uframe 4 or later.
>
> I don't understant, this is the OUT transaction that has been scheduled
> at uframe 4 & 5.
> We did not change restriction for IN transactions, that now find a place
> in uframe 2 & 3 (that are free because OUT does not occupate uframe 1 &
> 2 anymore) :
Ah, okay. I didn't pay close attention to which transfer was IN and
which was OUT. This is still only a band-aid solution, but it looks
like it will help solve a common problem.
As for the patch itself, there is a small error. start, next, previous
are all unsigned values; so when you do
previous = start-1;
it won't work if start was 0. You should do something more like this:
next = start;
start += period;
while (start-- > next) {
...
In addition, add a short comment explaining why this loop searches
backwards. And remember to run your patch through checkpatch.pl.
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
