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

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

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ecos-patches@ecos.sourcewar
                   |                            |e.org, john@dallaway.org.uk
          Component|USB driver                  |Patches and contributions

--- Comment #1 from John Dallaway <john@dallaway.org.uk> 2010-08-26 10:13:50 BST ---
(In reply to comment #0)

Chris, thank you for the contribution. In the absence of a complete
implementation, can you clarify how you envisage the new endpoint retrieval
scheme to work please?

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.

> Instead of using static endpoint references as per existing USB slave drivers,
> STM32 USB endpoints may only be accessed after USB device configuration via
> the two following 'getter' functions:

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?

> // Get a handle on the specified transmit (in) endpoint.  Calling this
> // function with a given logical endpoint ID will return the transmit
> // endpoint data structure associated with that endpoint ID.
> extern usbs_tx_endpoint* cyg_usbs_cortexm_stm32_tx_endpoint
     (cyg_uint32 ep_id);
> 
> // Get a handle on the specified receive (out) endpoint.  Calling this
> // function with a given logical endpoint ID will return the receive
> // endpoint data structure associated with that endpoint ID.
> extern usbs_rx_endpoint* cyg_usbs_cortexm_stm32_rx_endpoint
     (cyg_uint32 ep_id);
> 
> This approach allows the STM32 USB driver to support multiple USB
> configurations if required.

Can you explain what you mean by "multiple configurations" here?

> However, the existing standard eCos class drivers assume the use of static
> endpoint definitions which will require changes to work against this driver.
> 
> IMHO, the best way to resolve this would be to introduce a new pair of
> functions to the standard USB slave API, which are generic variants of the
> ones given above for the STM32.  This would be easy to add to existing
> drivers and would provide a consistent way of accessing old-style fixed
> endpoint USB hardware and more modern configurable USB hardware.  In addition
> they will hide the native types of the endpoint data structures which
> currently 'leak' from hardware specific slave drivers into class driver
> implementations.

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?

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

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

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

[bugzilla-daemon]

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 on the CC list for the bug.

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

[bugzilla-daemon]

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

--- Comment #3 from John Dallaway <john@dallaway.org.uk> 2010-09-03 15:00:08 BST ---
(In reply to comment #2)

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

Chris, can you provide an example implementation of this in the form of a patch
for the USB slave I/O layer and the USB serial function device? With a complete
implementation in place, it should be clear to everyone how to roll out the
improved API to other drivers over time.

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

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

[bugzilla-daemon]

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

--- Comment #4 from Chris Holgate <chris@zynaptic.com> 2010-09-13 20:30:48 BST ---
Created an attachment (id=975)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=975)
Modified USB slave API - for comment only.

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

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

[bugzilla-daemon]

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

Chris Holgate <chris@zynaptic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #963 is|0                           |1
           obsolete|                            |

--- Comment #5 from Chris Holgate <chris@zynaptic.com> 2010-09-13 20:31:58 BST ---
Created an attachment (id=976)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=976)
STM32 USB driver package using proposed API changes - for comment only.

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

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

[bugzilla-daemon]

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

--- Comment #6 from Chris Holgate <chris@zynaptic.com> 2010-09-13 20:50:53 BST ---
Hi John,

