On Tue, Apr 17, 2012 at 01:45:07PM +0200, Marek Vasut wrote: > Dear Sascha Hauer, > > > Hi Marek, > > > > On Tue, Apr 17, 2012 at 12:15:43PM +0200, Marek Vasut wrote: > > > This patchset introduces the USB Host driver for i.MX28 CPU, utilising > > > the generic USB PHY infrastructure. > > > > Your patches won't work when more than one USB port is enabled because > > of the singular usb transceiver present in the kernel. That of course is > > not your fault. I think Heikki (Added to Cc) is working on this issue, > > but I don't know the status here. > > All right, I'll let Heikki hack on that. I'm not sure if we have any mx28 based > device with multiple USB ports in kernel. Do we ? > > > Another problem is that what you are doing does not integrate at all > > with otg. > > Well, how should this be done to integrate with OTG then? > > > I don't ask you to implement otg support because you are > > likely not interested in this, but since you are adding a new ehci > > glue driver anyway I suggest another approach: > > > > Put a driver under drivers/usb/otg which: > > > > - matches a 'imx-usb' device > > - gets/enables all clocks needed for USB > > - finds the transceiver > > - registers a ehci device > > So the PHY actually registers the EHCI driver (plat_bus->phy->ehci)? That's > slightly weird, don't you think? Your hardware device is a device consisting of a ehci core and a USB device core. Currently we register the child devices independently which leads to the mentioned problems. Instead we should register the USB core as a whole and pass the resources to either the client or the host driver. The phys are completely independent devices (from a bus topology point of view). The USB core just happens to use the phys. 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
