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

On Mon, 2007-02-19 at 15:19 -0800, ext David Brownell wrote:
> 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.  ;)
Ok... once I have a more stable code... I'll check it.. ;-)


> > 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).
Really good, thanks Dave.


> 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...
When I wrote "attributions" I meant:
struct usb_gadget *gadget = cdev->current_func->gadget;

This I already turned up into:
struct usb_gadget *gadget = get_composite_gadget(cdev);

And other instructions like this one...

sorry the bad english :-p


> > 	- 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.
The way we've implemented, once you modprobe g_*, the struct
usb_function would be added to struct usb_composite_dev's list_head, the
descriptors would be parsed from the structures added in the list, and
the correct pointers for that callback functions would be created...

This is already working fine in a generic way... if we add only one g_
module it's behaving as a simple gadget... if we add more than one, it
behaves as a composite gadget...

This is actually transparent to the controller driver... and to the g_
modules...

This is why we've coded it in a generic way... what would be nice to do
is test the composite gadgets with other usb controllers... but those I
don't have access to them.

BTW, I can't see the issue about using a generice composite framework
and just modprobe the usb_functions we want before plugging the cable...
please David.. could you explain it better??

> 
>  
> > 	- 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.

I'm, actually, thinking about these isochronous endpoints... we would
like to code the g_cam module... I actually saw that there's already an
effort on that... I contacted the developer asking if he would release
the code under GPL and he told me he didn't know yet...

But, this is not the subject... So... if we could make the endpoints
allocation more dynamic... it would be really great for the
usb_functions developers... I try to play around with this...


Just another comments:

I tested the composite framework with a Windows box... Window recognizes
it as a USB Composite driver and installs the USB Composite Controller
as you can see in [1].

I thought, then, composite gadget was mis-behaving... so I tried to
compile again the USb Gadget "only" Framework you wrote to see its
behavior and it behaved the same way as the Composite... Windows Machine
recognized it as a Serial, Ether, Storage Gadget but didn't had drivers
for them as you can see in [2].

I'm attaching only set of screenshots but I've run other tests too.


[1] Screenshot-VNC_Windows_EtherSerial_Composite.png
[2] Screenshot-VNC_Windows_Ether_Gadget.png

-- 
Best Regards,

Felipe Balbi
[email protected]

Nokia Institute of Technology - INdT
Kernel Developers Team

+55 92 2126 1003

-------------------------------------------------------------------------
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