(In reply to comment #3)
> Chris, can you provide an example implementation of this in the form of a patch
> for the USB slave I/O layer and the USB serial function device? With a complete
> implementation in place, it should be clear to everyone how to roll out the
> improved API to other drivers over time.

I've included a proposed patch which adds the extra functionality to the USB
slave API, together with a modified version of the STM32 driver which makes use
of the additional API functionality.  These are for comment only, as they seem
to be OK but have not yet had a proper workout.

I've got a pretty demanding contract on at the moment, but I'll try and get
some proper testing in when I have the time and will report back when I'm happy
with the changes.  However, this will probably be with my proprietary class
driver rather than one of the standard eCos ones.  A patch against the standard
eCos serial driver will take a little longer.

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

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

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fpagliughi@mindspring.com

--- Comment #7 from John Dallaway <john@dallaway.org.uk> 2010-09-17 14:11:01 BST ---
Chris, thank you for the attachments. I've been experimenting with them and
have reached the point where my linux box is recognising the connection of a
serial device:

Sep 17 13:38:35 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 20
Sep 17 13:38:35 cog kernel: usb 4-1: device descriptor read/all, error -71
Sep 17 13:38:35 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 21
Sep 17 13:38:35 cog kernel: usb 4-1: device descriptor read/all, error -71
Sep 17 13:38:35 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 22
Sep 17 13:38:35 cog kernel: usb 4-1: device descriptor read/8, error -71
Sep 17 13:38:35 cog kernel: usb 4-1: configuration #1 chosen from 1 choice

Meanwhile, the STM32 USB driver reports:

### 3:Powered ###
### 4:Reset ###
### 4:Reset ###
### 4:Reset ###
### 4:Reset ###
STM32 USB : Setting USB device address = 20
### 5:Addressed ###
### 4:Reset ###
### 4:Reset ###
STM32 USB : Setting USB device address = 21
### 5:Addressed ###
### 4:Reset ###
STM32 USB : Setting USB device address = 22
### 5:Addressed ###
STM32 USB : Setting USB configuration = 1
### 6:Configured ###

To get this far, I have:

a) set CYGDAT_IO_USB_SLAVE_SERIAL_EP0 == "cyg_usbs_cortexm_stm32_ep0c"
b) commented out references to the static rx/tx/intr endpoint structs in
   usbs_serial.c, and
