From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4706 invoked by alias); 26 Aug 2010 11:00:31 -0000 Received: (qmail 4663 invoked by uid 22791); 26 Aug 2010 11:00:30 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Aug 2010 11:00:20 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 6FED52F7800A for ; Thu, 26 Aug 2010 12:00:18 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuNZn031-ao7; Thu, 26 Aug 2010 12:00:13 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001024] STM32 USB driver and proposed USB API change X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: chris@zynaptic.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 26 Aug 2010 11:00:00 -0000 Message-Id: <20100826110013.B28EC2F78003@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2010-08/txt/msg00005.txt.bz2 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 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.