Hello, I work in a scientific organization (www.ihep.su, experiments in high energy physics). My colleagues developed a crate controller with buffer memory and a usb interface (read out module, rom) to read out crate electronics with cypress ez-usb sx2 (cy7c68001). I developed a (Linux) kernel driver to read buffer memory in rom synchronously and asynchronously. It works fine. There is a test which makes me think that URB is scheduled always by USB controller in the next microframe and never in the current one even if it is "idle". cy7c68001 is configured for one pipe bulk-in with 512 bytes per packet/ Driver FIFO contains 64 items. Data transfer is implemented in driver with one iterative URB submission-receiving with one item as URB buffer. A user process empties driver FIFO concurrently with URB handling. Each measurement is an average of 20 transfers by 32 MB each: columns: 1: size of FIFO item in bytes 2: measured value in MB/s 3: estimation in MB/s (= 8 kHz * size) results: 1*512 3.86 3.91 2*512 7.62 7.81 3*512 11.3 11.7 4*512 14.9 15.6 I see the same behaviour on different test systems with different USB controllers. That means USB controller developers and producers deceive users, because they don't permit to use full USB bandwidth for short transfers without serious reasons. Now we think about an external bus adapter with usb interface. Each cycle on extern bus should be handled properly to provide consistency of command execution. If a bus cycle is implemented with one URB transfer then its duration is limited by duration of one USB microframe (125 us). 125 us is very long for us. What we can do: * develop a macrocommand protocol, to run some bus cycles by one URB transfer with built-in macrocommand. That requires complex external bus controller logics and limits use cases by a macrocommand pattern. * get a USB controller that can schedule transfers in current microframe. In accordance with USB2.0 specification we could get cycle duration 1/(131 * 8 kHz) ~ 1us (table 5-10 permits 131 transfer for 2-byte payload). That is enough for us. What we can't: * submit some URBs concurrently * use some pipes concurrently because external bus cycles can depend on results of previous cycles. The questions are: * Is there a USB controller with scheduling in current microframe? * Is it possible to schedule transfer in current microframe from a Linux driver? * If not, is there a FPGA (open) IP core for USB controller to fix and make it to schedule URB transfers in current microframe? * if not, is there a way to make USB controller developers to implement scheduling in current microframe? * if not, is there another way to get 1 us bus cycle by a USB link? Thanks for answers in advance, Alexey. PS It seems USB3.0 has the same drawback -- 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
