On Thu, 9 Jun 2011, Felipe Balbi wrote: > Now going forward we need to figure out how to be sure that users can > tie a particular gadget driver to a particular UDC, so we might need the > idea of "gadget ports" to be implemented on the udc class. We also need > to get rid of any gadget driver that's not using the composite.c > framework, so that we have one location to focus for all gadget driver > changes. Wait a minute. There are some venerable standalone gadget drivers, and I don't see any good reason for forcing them to use the composite framework. In fact, didn't David specifically avoid doing that, in order to save the unnecessary overhead? > By doing that we can e.g. add a module parameter to composite.c > which will tell udc class which class to load the gadget driver to. A similar module parameter could be added to the standalone drivers. > We also need to cleanup all the ->start()/->stop() calls from all udc > controllers, then we need to uninline all the operations we have on > gadget.h, Why? What's wrong with leaving the operations inline? Most of them are function calls anyway. > later we move the otg notifier to the udc class and notify on > every call to those functions. Later we make udc class handle the > ->pullup() method correctly, so that all gadget drivers will always > start with pullups disconnected and for each function driver bound to > the gadget driver we increment the deactivations counter and every > function driver is required to activate when its ready to work, that > will be a different situation for every gadget driver, in case of f_obex > it needs an obex server on userland, in case of mass storage, if > removable == 1, it can activate on bind() time, else it needs to wait > until a file is echoed to "file" sysfs attribute and so on. That's not how the mass storage drivers work. If the "removable" flag isn't set, they _require_ a backing file to be specified at load time and the "file" attribute is read-only. > After all this is done, we need to make gadget framework handle the > start of the enumeration too. Today every gadget driver starts a > transfer on probe() time to wait for the SetAddress command so ep0 > handling is always "special" and separate from all other endpoints, I But ep0 _is_ special, for several reasons. Furthermore, the initial transfer doesn't wait for the Set-Address request; it handles any control request. For example, the first request sent by a Linux host to a new device is Get-Device-Descriptor, not Set-Address. > wanted to tie that to usb_ep_queue() on, maybe, composite.c so that we > don't need to start the underlying HW until we know all gadget drivers > are ready to respond. This might save a few micro-amps in runtime power > consumption too :-p ep0 has to be started as soon as the pullups are enabled. There's no choice about that. You could start it sooner if you wanted, but obviously that would be pointless. > Last, but not least, we can think of a power management framework for > USB3 gadget drivers. USB3 peripherals can start lower bus states, so we > can have an API similar to what we have on USB Host side. Gadget drivers > would be required to tell udc class when they are idle, if the pm timer > expires, we request lower bus states ;-) Why not use the existing runtime PM framework? Or is that what you meant? > So this is my idea to the gadget framework for the next couple of years > at least :-p Comments are welcome and I hope everybody can help too ;-) Does anybody have any experience with how the Linux gadgets are being used in commercial devices? It might be good to get some feedback from the people who actually need to make this stuff work in real life. 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