c) modified the parameters passed into usbs_serial_init():

  void
  usbs_serial_start(void)
  {
    usbs_serial_init(&usbs_ser0,
      usbs_get_tx_endpoint(usbs_serial_ep0, TX_EP_NUM),
      usbs_get_rx_endpoint(usbs_serial_ep0, RX_EP_NUM));
        ......

lsusb reports:

Bus 004 Device 022: ID ffff:0001  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0xffff 
  idProduct          0x0001 
  bcdDevice            0.00
  iManufacturer           1 eCos
  iProduct                2 eCos USB Serial Device
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

"Vendor Specific Class" doesn't look good. Are there any clues here as to the
problem? I am adding Frank Pagliughi (eCos USB slave serial author) to the CC
list in case he has some insights on how to debug this.

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

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

[bugzilla-daemon]

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

--- Comment #8 from Chris Holgate <chris@zynaptic.com> 2010-09-17 19:02:53 BST ---
Hi John,

(In reply to comment #7)
> Chris, thank you for the attachments. I've been experimenting with them and
> have reached the point where my linux box is recognising the connection of a
> serial device:
> 
> "Vendor Specific Class" doesn't look good. Are there any clues here as to the
> problem? I am adding Frank Pagliughi (eCos USB slave serial author) to the CC
> list in case he has some insights on how to debug this.

Looking at the reported endpoints, I'm guessing that you need to set
CYGDAT_IO_USB_SLAVE_CLASS_TYPE to ACM to get the standard serial class driver
setup.  The generic option appears to set the class field to 'vendor specific'
- presumably because omitting the interrupt endpoint renders it non-compliant
with the spec.

I suspect that there are plenty of 'vendor specific' USB products out there
which are really just serial ports under the hood, and where the vendor drivers
are only there to map them to a generic COM/TTY port.

Chris.

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

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

[bugzilla-daemon]

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

--- Comment #9 from John Dallaway <john@dallaway.org.uk> 2010-10-07 11:12:59 BST ---
Chris, with CYGDAT_IO_USB_SLAVE_CLASS_TYPE == "ACM", lsusb looks better (but
scroll down for the problem):

Bus 004 Device 008: ID ffff:0001  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0xffff 
  idProduct          0x0001 
  bcdDevice            0.00
  iManufacturer           1 eCos
  iProduct                2 eCos USB Serial Device
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           48
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

usb_start() and usbs_serial_wait_until_configured() are required before calling
usbs_get_[rt]x_endpoint() so the sequence of calls in usbs_serial_start()
needed re-ordering. I'm now getting an assertion failure due to invalid
endpoint in stm32_usb_get_txep() and it looks like the TX endpoint map is not
correct:

(gdb) print txep_map
$8 = {0x0, 0x0, 0x68024ae0, 0x0 <repeats 12 times>}

stm32_usb_get_txep() is looking up logical endpoint 1 (TX) and therefore
retrieving element 0 which is 0x0. Any ideas?

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

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

[bugzilla-daemon]

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

--- Comment #10 from Chris Holgate <chris@zynaptic.com> 2010-10-07 20:23:13 BST ---
Hi John,

(In reply to comment #9)
> Chris, with CYGDAT_IO_USB_SLAVE_CLASS_TYPE == "ACM", lsusb looks better (but
> scroll down for the problem):
> 
> Bus 004 Device 008: ID ffff:0001  
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass            2 Communications
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0         8
>   idVendor           0xffff 
>   idProduct          0x0001 
>   bcdDevice            0.00
>   iManufacturer           1 eCos
>   iProduct                2 eCos USB Serial Device
>   iSerial                 0 
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           48
>     bNumInterfaces          2
      ^^^^^^^^^^^^^^^^^^^^^^^^^

I think this is the problem, since the driver has not previously been tested
with multiple interface declarations.  Looks like there is a possible bug in
the driver which doesn't deal properly with this situation when setting up the
endpoints.  I should have some time this weekend to sort out a fix.

Chris.

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

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

[bugzilla-daemon]

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

Chris Holgate <chris@zynaptic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #976 is|0                           |1
           obsolete|                            |

--- Comment #11 from Chris Holgate <chris@zynaptic.com> 2010-10-09 15:38:07 BST ---
Created an attachment (id=994)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=994)
STM32 USB driver package fixing multiple interface bug - to be tested.

This updated version of the STM32 USB driver package should fix the bug which
John encountered with the multiple interface configuration used by the serial
driver.  There are no regressions against the single interface setup that I am
using, but I have not had chance to test it against the serial driver package
yet.  Debug tracing is now selectable via a CDL option and will now report the
endpoints in use as they are set up.

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

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

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned@bugs.ecos.source |john@dallaway.org.uk
                   |ware.org                    |

--- Comment #12 from John Dallaway <john@dallaway.org.uk> 2010-10-15 14:51:27 BST ---
Chris, thank you for the updated driver. The cdc-acm driver on my Linux box is
now reporting "Zero length descriptor references":

Oct 15 13:11:27 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 28
Oct 15 13:11:37 cog kernel: usb 4-1: configuration #1 chosen from 1 choice
Oct 15 13:11:37 cog kernel: drivers/usb/class/cdc-acm.c: Zero length descriptor
references
Oct 15 13:11:37 cog kernel: 
Oct 15 13:11:37 cog kernel: cdc_acm: probe of 4-1:1.0 failed with error -22

This seems to be widely reported on the net with random ACM hardware so I have
switched back to CYGDAT_IO_USB_SLAVE_CLASS_TYPE == "generic" for the time
being.

With the eCos "generic" USB serial support, I'm issuing:

  modprobe usbserial vendor=0xffff product=0x0001

and seeing:

Oct 15 13:49:49 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 35
Oct 15 13:49:59 cog kernel: usb 4-1: configuration #1 chosen from 1 choice
Oct 15 13:49:59 cog kernel: usbserial_generic 4-1:1.0: generic converter
detected
Oct 15 13:49:59 cog kernel: usb 4-1: generic converter now attached to ttyUSB0

So far, so good.

I can connect to /dev/ttyUSB0 using minicom and send/receive chars over USB.

The remaining problem is that every other char I receive on the eCos side is a
copy of the previous character received. If I type "abcdefgh" into minicom,
eCos receives "?bbddffh". The very first char received is random. The timing of
all received characters is as expected (immediately after hitting the key). The
transmission of chars from eCos to minicom is working correctly.

Can you see how this issue might arise with your latest STM32 USB driver code?
Is there some further tracing I could add to debug this?

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

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

[bugzilla-daemon]

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

Ilija Stanislevik <ilijas@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijas@siva.com.mk

--- Comment #13 from Ilija Stanislevik <ilijas@siva.com.mk> 2010-10-15 17:12:42 BST ---
(In reply to comment #12)
I did the same thing like John. The result is somewhat different. I'm getting
echo of every even character, while the odd ones are lost. When I type
"abcdefgh" the echo is "bdfh".

Furthermore I used usb sniffer to confirm that the host correctly sends all
characters, each in a separate out packet.

How can I further help the development? I can dedicate some of my time for
this.

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

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

[bugzilla-daemon]

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

--- Comment #14 from John Dallaway <john@dallaway.org.uk> 2010-10-15 18:06:58 BST ---
(In reply to comment #13)

> I did the same thing like John. The result is somewhat different. I'm getting
> echo of every even character, while the odd ones are lost. When I type
> "abcdefgh" the echo is "bdfh".
> 
> Furthermore I used usb sniffer to confirm that the host correctly sends all
> characters, each in a separate out packet.
> 
> How can I further help the development? I can dedicate some of my time for
> this.

Ilija, it's good to have your support.

I was using a blocking call to read a single char:

    char rxbuf[1];
    while (1) {
      usbs_serial_rx(&usbs_ser0, rxbuf, 1);
      diag_printf("RX char: %c\n", rxbuf[0]);
    }

I have now determined that usbs_serial_rx() returns to caller on receipt of
every char but the buffer is modified only when even numbered chars are
received. Perhaps you were using a non-blocking read?

So the driver is responding to every char received but only the 2nd, 4th, 6th,
... chars are being processed correctly.

Hopefully Chris Holgate will be able to readily identify the problem from our
descriptions, otherwise your time in debugging this would be very helpful.

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

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

[bugzilla-daemon]

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

--- Comment #15 from John Dallaway <john@dallaway.org.uk> 2010-10-15 21:51:40 BST ---
One further data point:

  On receipt of the 1st, 3rd, 5th, ... chars, the RX complete callback function
is called with the result parameter set to zero. This implies that either
rxep->rxtr.status == 0 or rxep->rxtr.bytes_rcvd == 0.

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

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

[bugzilla-daemon]

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

--- Comment #16 from Ilija Stanislevik <ilijas@siva.com.mk> 2010-10-16 08:41:11 BST ---
(In reply to comment #14)
> 
> I was using a blocking call to read a single char:
> 
>     char rxbuf[1];
>     while (1) {
>       usbs_serial_rx(&usbs_ser0, rxbuf, 1);
>       diag_printf("RX char: %c\n", rxbuf[0]);
>     }
> 
> I have now determined that usbs_serial_rx() returns to caller on receipt of
> every char but the buffer is modified only when even numbered chars are
> received. Perhaps you were using a non-blocking read?

Yes, I was using the non-bloking read function usbs_start_rx_buffer().

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

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

[bugzilla-daemon]

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

--- Comment #17 from Chris Holgate <chris@zynaptic.com> 2010-10-16 11:12:42 BST ---
(In reply to comment #13)
> (In reply to comment #12)
> I did the same thing like John. The result is somewhat different. I'm getting
> echo of every even character, while the odd ones are lost. When I type
> "abcdefgh" the echo is "bdfh".
> 
> Furthermore I used usb sniffer to confirm that the host correctly sends all
> characters, each in a separate out packet.
> 
> How can I further help the development? I can dedicate some of my time for
> this.

The fact that you have a USB bus sniffer could be very useful here. Could you
check to see if the host is sending anything else in addition to the packets
containing the characters.  In particular, is it sending out any zero length
packets in between the character packets?

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

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

[bugzilla-daemon]

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

--- Comment #18 from Ilija Stanislevik <ilijas@siva.com.mk> 2010-10-16 11:55:13 BST ---
(In reply to comment #17)

> The fact that you have a USB bus sniffer could be very useful here. Could you
> check to see if the host is sending anything else in addition to the packets
> containing the characters.  In particular, is it sending out any zero length
> packets in between the character packets?

The host does not send any out-packets other than the ones containing the
characters typed in minicom. Depending on how fast I type, there are
occasionally intermitted in-packets which are NAK-ed (device has nothing to
send).

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

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

[bugzilla-daemon]

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

--- Comment #19 from Chris Holgate <chris@zynaptic.com> 2010-10-16 13:17:42 BST ---
(In reply to comment #18)
> (In reply to comment #17)
> 
> > The fact that you have a USB bus sniffer could be very useful here. Could you
> > check to see if the host is sending anything else in addition to the packets
> > containing the characters.  In particular, is it sending out any zero length
> > packets in between the character packets?
> 
> The host does not send any out-packets other than the ones containing the
> characters typed in minicom. Depending on how fast I type, there are
> occasionally intermitted in-packets which are NAK-ed (device has nothing to
> send).

Ok - that eliminates on possible cause.  The bug is obviously an issue with the
double buffering on bulk endpoints, but I have not seen it before with my class
driver.  The most obvious difference here is that John's request is sized
'exactly' for a single character, while I have been using an oversized receive
buffer.

Does the problem still occur if the request specifies an RX buffer size of,
say, 100 characters?  Also, can you check that your build has asserts enabled,
since most of the unexpected driver behaviour should be covered by assert
conditions.

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

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

[bugzilla-daemon]

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

--- Comment #20 from John Dallaway <john@dallaway.org.uk> 2010-10-16 14:53:07 BST ---
(In reply to comment #19)

> Does the problem still occur if the request specifies an RX buffer size of,
> say, 100 characters?  Also, can you check that your build has asserts enabled,
> since most of the unexpected driver behaviour should be covered by assert
> conditions.

Chris, in my single char blocking read experiment (comment #14) I had
CYGDBG_USE_ASSERTS enabled.

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

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

[bugzilla-daemon]

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

--- Comment #21 from Ilija Stanislevik <ilijas@siva.com.mk> 2010-10-16 15:34:12 BST ---
(In reply to comment #19)


> Does the problem still occur if the request specifies an RX buffer size of,
> say, 100 characters? 

In my tests the request states buffer size of 4096. After the Comment #19 I
repeated the test with 1 and again with 100 bytes requested. No change in
behavior. 

> Also, can you check that your build has asserts enabled,
> since most of the unexpected driver behaviour should be covered by assert
> conditions.

The asserts are enabled.

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

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

[bugzilla-daemon]

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

Chris Holgate <chris@zynaptic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #994 is|0                           |1
           obsolete|                            |

--- Comment #22 from Chris Holgate <chris@zynaptic.com> 2010-10-16 20:29:58 BST ---
Created an attachment (id=1000)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1000)
STM32 USB driver package fixing double buffering configuration bug.

The bug which was causing alternate bulk transfer packets to fail was due to
misconfiguration of the receive bulk transfer endpoint.  My own class driver
masked the bug because of the particular order in which it configured the
endpoints.  The updated USB driver package should fix this problem for the
serial port class driver.  A couple of points to note:

1) When using the serial port class driver, the variable length bulk transfer
option must be deselected.  This option may benefit from another descriptive
name in order to avoid confusion.

2) To avoid buffer overflow conditions on large transfers, all calls to the
serial port receive functions should specify a buffer which is a multiple of
the bulk transfer message size for the bulk transfer endpoint (usually 64
bytes).

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

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

[bugzilla-daemon]

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

--- Comment #23 from John Dallaway <john@dallaway.org.uk> 2010-10-17 15:21:11 BST ---
Chris, thank you for the double buffering fix. I am now able to receive all
characters sent from minicom, but the application locks up after a few
characters have been received (not always the same number of chars). The same
problem occurs with the "usbserial_echo" test in the USB serial function
package. I definitely have variable length bulk transfers disabled and the
usbserial_echo test uses a 4096 byte buffer.

Do you have any time to look at this? If not, Ilija Stanislevik may be able to
investigate. Either way, any ideas as to the possible cause of this lock up
would be much appreciated.

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

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

[bugzilla-daemon]

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

--- Comment #24 from Chris Holgate <chris@zynaptic.com> 2010-10-17 16:06:37 BST ---
(In reply to comment #23)
> Chris, thank you for the double buffering fix. I am now able to receive all
> characters sent from minicom, but the application locks up after a few
> characters have been received (not always the same number of chars). The same
> problem occurs with the "usbserial_echo" test in the USB serial function
> package. I definitely have variable length bulk transfers disabled and the
> usbserial_echo test uses a 4096 byte buffer.

I've not been able to replicate that here.  Loopback to minicom using the
method you've previously described seems to work fine for me (for a few hundred
characters at least).  I couldn't get my Linux machine to correctly recognize
the eCos serial loopback until I ditched my FTDI based USB/serial adapter for
the Redboot connection - but once I reverted to a 'proper' serial port for
Redboot things have been fine.  The test code I used is the absolute minimum I
could get away with (see below)...

#include <cyg/hal/hal_arch.h>             // CYGNUM_HAL_STACK_SIZE_TYPICAL

#include <cyg/infra/cyg_type.h>
#include <cyg/infra/cyg_ass.h>
#include <cyg/infra/diag.h>

#include <cyg/kernel/kapi.h>
#include <cyg/io/usb/usbs_serial.h>

//-----------------------------------------------------------------------------
// Thread primitives used for eCos application startup.

static cyg_uint8 stack [CYGNUM_HAL_STACK_SIZE_TYPICAL]
__attribute__((aligned(8)));
static cyg_thread thread_data;
static cyg_handle_t thread_handle;

//-----------------------------------------------------------------------------
// Main thread entry point.

extern "C" void mainThreadStartup 
  (void)
{
    int rxBytes, txBytes, i;
    char rxBuf[256];

    // Set up the USB serial interface.
    diag_printf("Setting up the USB serial interface.\n");
    usbs_serial_start();

    while(1) {
        rxBytes = usbs_serial_rx(&usbs_ser0, rxBuf, 256);
        for (i = 0; i < rxBytes; i++)
            diag_printf("%c", rxBuf[i]);
        txBytes = usbs_serial_tx(&usbs_ser0, rxBuf, rxBytes);
    }
}

//-----------------------------------------------------------------------------
// Startup function called in the context of the eCos idle thread once all the
// system startup is complete.

extern "C" void cyg_user_start 
  (void)
{
    cyg_thread_create(
        10,                                      // Arbitrary priority
        (cyg_thread_entry_t*) mainThreadStartup, // Thread entry point
        0,                                       // 
        (char*) "app_thread",                    // Thread name
        &stack[0],                               // Stack
        CYGNUM_HAL_STACK_SIZE_TYPICAL,           // Stack size
        &thread_handle,                          // Thread handle
        &thread_data                             // Thread data structure
    );
    cyg_thread_resume(thread_handle);
    cyg_scheduler_start();
}

//-----------------------------------------------------------------------------

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

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

[bugzilla-daemon]

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

--- Comment #25 from John Dallaway <john@dallaway.org.uk> 2010-10-17 16:29:13 BST ---
(In reply to comment #24)

> I've not been able to replicate that here.  Loopback to minicom using the
> method you've previously described seems to work fine for me (for a few hundred
> characters at least).  

That's good news. Could you export your eCos config to a .ecm file and attach
to this report please? I will try to reproduce your success...

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

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

[bugzilla-daemon]

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

--- Comment #26 from Chris Holgate <chris@zynaptic.com> 2010-10-17 19:07:49 BST ---
Created an attachment (id=1001)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1001)
STM32 USB driver configuration for successful loopback test

As requested, this is the minimal configuration which I have successfully used
for the STM32 USB serial driver loopback test.

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

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

[bugzilla-daemon]

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

--- Comment #27 from Ilija Stanislevik <ilijas@siva.com.mk> 2010-10-17 19:33:51 BST ---
(In reply to comment #22)

Tested with 4096 and again with 64 bytes requested. Tested by typing characters
in minicom, as well as by sending an ASCII file from minicom. Works in all
cases. Seems fine now.

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

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

[bugzilla-daemon]

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

--- Comment #28 from John Dallaway <john@dallaway.org.uk> 2010-10-18 10:35:47 BST ---
Created an attachment (id=1002)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1002)
usbs_serial-101018.patch

I have USB serial working on STM32 now. This provisional patch adds support for
the dynamic configuration of I/O endpoint structures to the USB serial function
driver in line with Chris Holgate's USB API change proposal.

I'm concerned that usbs_serial_start() will now block until a connection has
been established and endpoints have been configured. How will this affect the
implementation multiple function devices over a single USB port where multiple
usbs_*_start() functions may need to be called? I'm thinking that it should be
possible to present both a mass storage device and a serial device (for
example) over a single physical interface. While it's desirable to minimise
code changes, we should not restrict the capabilities of the USB slave support
in the process.

Chris, I would value your comments on the above.

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

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

[bugzilla-daemon]

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

--- Comment #29 from Chris Holgate <chris@zynaptic.com> 2010-10-20 19:27:14 BST ---
(In reply to comment #28)

> I'm concerned that usbs_serial_start() will now block until a connection has
> been established and endpoints have been configured. How will this affect the
> implementation multiple function devices over a single USB port where multiple
> usbs_*_start() functions may need to be called? I'm thinking that it should be
> possible to present both a mass storage device and a serial device (for
> example) over a single physical interface. 

I don't think this scenario is supported by the USB spec - a single end device
can only ever implement a single class driver, as identified by the device
descriptor.  To get multiple class drivers running behind a single USB
connector, you would need to emulate a USB hub and hang the class drivers off
the back of that - one per virtual USB slave device.

While such a feature would be nice to have, it would need quite a bit of extra
work and may require additional features which are not present on the currently
supported hardware.

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

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

[bugzilla-daemon]

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

--- Comment #30 from John Dallaway <john@dallaway.org.uk> 2010-10-21 09:57:39 BST ---
(In reply to comment #29)
> (In reply to comment #28)
> 
> > I'm concerned that usbs_serial_start() will now block until a connection has
> > been established and endpoints have been configured. How will this affect
> > the
> > implementation multiple function devices over a single USB port where 
> > multiple
> > usbs_*_start() functions may need to be called? I'm thinking that it should
> > be
> > possible to present both a mass storage device and a serial device (for
> > example) over a single physical interface. 
> 
> I don't think this scenario is supported by the USB spec - a single end device
> can only ever implement a single class driver, as identified by the device
> descriptor.  To get multiple class drivers running behind a single USB
> connector, you would need to emulate a USB hub and hang the class drivers off
> the back of that - one per virtual USB slave device.
> 
> While such a feature would be nice to have, it would need quite a bit of extra
> work and may require additional features which are not present on the currently
> supported hardware.

Chris, thanks for your reply. I had assumed that this is how (eg) USB docking
stations work. Perhaps they use a vendor-specific class.

Is there any way to avoid the blocking usbs_*_start() call when using dynamic
endpoint configuration? I was wondering if the endpoint structs should be
retrieved within usbs_*_wait_until_configured(), which is already a blocking
call, rather than within usbs_*_start(). usbs_*_wait_until_configured() would
not be called from usbs_*_start(). This would make a call to
usbs_*_wait_until_configured() essential rather than advisable but would avoid
a hardware-dependent variation in blocking/non-blocking behaviour of
usbs_*_start(). Does this make sense to you?

Will the driver re-use the same endpoint structures if the cable is
disconnected and then reconnected?

I'm just wanting to check we have all bases covered here.

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

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

[bugzilla-daemon]

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

Alan Bowman <alan.bowman@datong.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan.bowman@datong.co.uk

--- Comment #31 from Alan Bowman <alan.bowman@datong.co.uk> 2010-10-21 16:40:19 BST ---

> I don't think this scenario is supported by the USB spec - a single end device
> can only ever implement a single class driver, as identified by the device
> descriptor.  To get multiple class drivers running behind a single USB
> connector, you would need to emulate a USB hub and hang the class drivers off
> the back of that - one per virtual USB slave device.

While I haven't looked through the spec for a while, I believe that you _can_
have multiple class drivers on a single device without using a virtual hub.  I
think it's called a composite device.  The descriptor arrangement is a bit more
complicated, but it's still possible.

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

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

[bugzilla-daemon]

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

--- Comment #32 from Chris Holgate <chris@zynaptic.com> 2010-10-21 19:32:15 BST ---
(In reply to comment #31)

> While I haven't looked through the spec for a while, I believe that you _can_
> have multiple class drivers on a single device without using a virtual hub.  I
> think it's called a composite device.  The descriptor arrangement is a bit more
> complicated, but it's still possible.

Your recollection of the spec is obviously better than mine.  As you say,
composite devices are supported and I should probably have used the Google
before posting misleading rubbish!  However, a single device can still only
have one control endpoint and one root descriptor, which means the scenario
John mentioned of multiple class drivers calling usbs_start with different (or
even the same) control endpoint data structures should never happen.

I think that supporting composite drivers is really an issue for a notional USB
class driver framework.  As far as the existing low level USB slave drivers are
concerned, a USB device is just a bundle of endpoints and a bunch of arbitrary
descriptors.  IMHO that is exactly the right level of abstraction - and any
additional support for composite drivers should be added as an extra layer of
abstraction between the low level USB slave driver and the class function
drivers.

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

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

[bugzilla-daemon]

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

--- Comment #33 from Chris Holgate <chris@zynaptic.com> 2010-10-21 19:47:48 BST ---
(In reply to comment #30)

> Is there any way to avoid the blocking usbs_*_start() call when using dynamic
> endpoint configuration? I was wondering if the endpoint structs should be
> retrieved within usbs_*_wait_until_configured(), which is already a blocking
> call, rather than within usbs_*_start(). usbs_*_wait_until_configured() would
> not be called from usbs_*_start(). This would make a call to
> usbs_*_wait_until_configured() essential rather than advisable but would avoid
> a hardware-dependent variation in blocking/non-blocking behaviour of
> usbs_*_start(). Does this make sense to you?

Yes - that is a cleaner way to do it.  At the moment USB class driver
implementations are a bit ad-hoc and documenting a recommended set of lifecycle
management functions as above would help to add some consistency.

> Will the driver re-use the same endpoint structures if the cable is
> disconnected and then reconnected?

Not necessarily - if the descriptors change or the host selects a different
configuration, all bets are off.  Any endpoint references held by a class
driver should be treated as going out of scope when the USB device leaves the
'configured' state.

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

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

[bugzilla-daemon]

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

--- Comment #34 from John Dallaway <john@dallaway.org.uk> 2010-10-21 22:20:33 BST ---
(In reply to comment #32)
> (In reply to comment #31)
> 
> > While I haven't looked through the spec for a while, I believe that you
> > _can_
> > have multiple class drivers on a single device without using a virtual
> > hub.  I
> > think it's called a composite device.  The descriptor arrangement is a bit
> > more complicated, but it's still possible.
> 
> Your recollection of the spec is obviously better than mine.  As you say,
> composite devices are supported and I should probably have used the Google
> before posting misleading rubbish!  However, a single device can still only
> have one control endpoint and one root descriptor, which means the scenario
> John mentioned of multiple class drivers calling usbs_start with different (or
> even the same) control endpoint data structures should never happen.
> 
> I think that supporting composite drivers is really an issue for a notional 
> USB
> class driver framework.  As far as the existing low level USB slave drivers
> are
> concerned, a USB device is just a bundle of endpoints and a bunch of arbitrary
> descriptors.  IMHO that is exactly the right level of abstraction - and any
> additional support for composite drivers should be added as an extra layer of
> abstraction between the low level USB slave driver and the class function
> drivers.

Agreed. Composite devices have one device descriptor, one configuration
descriptor and multiple interface descriptors. With the current USB slave
infrastructure it would be easy enough to implement a new composite device but
not so easy to re-use multiple existing function device packages to form a
composite device. I think this should not affect the proposal for dynamic
endpoint configuration.

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

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

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1002|0                           |1
        is obsolete|                            |

--- Comment #35 from John Dallaway <john@dallaway.org.uk> 2010-10-25 09:48:14 BST ---
Created an attachment (id=1005)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1005)
usbs_serial-101025.patch

This revised USB serial function driver patch calls the
usbs_get_[tr]x_endpoint() functions from usbs_serial_wait_until_configured() to
avoid changing the non-blocking behaviour of usbs_serial_start().

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

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

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #975 is|0                           |1
           obsolete|                            |

--- Comment #36 from John Dallaway <john@dallaway.org.uk> 2010-10-26 11:49:52 BST ---
Created an attachment (id=1006)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1006)
usbs-101026.patch

This patch is a documented version of Chris Holgate's modified USB slave API
patch. The original patch was marked "for comment only". Chris, can you confirm
that you are OK for this to be checked in now?

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

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

[bugzilla-daemon]

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

--- Comment #37 from Chris Holgate <chris@zynaptic.com> 2010-10-26 20:15:03 BST ---
(In reply to comment #36)
> Created an attachment (id=1006)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1006) [details]
> usbs-101026.patch
> 
> This patch is a documented version of Chris Holgate's modified USB slave API
> patch. The original patch was marked "for comment only". Chris, can you confirm
> that you are OK for this to be checked in now?

I think that the patch looks safe to check in.  I think we've given it a fair
workout with the STM32 driver - and the the changes are all additive, so there
shouldn't be any regressions with existing drivers.

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

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

[bugzilla-daemon]

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

--- Comment #38 from John Dallaway <john@dallaway.org.uk> 2010-10-27 11:25:38 BST ---
The USB slave API and USB serial function patches are now checked in.

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

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

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #39 from John Dallaway <john@dallaway.org.uk> 2010-10-27 14:04:28 BST ---
Chris, the STM32 USB driver is now checked in. Many thanks for your valuable
contribution!

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