ext David Brownell wrote: >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. > > > Hi Dave,
First of all, thanks for this explanation that was very helpful. But now, we have to write an action plan. We would like to know which tasks could be done for us. Could you help us to define these tasks? Thanks in advance. Carlos and David. -- Carlos Eduardo Software Engineer Nokia Institute of Technology - INdT Embedded Linux Laboratory - 10LE Phone: +55 92 2126-1079 Mobile: +55 92 8127-1797 E-mail: [EMAIL PROTECTED] ------------------------------------------------------- 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
