On Friday 07 January 2005 6:32 am, Raghunathan K wrote: > Hi Dave, > > I browsed through source code of 2.4 kernel non PCI based controller drivers > (pxa2xx_udc, n9604, and superh_udc). I have a few doubts based on it - > > * init() function : handles all initialisations ,mainly filling the xxx_udc > structure with endpoint and device (ep 0) specific data from some hardcoded > structures (eg. epNo,epType,Vendorid,maxpacketsize...) . It also sets > various endpoint registers and installs interrupt handlers.
Vendor ID (and manufacturer ID) are provided by the gadget driver; such policy decisions do NOT belong in the hardware-specific logic. > Provided there are quite a number of endpoints to initialise it is it ok > to put all their initialisations in the init() function ? The init() function is called only once, for driver initialization; so it's the right place for any "do it once" initialization. Some of the endpoint fields get reinitialized before binding to a gadget driver; that's mostly paranoia, protecting against bugs. The PXA25x driver initializes its endpoint structures statically, so it's done by the compiler ... saving code space, and shifting some data from the heap to the initialized data segment. > Also, I could not see the DMA descriptor list being created (for IN and > OUT). How is this DMA handled ? Also where are the buffers to be used by DMA > (sk_buff) allocated ? I did a search on dev_alloc_skb and found them in > ethernet-rndis module, which i found rather strange. None of those drivers use DMA, so I don't know what you mean. The PXA 25x driver has DMA infrastructure, but it's disabled by default. IN DMA transfers worked in light testing, but using DMA there isn't much of a win ... the PXA DMA hardware has absurd requirements about DMA alignment. Most folk seem to be using the ethernet/RNDIS code, and the network stack doesn't align TX buffers like that. If you'd like to make that DMA work better, feel free. OUT DMA transfers have never been tested; they'd need to use a nasty scheme to switch toggle between packets. > * i am still unclear about interface between the gadget and controller > driver. How will data be sent/received to/from the ether-rndis gadget driver > by our controller driver ? Each usb_request wraps one buffer. Gadget drivers queue such requests to endpoints, and the controller driver knows the endpoint's direction (writing data IN to the host, or reading it OUT from that host). So the controller driver does nothing at all until it's got a request, at the head of an endpoint's queue, from a gadget driver. The only data that goes spontaneously from the controller driver up to the gadget driver is control setup() requests. - Dave > > > Regards > Raghu > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David > Brownell > Sent: Wednesday, December 29, 2004 12:06 AM > To: linux-usb-devel@lists.sourceforge.net > Cc: Raghunathan K > Subject: Re: [linux-usb-devel] Embedded USB device development > > > On Tuesday 28 December 2004 4:20 am, Raghunathan K wrote: > > I used the latest 2.4.28 gadget files in my 2.4.20 build (from > > include/linux/usb* and drivers/gadget). After a few changes in > > makefiles and config.in i was able to compile the gadget framework. > > Good! Though you might want to grab the latest 2.4.29-pre > code as you get going; there are a few interface updates, > and a significant bugfix (memleak) to the RNDIS support. > > > > But since my board > > does not have PCI based support i was unable to compile the existing > net2280 > > and goku_udc controller drivers. I guess 2.6 kernel has examples of > > controller drivers which are not PCI based but ARM AHB based. > > AHB would normally be modeled as a platform bus. Its details should be more > meaningful to somone integrating an ARM cell into some system-on-chip design > (*) than to software ... that is, someone who compiles RTL to gates, not C > to assembly language. > > On 2.4 such busses don't have formal support; on 2.6 "platform_bus" is > normally used to model AHB interconnects in Linux. > > For kernel 2.4 based non-PCI drivers, see the gadget-2.4 tree as listed at > http://www.linux-usb.org/gadget ... you can browse the code on-line at > > http://usb-gadget.bkbits.net:8080/gadget-2.4 > > Non-PCI drivers there include pxa2xx_udc, n9604, and superh_udc. There are > other such drivers; most such work uses 2.6 lately. > > - Dave > > (*) http://www.arm.com/products/solutions/AMBAHomePage.html > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > linux-usb-devel@lists.sourceforge.net > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
