> > We have to deal with a historically grown wrong hardware abstraction > here. What we have from a hardware point of view is a device consisting > of: > > - A ehci core (theoretically optional, but seems to be always present) > - A Synopsys USB device core (optional), the one we currently have four > different drivers for. > - A USB phy (mandatory, but may be nearly invisible from software). The > phy may be an external ULPI phy, an internal phy in the SoC, or even > selectable between both. > > Currently we have a ehci-mxc driver which claims resources like mem > regions, interrupts and clocks. We also have the gadget driver > (currently the fsl_mxc_udc driver) which also claims the same resources. > Instead we should have a glue driver which claims the resources and > passes control over to either the host or the gadget driver. This glue > code should also connect the phy. > > Looking at the code in mainline the msm driver is closest to what we > want to have. It claims the resources in msm_otg.c and passes control > over to the ehci or ci13xxx gadget driver depending on the USB id pin or > a platform decision. What's missing here is some plugin mechanism for > different phys. That's another historically grown thing that there is > only a single phy in the Kernel because there can be only one otg > instance and phys were thought to be present only in otg cores. Heikkis > patches work in the right direction here. msm_otg.c is really good code which mainlined this year, it considers many user situations, like low power, charger, usb wakeup, id/vbus changes from different hardware/user choice, etc. In fact, the most difficulties for otg driver (host/device share the same registers controller) are clock management, power management, usb wakeup, register access among the three drivers (otg, host and device driver) > > As a conclusion I think that there should be no platform or SoC specific > code in neither the ehci nor in the gadget driver. Also there shouldn't > be all these ehci-$SoC.c files in the tree. The way to get there could > be: > > - Work on Heikkis patches so that we can register usb phys > - move the USB phy setup code from arch-imx to drivers/usb/phy > - factor out the common code from the msm_otg driver. > - create a imx-otg.c which only claims the resources and passes > them to the otg common code. Sooner or later not even an imx-otg.c is > necessary because we can use a devicetree based driver and then only > the phy code will be SoC specific. I agree with these tasks for refine i.mx usb structure. I will try Heikki's patch first. > > I'm sorry that there is no easy way to get proper USB support, but we > are way beyond the point where the current infrastructure scales. > In any way, there is no place for more SoC specific code in ehci-mxc.c. > Instead you should work on moving SoC code out of there. > > 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
