RE: [PATCH v9 5/7] usb: Add streams support to the gadget framework

["Tanya Brokhman" <tlinder@codeaurora.org>]

Hi Felipe

> > @@ -129,6 +132,22 @@ ep_matches (
> >  	}
> >
> >  	/*
> > +	 * Get the number of required streams from the EP companion
> > +	 * descriptor and see if the EP matches it
> > +	 */
> > +	if (usb_endpoint_xfer_bulk(desc)) {
> > +		if (ep_comp) {
> > +			num_req_streams = ep_comp->bmAttributes & 0x1f;
> > +			if (num_req_streams > ep->max_streams)
> > +				return 0;
> 
> We would like the gadget drivers to all with all controllers, this
> would
> likely be better to ask from controller driver for N streams but work
> if
> we get less ? Something like:
> 
> struct usb_gadget_ops {
> 	...
> 	request_stream(struct usb_gadget *g, int max_streams);
> };
> 
> if (usb_endpoint_xfer_bulk(desc)) {
> 	if (ep_comp) {
> 		num_req_streams = usb_gadget_request_streams(gadget,
> 			ep_comp->bmAttributes & 0x1f);
> 
> 		/* now patch ep_comp descriptor */
> 		ep_comp->bmAttributes = num_req_streams;
> 	}
> }
> 
> this way, different function drivers can request for a different number
> of streams and controller driver is required to keep track of total
> number of streams, and number of "busy" streams.
> 

I'm not sure I understand what you meant by the above..
When choosing this approach we thought of the following design:
Each controller knows how many streams it supports for each endpoint and
inits the ep->max_streams filed accordingly. Each gadget driver declares the
number of streams it wishes to operate with using the comp_desc and if the
endpoint can support the requested number of streams - it's allocated for
that gadget driver. If no matching endpoint is found - it's up to the gadget
driver to decide what to do next. One approach could be to try and configure
the endpoint with less streams. For example in UAS if configuring the
endpoint with streams>0 fails, we fall  back to HS mode where no streams are
required.

Does this address your concerns? Perhaps this is what you meant...

> Another approach would be to require function drivers to request the
> streams during bind by themselves and only give this layer correct
> descriptors, which allow you to make those arguments const.

Actually, during bind we still don't know the connection speed so the number
of streams can't be determined at that point. For example: when UAS gadget
driver operates in HS mode the number of streams is 0, when in SS > 0. I
think this is the right place for streams configuration.


Best regards,
Tanya Brokhman
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum