On Thu, 30 Aug 2012, Sebastian Andrzej Siewior wrote: > > You're missing the point. The test of the interrupt URB's interval > > should be done _before_ find_endpoint() is called. > > The endpoint has a last_io field which could be used for that (which > isn't used right now at all) so I though it would be handy to consider > that. However, for that we need the endpoint� Yeah; that's not the right approach. You have to think in terms of emulating a real host controller/device controller combination. The scheduling information is maintained by the host controller driver, whereas the endpoint array in dummy-hcd holds device-side information. > In that case I would have to extend urbp for by an last_io member. No, that's not good enough. The scheduling information has to survive beyond the lifetime of an individual URB. Real host controllers use various data structures to store this; it looks like dummy-hcd will have to add something equivalent to ehci-hcd's ehci_qh structure. Only a few fields will be needed, probably just period and start. And a pointer to the endpoint structure. In theory dummy-hcd should also do scheduling of periodic transfers. In practice I think we can ignore it; interrupt URBs are not likely to take up a very large fraction of the available bandwidth. > > That's how real host controllers work; they don't try to contact > > interrupt endpoints during frames that aren't in the endpoint's > > schedule. > > Yes but they know to which endpoint the particular URB belongs. dummy > just wakes up and says "I have no memory of you" and completes it. Like I said, dummy-hcd will need a new data structure. On the bright side, this will reduce the amount of work that find_endpoint() has to do, because the endpoint pointer can be stored in the new structure. 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
