Hi, Alan, > > > I checked and found that in Xilinx's Host controller case, the time that > > the TT is enabled is because a FS device is directly connected. The TT > > therefore knows the HS control transfer, HUB_CLEAR_TT_BUFFER, must be > > for the TT itself. All traffic to downstream would be split transfers, > > since the host controller is directly connected to a FS device. So, the > > device address for the HS control transfer of HUB_CLEAR_TT_BUFFER is not > > critical for the control message to reach the TT. The port address is > > useful to find which port's TT. However, Xilinx's EHCI host controller > > only has one port. > > What about in the future when there are host controllers with more than > one port? What if one of the ports is connected to a high-speed hub > and the other port is connected directly to a full-speed device? Then > how will the TT know whether the Clear-TT-Buffer is meant for itself or > for the other hub? Then port address can differentiate different port. And, for the port that is connected to a HS hub, the TT for that port is not enabled. TT is only enabled if a directly connected device is FS. > > > I do think this is not a pretty solution. I think we will hold this and > > wait for a solution in Linux, and will adjust our hardware to that (we > > are taking the advantage of FPGA). > > Okay. You could do the same thing that Freescale did. Then the same > code in ehci-hcd would work for both types of controller. > How does Freescal do it? From the code, does not seem to have anything special for TT. Thanks, Julie. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- 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
