Hi Alan, Resend because Gmail was using HTML format before...Sorry! Seen through from several Freescale SOC document (for example,MPC8349EA,MPC5121E,MPC8313,etc), you will find out some of them have a register called ASYNCTTSTS (on MPC8349EA), which has a field (TTAC ) for Clear_TT_Buffer. This is not common to all FSL SOCs, so it is hard to implement a general code; Some SOC has the same register but has no TTAC field, and some of these SOCs do not even have ASYNCTTSTS register. [ 16.3.2.10 Transaction Translator Asynchronous Buffer Status (ASYNCTTSTS)— MPH-Only, Non-EHCI This register is not defined in the EHCI specification. This register is used to control the Asynchronous Buffer in the Embedded TT in the MPH module. Because the Unlink Periodic Buffer in the Embedded TT has automatic time-out and clear, the asynchronous buffer can become hung when the host controller driver does not let a complete-split run until completion. This register provides a function similar to that provided by the Clear_TT_Buffer and Get_TT_State. 1 TTAC Embedded TT async Buffers Clear. This field will clear all pending transactions in the embedded TT Async Buffer(s). The clear will take as much time as necessary to clear buffer without interfering with a transaction in progress. TTAC will return to zero after being set by software only after the actual clear occurs. 0 TTAS Embedded TT async Buffers Status. 1 One or more transactions are being held in the embedded TT Async Buffers. 0 All outstanding transactions in the embedded TT have been flushed. ] I had once a email session to one FSL silicon engineer,who said this: [ EmbeddedTT only implemented for MPH(multi port host), there no embeddedTT for SPH(single port host). For usb in mpc5121e was SPH, there should be no embeddedTT implemented. Both LS,FS,HS device can works well by directly connect to host. ] However, if you disable embeddedTT on that MPC5121E, you can not work with direct connected FS/LS. So the words from that engineer may not be TRUE. It is really hard for us to find out the full doc for these ARC/TDI EHCI variations. I had once tried to search if there is any patent that describes the story of the embeddedTT on http://www.patentstorm.us, but I couldn't find any info. I thought this embeedTT thing should have a patent to protect its property. Sign -:) Thanks, Cory 2009/5/19 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > 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 > -- 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
