On Mon, 27 Jul 2009, Julie Zhu wrote: > > 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. Ah, but that won't work. If the Clear-TT-Buffer command is meant for the external hub, then the port address in the command will refer to the port on the external hub, not the port on the root hub. For example, let's suppose the HS hub is connected to the root hub's port 1 and a FS device is connected to the root hub's port 2. Let's also suppose that another FS device is connected to port 2 on the external hub. Now the kernel wants to send a Clear-TT-Buffer command to the external hub. The port number will be 2. Won't the embedded TT get confused? It doesn't know whether that 2 refers to a port in the root hub or a port in the external hub. > > 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. There _is_ no code in ehci-hcd to handle it; that code still has to be written. The Freescale design includes an additional (not standard EHCI) memory-mapped register, called ASYNCTTSTS, located at offset 0x015c. The MPC8349EA has only one TT so only bits 0 and 1 in the register are used; the remaining bits are reserved. Presumably more bits would be used if there were more TTs. The low-order bit is called TTAS (for TT Async buffer Status) and the high-order bit is called TTAC (for TT Async buffer Clear). TTAS is read-only; its value is 0 if the TT's async buffers are all empty and 1 otherwise. TTAC is R/W; the driver writes a 1 to tell the embedded TT to clear its async buffer and the value changes back to 0 after the buffer has been cleared. This may take a while because the clear won't interfere with a transaction in progress -- I think that is a design mistake and the clear should occur immediately. This design is far from perfect. According to the USB 2.0 spec each TT must have at least two async buffers, and the kernel needs to be able to clear one of them without interfering with the other. But the Freescale design doesn't provide any way to do that. 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
