Re: Clear-TT-Buffer etc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
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. Maybe the ARC ehci does include a TT, but I could find no
evidence for it in the ARC spec. Including that you say isoc transfers
for FS is the same queuing as for HS. 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?

<snip>

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

Regards, Steve
--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux