[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #2 from Chris Holgate <chris@zynaptic.com> 2010-08-26 12:00:12 BST ---
(In reply to comment #1)

> At present, the Rx and Tx endpoint structures to be used by a function device
> package are specified using CDL options in the function device package (eg
> CYGDAT_IO_USB_SLAVE_SERIAL_EP0). The relationship between endpoints and
> function devices is fixed at build time.

This is fine for the older hardware which has limited configurability, but
doesn't scale well for newer, more flexible hardware (see below).

> Is specifying the endpoint structures at build time simply not possible? Or are
> you proposing the new scheme to allow greater flexibility with more modern
> hardware? What additional flexibility is achieved?

Consider that the STM32 has 7 fully configurable data endpoints - each of which
may be configured as an input or an output, each of which may be bulk,
interrupt or isochronous, each of which may be configured with arbitrary packet
sizes and each of which may be assigned an arbitrary logical endpoint number. 
Configuring that in the same way as existing drivers would be a CDL and #ifdef
nightmare.  

Fortunately, for any given class driver the definitive settings for all these
configuration options is present in the form of the class driver descriptors. 
By parsing the class driver descriptors for this information, the STM32 driver
avoids the user having to duplicate all the class driver descriptor settings as
CDL options.

> > This approach allows the STM32 USB driver to support multiple USB
> > configurations if required.
> 
> Can you explain what you mean by "multiple configurations" here?

USB device configurations are part of the USB spec that allows the host to set
up a device to behave as a specific class.  An example would be a camera which
supports a standard mass storage configuration as well as a PTP configuration. 
Each configuration will correspond to a different interface and endpoint setup
on the USB device.  The host notifies the device of the configuration it wants
to use during device bringup and the device must reconfigure its endpoint
settings as required by the selected configuration.

> If we provide the following functions in the generic USB slave API:
> 
>   usbs_rx_endpoint* cyg_usbs_rx_endpoint (cyg_uint32 ep_id);
>   usbs_rx_endpoint* cyg_usbs_tx_endpoint (cyg_uint32 ep_id);
> 
> how do you propose that the implementation of these functions looks up the
> endpoint structure? Another parameter to specify the hardware device driver
> lookup function?

The functions would need to be indirected through the control endpoint data
structure as per the existing USB API functions.

> How would the user of the USB function driver continue to specify the endpoints
> using CDL options?

Existing USB slave drivers can still export their static endpoint data
structures as before.  Existing class drivers which rely on this configuration
approach will continue to work with the existing USB slave drivers, but will
need to be reworked if they are to be used with the new API functions.

To work with the new API, existing USB slave drivers will need to add the
endpoint 'getter' functions and extra CDL configuration options which allow the
logical endpoint IDs requested via these functions to be mapped to the
appropriate physical endpoint data structures.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.