Hi, On Thu, Jun 09, 2011 at 04:28:45PM -0400, Alan Stern 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? I don't really remember that, so I might have missed. OTOH, composite.c is fairly simple and the only gadget driver not using it is file_storage.c, but having a f_msc.c wouldn't hurt. > > 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. then, when things need to change we have several places to do so. > > 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. keep reading. The idea is to move the otg notifier to be a UDC notifier. Most of the notifications are from the gadget anyway: Suspend, Resume, Enumerated with xxx mA configuration, etc. See that my end goal is to make USB Charging also a lot simpler. I can put more details if you want to read them, but since that won't happen easily without this initial re-factor, I wanted to defer discussing it a bit. > > 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. exactly... if removable == 1, it means we're a card-reader (or CDROM) so we can connect to host even without a backing file ;-) > > 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. well, I though you would have gotten the point. The thing is that there is a duplication there. All controllers have to "bypass" usb_ep_queue() and that's always a bit tricky to get right. So, if we know every controller will _have_ to start a ep0-out transfer to receive the first USB Setup Packet, then we can combine that on an upper layer and free all controllers from having to do that. > > 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. and I want to defer pullups until they are actually needed. Meaning that all function drivers are up and running. At that point usb_ep_queue() to ep0-out would start things. > > 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? yes, that's what I mean. But we need to make wrapper around it for ease of use, much like you did for the host side ;-) > > 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. Well, at least I've put 3 products on the market, all of them got USB certification. Does that count ;-) ? -- balbi
Attachment:
signature.asc
Description: Digital signature
