As more folk start to use the gadget API, I've heard more suggestions about things that would help make the gadget drivers more flexible. Even some off-line brainstorming with folk (notably Alan Stern) about ideas.
So here are notes about some issues that were raised, and how I think the gadget framework might eventually address them.
Please discuss. And help implement ... :)
- Dave
ISSUE A: Autoconfigure Endpoints
Gadget drivers currently use compile-time binding to
particular controllers. This reflects the main usage
(dedicated hardware configurations), and is unavoidable
in some contexts, but it has some drawbacks: (a) Even the simple "bulk-only" endpoint configs
need gadget driver source updates to support new
controller drivers, mostly just telling which
endpoints to use. The current set of gadget
drivers uses just "bulk-only" configs. (b) Some less deeply-embedded distributions may need
to handle multiple hardware configurations. An
example would be a PXA based distro for HH.org,
using pxa2xx_udc most of the time ... except that
some Axim PDAs need mq11xx_udc instead.HOW TO SOLVE?
Oddly enough, "gadgetfs" has been leading the way here.
See http://www.linux-usb.org/gadget/usb.c and notice
the lack of compile-time binding! That's logically done
in two parts: - The gadget APIs have been modified over time to
expose information (like ep0 maxpacket size) that
was originally not available; so the amount of
code that's #ifdeffed per-controller shrank. - See the autoconfig() routine in that user mode
driver; it handles "bulk-only" configs just fine. So the basic idea would be to have a kernel mode
autoconfig() running from the gadget driver bind()
method. That should live in the init section, so
that costs are shifted only from compile-time to
load-time, not into run-time. CHALLENGE I: Come up with some autoconfig() that's
appropriate for today's "bulk-only" gadget drivers to
use, replacing the endpoint and speed logic currently
handled with #ifdef CONFIG_USB_GADGET_<hardware>. CHALLENGE II: There's other logic now wrapped in
such #ifdefs. Find some clean way to do that stuff
at runtime too ... perhaps like the "machine_is_axim()"
logic, though not ARM-specific.ISSUE B: Function drivers, more than Gadget Drivers
Although it's quite possible to develop gadget drivers
for multi-configuration devices (see gadget zero) or
with multiple interface descriptors (ethernet gadget),
it's not very easy to assemble devices that mix more
than one of the existing functions. Examples: * Both PXA/IXP and net2280 controllers can easily
support two different "bulk-only" functions in
a given configuration. (USB calls this kind of
configuration "composite": like audio + HID.) But it's not easy to combine the existing gadget
drivers into such a configuration. For example,
"ether" plus "file storage". And one person wanted to support two different
instances of a given function: HID keyboard,
and HID mouse. * Except for the superh UDC, all the controllers
now in use support devices that offer more than
one configuration. But it's not easy to combine the existing gadget
drivers by putting one in each configuration,
so a given device could act as a network, serial,
or disk link (as configured by the host). * Although every high speed driver is by definition
a kind of multi-configuration device (current
speed, and other-speed), the two configurations
are usually set up as almost identical. That's inappropriate for cases like high speed
video, where the full speed configuration can't
offer high bandwidth signals (8 MB/sec on up).HOW TO SOLVE?
First, recognize that this is partly because of how
gadget drivers are defined: one chunk of code that
manages the device. Such a chunk is needed, but it
doesn't need to be what most people write. So let's come up with a better name for the kind of
code that wraps up a given USB function, but which
could be combined into composite or multi-config
devices. I'll call these "function drivers".So we can now factor the problem into sub-parts:
- Defining an interface for function drivers. The
probing would autoconfigure endpoints, and IDs for
interfaces and strings. Several existing gadget
drivers would need to be converted to use this. - Provide a re-usable gadget driver ("main") into
which function drivers could be plugged, in various
combinations including: * single-function, just like today's drivers.
* composite, like "ether _and_ serial"
* multi-config, like "ether _or_ storage _or_ serial" That probably needs to be declarative, so it's
easy to say "use these product and vendor ids,
and list those N functions in this order". I've posted a patch that should help out here a bit,
by making it easier to build configuration descriptors
from lists of their components.
CHALLENGE III: Come up with a function driver API and a re-usable "gadget main" that works on modified "file_storage" and "serial" ... and lets the two of them be combined into a composite device.
CHALLENGE IV: The same, but implementing multi-config
devices for gadget zero (source/sink, or loopback)
and (soon) ethernet (RNDIS, or CDC/minimalist).CHALLENGE V: Solve III and IV with the same code!
CHALLENGE VI: Surely one of the function drivers
should be implemented in user-mode, from gadgetfs.
The multi-config case looks much simpler than the
composite device case.------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
