Hi,
On 10/25/2010 07:19 PM, Alan Stern wrote:
On Mon, 25 Oct 2010, Hans de Goede wrote:
Hi All,
The last 3 days I've been working on (*) getting a few usb-1.1
webcams to work when connected through a usb-2.0 hub.
*) And also doing a lot of reading of ehci-sched.c and the usb 2.0
standard.
This mail is an attempt to organize my thoughts, point out
what I believe are bugs in the current code and suggest some
enhancements.
Note the below discusses the CONFIG_USB_EHCI_TT_NEWSCHED code, some
may apply to the old code to, some may not.
...
It looks like all the issues you raise were discussed in those threads
I referred you to earlier.
Hi,
I've skimmed over the first thread and I've read your proposal from the 2nd
link you've send. Although I agree that a bigger overhaul of the code would
be good. I think we can get quite a long way with some tweaks. First of all
a bunch of small bugfixes as suggested in my mail, so basically stop
scheduling start splits in such a way that we are missing complete splits.
On top of that I would like to implement support for backpointers (sorry
about the confusion, see below). So that isoc packets can span the entire
frame.
Then add a small tweak to schedule isoc transfers < 950 bytes starting
in bus uframe1, leaving bus uframe 0 free for interrupt transfers.
A bit of reverse logic compared to normal, but implementing backpointers
seems easier then fstn to me.
So this brings
Once all of the above issues are fixed, things may all be to the spec, but
limiting all transfers to uframe0-3 is not good, so I plan to work on FSTN
support as time allows. Atleast for isoc transfers as doing FSTN support
for isoc transfers is something which I think can be implemented in a sane
manner (unlike interrupt transfer FSTN stuff).
What are you talking about? FSTN doesn't apply to isochronous
transfers, only to interrupt transfers. Conversely, isochronous-OUT
transfers require support for the BackPointer field in the siTD
structure, which we currently don't have.
Yes, sorry I had stopped reading the EHCI spec at the relevant part and
assumed spanning frame boundaries with isoc would use fstn too, my bad.
When we do this (add FSTN support for isoc but not for interrupt transfers)
it might be a good idea to reserver the 1st uframe for interrupt transfers
(except when a really large isoc request arrives).
The entire TT-scheduling code, old and new, needs to be rewritten. I
suggest that when this is done, we schedule each isochronous transfer
as early as possible within the frame and interrupt transfers towards
the end of the frame (depending on the period).
I agree that that would be ideal, but looking at how old this code is and
how little love it has seen. I'm serious thinking about investing some of
my time in getting the current code into a shape where although not perfect
it will be a lot better.
So this brings me to the question, are there any concrete plans to start
this rewrite soon? And if not would you be willing to take patches
fixing things in the current code like scheduling transfers in uframe 4 and
later, which we seem to agree up on is wrong to do with the current code ?
Thanks & Regards,
Hans
--
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
