On Mon, 25 Oct 2010, Hans de Goede wrote: > 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. I don't think that's a good idea. It will mean that the driver will no longer be able to handle situations that currently do work. > 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. Any transfer >= 580 bytes _must_ be scheduled first thing in bus uframe 0. See the Case 2b paragraph in section 4.12.3.1 of the EHCI spec. Furthermore, if an interrupt transfer is scheduled in uframe N then there must not be any isoc transfers scheduled in uframes N+1 through N+3. Thus reserving bus uframe 0 for interrupt transfers is _not_ a good idea. > A bit of reverse logic compared to normal, but implementing backpointers > seems easier then fstn to me. Maybe, maybe not. Neither is trivial. > 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. To be honest, I don't think that is possible. Or if possible, it is not worthwhile. > So this brings me to the question, are there any concrete plans to start > this rewrite soon? No concrete plans. On the other hand, I don't have very much other stuff pending... Perhaps I'll be ready to work on it starting in January... Hard to say. :-) > 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 ? It's wrong, but changing it will break things that currently work. So no, I won't accept such changes. 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
