On Mon, 18 May 2009, Steve Calfee wrote: > On Mon, May 18, 2009 at 2:27 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 18 May 2009, Steve Calfee wrote: > > > >> Hi Alan, > >> > >> It has been a really long time since I used the Arc core (around > >> 2003?), and I no longer have the ARC ehci document, which may have > >> been under NDA. > >> > >> However, It is my impression that the ARC/TD core was done the "right" > >> way, with respect to non-HS transfers. I think it just uses the ehci > >> dma transfer machine to send on FS/LS. So I think it is the case that > >> there is no transaction translator at all. All that split transfer > >> stuff was just to implement a new protocol between HS controllers and > >> HS hubs with FS/LS connections. Why would the ARC core do the TT hack > >> internally for known speed connections? > > > > Because if you don't buffer FS/LS transfers separately from HS > > transfers, you end up delaying the HS bus unnecessarily. Â Hence there > > has to be special buffering hardware for FS/LS transfers -- and once > > you've done that, you're 50% of the way toward implementing a TT. > > > > I was talking about a host port directly connected to a FS/LS device. So was I. > In that case the hardware DMAs into a fifo and the only Host > controller difference between HS/FS/LS is the clocking rate out of the > fifo. How do you know? It _could_ work that way, but reconciling that behavior with the documented way a controller iterates through the entries on the async list would be a little tricky (because there would have to be two or three different iterators: one for LS/FS -- or one for each -- and one for HS). > Maybe the ARC ehci does include a TT, but I could find no evidence > for it in the ARC spec. I don't know about the old ARC spec, but the more recent specs explicitly include phrases like "built-in TT" or "root-hub TT". > Including that you say isoc transfers > for FS is the same queuing as for HS. That isn't what I said. I said it is the same as queuing for regular EHCI -- i.e., the same as queuing a FS transfer through a high-speed hub's TT. > If they had a TT you wouldn't > you have to go through the same dance of fitting an xfer into multiple > HS frams as you do in a HS hub? Right. And indeed, you _do_ have to go through the same dance. > >> I really hope Sarah can push back on the Intel XHCI hardware guys and > >> prevent a similar hack for superspeed and lower speed devices. > > > > It may be too late for that; their hardware is already developed > > (though perhaps not finalized). Â However the overall design _is_ > > finalized. Â USB-3.0 actually contains two separate buses, one running > > at 1.5/12/480 Mbs and the other running at 4 Gbs. > > > > If they do a companion controller for xhci, there will be actually 3 > different controllers built in: uhci(or ohci), echi and xhci. All 3 > could use a single connector. I realize superspeed will have a few > extra wires, but for compatibility old style connectors will still be > there. AFAIK, Intel has not yet released the specs for their XHCI controller. When they do, we may find that it has only two built-in controllers: XHCI, and EHCI with a root-hub TT. :-) 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
