From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11513 invoked by alias); 26 Aug 2010 09:14:04 -0000 Received: (qmail 11495 invoked by uid 22791); 26 Aug 2010 09:14:02 -0000 X-SWARE-Spam-Status: No, hits=-1.3 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 09:13:57 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 1B4922F78006 for ; Thu, 26 Aug 2010 10:13:55 +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 sGB6gw32GdgJ; Thu, 26 Aug 2010 10:13:53 +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: john@dallaway.org.uk 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: CC Component 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 09:14:00 -0000 Message-Id: <20100826091352.DA0DA2F78003@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/msg00004.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 John Dallaway 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 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.