RE: Question on clear_tt_buffer for not TDI but with built-in TT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 27 Jul 2009, Julie Zhu wrote:

> 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?

> 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.

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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux