Hi, Alan, > > > 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. > You are right. Our approach only works for single port. Well, at least you can use an external hub if you want multiple ports. > > > 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. > That sounds reasonable. If Linux is to support it that way, we will adjust our hardware to match that in the future. 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
