Re: [RFC] [PATCH 0/5]: Composite Devices Support

On Friday 02 February 2007 7:44 am, Felipe Balbi wrote:
> The following patch series add support for Composite Devices following
> what was proposed David Brownell's patch.
> 
> Each patch modify one g_* module (ether, file_storage, serial) and
> another one sets up the base for such support.
> 
> We have some known issues but the code is working pretty fine with
> omap_h3 and omap_h2 development boards.

Don't forget to make it behave on those Nokia 880 boards too.  You
will need to make sure that the dual-speed code paths behave.  ;)


> We still have some work to do but this is our approach for USB Composite
> Gadgets support. If you could please comment the idea, we would be able
> to refine the code.
> 
> Listed below are the know issues:
> 
> 	- How to get which are the implemented bRequestTypes, as 
> 	  defined on linux as the USB_TYPE_ macros, from the gadget 
> 	  drivers?

The STANDARD ones should be handled mostly by the toplevel code
gluing the component functions into one device ... shared by all
composite devices.

Otherwise it's probably best to think about the USB_RECIP_* values
instead.  Whatever code assembles the composite gadget should be
able to provide a handler for anything unrecognized, or for the
"device" recipient (of e.g. a CLASS or VENDOR type request).

But in general, those requests are likely to be USB_RECIP_INTERFACE
and should get dispatched to the function implementing that interface.


> 	- Some of the direct attributions will be turned up into proper
> 	  functions.

Not clear to me what you mean by this; maybe "attributions" didn't
translate effectively from Portuguese...


> 	- One of the patches modify omap_udc.c to add 3 more endpoints
> 	  for us to be able to test composite framework running with 
> 	  all of the g_* gadget drivers.

Yeah, it's worth making sure that behaves.  In terms of full speed
platforms, I think the OMAP1 systems you're starting with are likely
the best choice in current Linux ... they have plenty of endpoints,
and by now both hardware and driver works well.


> 	- A composite Gadget with only one function, wouldn't it become
> 	  a simple gadget? If this is true, wouldn't be better to modify
> 	  USB Gadget Framework to become USB Gadget/Composite Framework
> 	  and get rid of those #if defined's?

Eventually, yes we want the #ifdefs gone.  Exactly how that will
work, I'm not entirely sure yet.

 
> 	- omap_udc.c defines some fifo_modes. The way it is implemented
> 	  composite framework would be limited to the fifo_modes
> 	  omap_udc.c implements, I mean that whenever I add a new
> 	  gadget driver, we would need to implement another fifo_mode
> 	  to handle the endpoints.

Not necessarily.  For example, your current stack would behave with
a set of bulk-only endpoints.

The complication comes when you want to configure isochronous endpoints,
which tend to require double buffering and so forth.

> 	  Wouldn't be nice to make the fifo_modes more dynamic ??

Some hardware -- like OMAP -- could easily support a dynamic init
model.  The way I see that working is at new callback from the
controller, used from the autoconfig code, which could do things
like allocating FIFOs to match the descriptors ... rather than
consulting a static table.

Example:  someone wants to turn their N800 into a bidirectional
webcam, with audio and video in both directions.  So the video
class function init code requests two 1KB ISO endpoints (IN, OUT)
which get double buffered and taken from the 16 KB buffer space
on that controller:  that's 4K allocated.  Then the audio class
function init code requests two much smaller ISO endpoints,
maybe just 128 bytes each.  Add a network link and a mass storage
interface, and there's still plenty of space left over ...

I'm sure an H2 or H3 could handle audio streaming just fine.  :)

Other hardware won't necessarily be as flexible.  It might run
out of buffer space, not be able to handle ISO, or might even
have fixed function endpoints that can't be configured.

- Dave



> 
> -- 
> Best Regards,
> 
> Felipe Balbi
> [email protected]
> 
> Nokia Institute of Technology - INdT
> Kernel Developers Team
> 
> +55 92 2126 1003
> 
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> [email protected]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel