On Wed, Mar 02, 2011 at 12:22:06PM +0000, Matthieu Castet wrote: > Hi, > > > I knew that a ehci controller is often combined with a gadget > > controller to get otg support. What I didn't know is that it's always > > the same gadget controller. Currently we have not less than 4 drivers > > for the same hardware in the tree: > > > > langwell_udc.c > > mv_udc_core.c > > ci13xxx_udc.c > > fsl_udc_core.c > > Yes, I reported it some time ago : http://marc.info/?l=linux-usb&m=129751953620076&w=2 > > > > Altogether there seems to be enough room for merging code. > > Unfortunately I won't have much time to work on this, so I'd like to > > ask if anyone else is interested in joining forces to get some > > cleanup done. > > I am interested, but I don't too much time either. > > What I planned to do was to make fsl_udc_core generic : > - extract probe/remove/suspend/resume platform stuff in platform driver. The core is generic like host ehci (and some flags if needed). > - provide a callback for post reset (ulpi stuff) > - handle strange clock handling (pre and post) > > I started to do something, but I never found time to finish it. > > > > At least I think we should pick one of the drivers above, sort the > > architecture specfic part out and rename it to something like > > ehci_udc.c to prevent people from adding even more drivers to the > > tree. The ci13xxx_udc driver looks most promising to me as it already > > has otg support in drivers/usb/otg/msm72k_otg.c and has proven to > > work on i.MX aswell. Also it has pci support. Originally it was > > posted for mips, so it probably works there, too > I think the ci13xxx_udc code is not the best. > It is not tested very well, the original code was pci (for eval board) no otg. > Msm did their driver (http://marc.info/?t=128930153200003&r=1&w=2) > and I recommended them to use the in kernel driver. At that time I > didn't know of fsl driver and only though there was ci13xxx_udc driver > for ehci udc. What a same. If they used fsl one, things will be much > simpler. No objections on that. It was easy enough to port i.MX (which uses the fsl_udc_core) over to ci13xxx, so I suppose it will be easy the other round aswell. What I missed in the fsl udc driver was that it does not work with otg because it setups the controller for device mode in its probe function. > > So ci13xxx_udc is only used by msm, and they start cleaning the code. > The mips version got some bugs/missing features [1]. For example the > hardware queuing (http://marc.info/?l=linux-usb&m=129803121032245&w=2) > that is already in fsl driver for years is a newer feature of the > driver. Also ci13xxx_udc use features not available on all core ( > http://www.nxp.com/documents/user_manual/UM10314.pdf USBADRA of > DEVICEADDR). > > For me the best candidate are fsl one or langwell : > - fsl_udc_core is the historic driver and seems to have tested pretty well (and was used on big/little endian arch). Know to work on > older cores. > - langwell_udc is pretty active one and got otg support (and lpm). But ATM it work only with lpm core (the register layout change). Don't know much about the langwell otg, but it looks fairly complete and has otg support. The only thing I noticed is that it assumes 64 bit aligned registers. > > I hope we could find a way to merge them. Me too. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
