Lines Matching refs:that

20 high speed "split transactions" that don't waste transfer bandwidth.
34 Note that USB 2.0 support involves more than just EHCI.  It requires
47 It's believed to do all the right PCI magic so that I/O works even on
57 at this writing no Linux drivers have been using that support.
60 is not yet available.  Note that split transaction support for ISO
67 Transfers of all types can be queued.  This means that control transfers
69 ones from another driver, and that interrupt transfers can use periods
74 drivers; a OHCI or UHCI driver that works already doesn't need to change
82 limits on the number of periodic transactions that can be scheduled,
99 remove its module and then the driver for that companion controller will
100 take over (at lower speed) all the devices that were previously handled
128 High speed devices can do things that full speed (or low speed) ones
149 good to keep in mind that bulk transfers are always in 512 byte packets,
168 that the controller hardware won't do concurrent USB and PCI access,
169 so that it's only trying six (or maybe seven) USB transactions each
171 for a product that beat all the others to market by over a year!)
173 It's expected that newer implementations will better this, throwing
174 more silicon real estate at the problem so that new motherboard chip
175 sets will get closer to that 60 MByte/sec target.  That includes an
181 default ehci-hcd driver uses the minimum latency, which means that if
182 you issue a control or bulk request you can often expect to learn that
190 When drivers don't do that, their performance results will show it.
195 than the I/O.  If that same loop used 16 KB chunks, it'd be better; a
214 through sysfs uframe_periodic_max parameter. Describe that.