From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1668 invoked by alias); 20 May 2009 10:19:08 -0000 Received: (qmail 1656 invoked by uid 22791); 20 May 2009 10:19:07 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from alicia.2020media.com (HELO alicia.2020mail.com) (212.124.192.215) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 10:19:01 +0000 Received: from [212.124.199.38] (helo=[192.168.0.2]) by alicia.2020mail.com with esmtp (Exim 4.30; FreeBSD) id 1M6isp-000LBX-Sl; Wed, 20 May 2009 11:18:47 +0100 Message-ID: <4A13D90F.2000600@zynaptic.com> Date: Wed, 20 May 2009 10:19:00 -0000 From: Chris Holgate User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Frank Pagliughi CC: Andrew Lunn , Simon Kallweit , ecos-devel@sourceware.org Subject: Re: STM32 USB support References: <4A11CAAA.8040900@intefo.ch> <4A11D861.8090206@zynaptic.com> <4A11E5DF.2000403@intefo.ch> <4A129C34.9090606@zynaptic.com> <20090519120004.GI20046@lunn.ch> <4A12D3CC.1070707@zynaptic.com> <4A137430.2010903@mindspring.com> In-Reply-To: <4A137430.2010903@mindspring.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00039.txt.bz2 Frank Pagliughi wrote: > > Yeah, the USB subsystem for eCos was written at a time when USB chips > were quite rigid - endpoints with fixed sizes and functions. Now, most > chips are more flexible than not, with generic endpoints and > configurable memory allocation. So the existing eCos infrastructure is > showing it's age. So each new driver is hitting this same problem and > trying to solve it in a new and different way. My thoughts are that the current infrastructure is still pretty usable and that the main limitations are the use of static devtab entries (which are optional anyway) and the drivers themselves. More specifically, there isn't a good example of how to use the infrastructure to write drivers for these more configurable USB devices. My main bugbear is the way in which class drivers currently access device endpoints. At the moment you need to know which low level driver is in use and the completely arbitrary names of the exported static endpoint data structures. This should really be hidden behind a generic API which is defined by usbs.h. I think that this would be an easy change and would require mimimal additions to the existing drivers. Existing drivers could add the endpoint 'getter' functions and still export their static endpoint data structures for legacy class drivers. > IIRC, at the time I had fairly convinced myself that what was needed was > an entirely new USB subsystem that would: > - make it much easier to work with the flexible new chips > - handle much more of the device enumeration There's quite a bit of code in the STM32 driver which addresses these issues within the existing framework. Maybe the thing to do would be to factor it out into a device driver utility library which can be used alongside the existing framework. > - provide a very specific callbacks structure (like read/write an > endpoint, respond to a bus reset, set the chips' address, etc) > - handle more of the buffering While the existing callback setup may not be the easiest to use, it does provide all the required information. As for buffering, this is something which I think should be a matter for the class driver writer. Again, this could all be made easier by better documentation and a possible class driver utility library. > In general, make it much easier to knock out USB drivers. It's never going to be really easy though! Chris.