> 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. > The forwarding I was referring to was the uml-hcd which works roughly like this: on output: 1) creates a new urb on the host 2) looks up the mapping from the uml device tree into the host tree 3) copies the relevant parts of the uml urb into the host urb changing types and simulating hubs 4) submits urb to the host hcd 5) gets completion of host urb copies the urb's status back and remaps the status the host status to uml status 6) sends completion of uml urb to uml usb layer.
on input: 1) creates a new urb on the host 2) looks up the mapping from the uml device tree into the host tree 3) copies the relevant parts of the uml urb into the host urb changing types and simulating hubs status 4) submits urb to the host hcd 5) gets completion of host urb copies data back out of host urb into uml urb 6) sends completion of uml urb to uml usb layer. other things is should be doing 1) translate interrupt urbs into bulk urbs and resubmit them on schedule 2) poll the hubs for status change (much like uhci) this is where the races are known 3) isochronous does not work yet > 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) > this is what I was referring to as catching a urb in that the target will have a suddenly appearing message from the TCD I was assuming that a urb would be created by the TCD and sent to the somehow registered, target driver, much like the net layer allocs a skb and sends it to the net layer for processing > Phase 1: target controller delivers a "setup data available", > SUDAV, IRQ to the driver; the host's eight bytes are provided. > here is where I was thinking the "catch" urb would be send to the driver > 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. > This would be a regular urb submit in response to the "catch" urb > 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. > Why make it a blank buffer rather then the urb style? Or would it be something like a universal answer buffer? The TCD could do the urb alloc when the driver registered for a endpoint, and keep the endpoint table up to date. of course I was thinking of having separate handler for each end point and treating the incoming urbs (yes it is the wire protocol but I think of them as urbs) as routed packets and the configuration management like a routing table that appears on the wire. I was hoping the most of the control stuff could be handled by the generic layer > 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 > I was not thinking too much of building a uml as a master usb or slave usb device to the host I just was wanting to get the uml-hcd working so it could talk through the host to real devices directly. Though running a uml as a usb master with the host computer configured as a usb slave might be fun. So might vice versa :) but in either case having a usb HCD/TCD that copies data back and forth (twiddling as needed) would likely be useful. more complex testing such as error injection can wait till after something works the first time. I know that if I was doing it there would be plenty of errors, before injection was even attempted, at least on the first versions. ------------------------------------------------------- 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
