On Mon, 30 Jul 2012, Alexey Filin wrote: > On Thu, Jul 26, 2012 at 7:47 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > You can do this only by hacking up a special driver of your own. > > Since transfer completions would not be reported by IRQs in time, you > > would have to poll for transfer completions at microsecond intervals. > > This would present a rather large overhead for the computer, but it > > might work. > > > > for example in such a way: > > there are 2 bulk endpoints in USB device, OUT and IN: > > OUT buffer format: | <ADDR> | <WRITE DATA> | <cycle type> | > IN buffer format: | <READ DATA> | <completion bit> | > > Read cycle (read data by ADDR): > > 1. USB host sets OUT buffer to: | <ADDR> | <ignored> | 0 | > 2. USB host clears <completion bit> in IN buffer: | <ignored> | 0 | > 3. USB host submits URBs for OUT and IN endpoints > 5. USB device gets <cycle type>, reads data by ADDR, puts data into IN > endpoint and sets <completion bit> > 6. while not <completion bit> set and not timeout triggered > USB host reads IN buffer > 7. USB host finishes cycle and returns data from IN buffer: | <READ DATA> | 1 | > > > Write cycle (write data by ADDR): > > 1. USB host sets OUT buffer to: | <ADDR> | <WRITE DATA> | 1 | > 2. USB host clears <completion bit> in IN buffer: | <ignored> | 0 | > 3. USB host submits URBs for OUT and IN endpoints > 5. USB device gets <cycle type>, gets data from OUT endpoint and sets > <completion bit> > 6. while not <completion bit> set and not timeout triggered > USB host reads IN buffer > 7. USB host finishes cycle, IN buffer: | <ignored> | 1 | > > URB completions are ignored, cycles are atomic (with a mutex), we get > latency ~1 us Your <completion bit> mutex isn't needed, because the USB host hardware provides one of its own. > can the same URB be submitted some times before completion? > if not, can different URBs be submitted with the same buffer before completion? > > should it work? Yes, something like it might work, I think. But you probably wouldn't want to use URBs for this; they have too much overhead. You'd need a more direct interface to the host controller driver. The EHCI spec doesn't put any strict time limit on how long the host controller can wait before writing back the completion information to a transfer descriptor. If the hardware waits more than 1 us, your scheme is doomed. 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
