On Wednesday 19 April 2006 12:01 pm, Carlos Aguiar wrote:
> Hi folks,
>
> I'm starting a project that the main idea is to try to add support for
> multiple gadgets. Ideally we would have Ethernet, serial and mass
> storage available at the same time.
Good, I'll be glad to see some progress on this. But please keep to
the current terminology: there will be exactly one "gadget", but it
will expose multiple "interfaces" or "functions".
> The platforms that I intend to use to develop the project is OMAP H2 and H3.
So it'll also go well with an OMAP OSK [1] or Nokia N770 ... ;)
I agree that the OMAP is a good platform to start this work on; it's got
plenty of endpoints, and I think omap_udc seems pretty solid. You should
however think about what it'd mean to do this with a dual speed peripheral
too; there are some differences that can crop up.
> I'm new in this list and I would like to ask you some orientations and
> to get any hints on where to get started.
As I recall, the model we came up with last time this was discussed included:
- Some core gadget driver into which interface/function/... drivers plug;
when given a single widget, the driver should act like todays drivers do.
- Those interface/function/u-name-it/... widgets would include:
* one or more usb_gadget_string tables for the strings
* descriptors for the interface(s), for building the config descriptor
* ... for dual-speed hardware, both high speed and full speed
desriptors...
* setup() callback for interface and class requests and SET_CONFIGURATION
* init() callback, used to set up interface and string identifers
So that core driver would be configured somehow, maybe with the desired device
descriptor and a table of those widgets to match each gadget configuration (or
maybe some other way). The gadget code would call the widget init() routines,
which would use some convention to allocate those numeric identifiers so they
don't collide.
At that point, that core driver would be able do respond to all setup() requests
from the USB host ... it would return device, string, and configuration
descriptors
on demand (matching the current peripheral speed), and pass SET_CONFIGURATION
and SET_INTERFACE requests up to the widgets. The widgets would initiate
endpoint
I/O as appropriate, etc.
Details are left as an exercise. :)
However you'll notice that all the gadget drivers you mentioned have already
been factored into tables of strings and descriptors, so that part has been
done already. You should be able to get quite far by changing only the gadget
driver initialization, and splitting out setup() code into a reausable core
plus widget-specific bits.
- Dave
[1] http://tree.celinuxforum.org/CelfPubWiki/OSK ... more generally available
than H2 or H3.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
