>>Also, I'd be happier if we had the device side ("gadget")
>>APIs further along. Both should be using the same URBs, the
>>same submit/unlink/complete model ... with the split pretty
>>much right there at "usb_bus". In one case the requests would
>>go to some HCD, that multiplexes devices, schedules periodic
>>traffic, and "knows" how to talk to the hub driver. In the
>>other, requests would go more directly to hardware, and rely
>>on the host to do everything except actually send/receive data.
>>(And "slave" drivers would look at control requests differently
>>too ... responding to requests, needing a two-phase API.)
>>
>
> About the gadget, looks like it could take advantage of a usb loopback
> interface-> that would take the urb and send it back to (I guess) a Target
> Controller Driver and the TCD would feed the incomming
> Control/Bulk/Interrupt/Isochronous up to the drivers with everything going
> in pretty much the other direction since the target side acts as a dumb
> slave to the host side, or so it appears.
Just a bit more complex than that ... It would be _nice_ to
have error simulation modes in there, to support more than one
device (ideally in separate UML virtual machines!), and add some
random delays for load simulation. But periodic transfers must
be initiated only at the correct intervals, so it'd need a bit
more intelligence than a loopback as soon as it got past the
basic control/bulk transfer support.
But yes, that's along the lines of what I was thinking. It'd
help move those device side APIs along. The device/slave side bus
controller emulation would only do anything when it get kicked
by the host side. Enumerating the simulated devices would need
a bit of extra attention; a first version might do it whenever a
device side driver registered itself, likely with some sort of
option for configuring low, full, or high speed modes.
> By the way submit/unlink/complete is HCD side I would expect a
> catch?/unlink/reply?/complete paradime on the TCD side.
> Was that what you ment by the two phase API?
The URB wouldn't get passed through, just data from the buffer(s).
I can't see any reason to change the model.
The "two phase" is only for control transfers. Here's a model
that will be familiar to anyone who's worked on the Cypress EZ-USB
microcontrollers; it can be elaborated, and all device controllers
use a corresponding model:
Phase 0: target driver sets up the control transfer mechanism
(maybe integrated with address assignment)
Phase 1: target controller delivers a "setup data available",
SUDAV, IRQ to the driver; the host's eight bytes are provided.
Phase 2: target driver responds to SUDAV by providing an URB
for the DATA phase of the request. For example, writing the
descriptors the host wants to read, or just acknowledging the
SETUP data with a zero byte write. Oh, and the driver would
perform the relevant request, too.
For bulk, interrupt, and iso transfers the driver would provide a
buffer -- most 32bit devices support mapped DMA, a few may require
bouncing data to endpoint-specific hardware buffers -- and issue
an URB that the target controller driver would process when the
host's corresponding request arrives.
There'd be no sense in a "catch" model since the device would be
NAKing transfers until the target/gadget side device driver made
a buffer available for the transfer, delivering data to the host
or receiving whatever it's ready to send.
Or to look at it differently, four different states need to be
supported for each endpoint, classic consumer/producer stuff:
either end (host/master, device/slave) can be ready to transfer
data, or not. Control is wierd because it's bidirectional with
built-in handshaking between the two CPUs, hence "two phase".
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
