On Mon, May 18, 2009 at 9:00 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > Dave: > > While working on this, I noticed there's still no code in ehci-q.c to > handle Clear-TT-Buffer for ARC/TDI embedded TTs. Looking through the > Freescale MCIMX31 and Intel IXP45X manuals explained why -- both of > them say (in the "Asynchronous Transaction Scheduling and Buffer > Management" section of the "EHCI Deviation" subchapter): > > Clear_TT_Buffer capability provided though the use of the > ___ register. > > It sure looks like something was meant to be filled in there but never > made it. Similarly, the "Operational Registers" section under "EHCI > Deviation" says: > > The following additions have been added to the operational > registers to support the embedded TT: > > A new register. > > Addition of two-bit Port Speed (PSPD) to the PORTSCx > register. > > Well, the PSPD bits are documented, but there don't seem to be any new > operational registers related to the embedded TT. > > So what's the story? Does anybody know how this is implemented, or > even if it is implemented at all? Is there somebody at Freescale or > Intel we can ask about it? > 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? I always thought that the uhci/ohci "companion" controller addition to ehci was an intel hardware hack because they ran out of time when releasing the earliest ehci hardware/documentation. Because of that hack, Intel did not address the FS/LS directly connected device issue. I really hope Sarah can push back on the Intel XHCI hardware guys and prevent a similar hack for superspeed and lower speed devices. Anyway, if you do have the doc, look at how the FS isoc schedule is done for directly connected FS devices. If it is handled the same as HS devices, there probably is no ARC/TD EHCI TT on the internal controller. 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
