> From: Felipe Balbi [mailto:balbi@xxxxxx] > Sent: Thursday, March 22, 2012 1:13 AM > > On Wed, Mar 21, 2012 at 08:06:12PM +0000, Paul Zimmerman wrote: > > > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Felipe > Balbi > > > Sent: Wednesday, March 21, 2012 6:23 AM > > > > > > On Wed, Mar 21, 2012 at 01:17:38PM +0000, Arnd Bergmann wrote: > > > > On Wednesday 21 March 2012, Felipe Balbi wrote: > > > > > I have explained an easy way to achieve that to Alan Stern, but he did > > > > > not like it. Basically, we should add a platform_device to ehci-hcd.ko > > > > > and make ehci-{omap,mv,fsl,atmel,etc} a parent device/driver which > > > > > basically passes the correct resources and handle platform-specific > > > > > details. > > > > > > > > > > That way, we could build everything together and udev would load the > > > > > correct modules for us. > > > > > > > > > > For an example of what I mean, see drivers/usb/dwc3/core.c, > > > > > drivers/usb/dwc3/dwc3-omap.c, and drivers/usb/dwc3/dwc3-pci.c > > > > > > > > While that way clearly works and can solve the problem we have > > > > with ehci today, I think it's easier and more consistent with > > > > other drivers to do it the opposite way, as we have recently > > > > discussed in the context of ohci: > > > > > > > > Make the base driver a loadable module that does not register > > > > any struct device_driver at all, but just exports functions to > > > > other module. The hardware specific drivers then each register > > > > to their own bus and use the functions exported by the > > > > main driver, with a way to override them with their own versions. > > > > > > > > Alan suggested a variation of that where we actually export > > > > a default "struct hc_driver" instead of the individual functions, > > > > which has the advantage of having to export fewer symbols, but > > > > otherwise is similar to what we do elsewhere. > > > > > > > > See libata, sdhci, serial-8250 or xhci for examples of this way. > > > > > > that is likely to work, indeed. My suggestion would make PM simpler > > > though and avoid some code duplication in the long run, meaning that > > > ehci-hcd.ko could have its own dev_pm_ops which e.g. knows how to save > > > EHCI's context while ehci-omap.c knows how to save OMAP-specific > > > context, toggle clocks, set pads in safe mode (when needed) and so on. > > > > > > But fair enough, both ways would work fine. > > > > I would also recommend your/Alan's approach to this over Felipe's way. > > We have a DWC3 platform with an (admittedly oddball) PM implementation > > that requires the bus driver to have some knowledge of the base driver's > > internal state, and needs the two drivers to be able to communicate with > > each other. With the base driver being a separate platform device, this > > is nearly impossible to achieve in a clean way. If the DWC3 driver was > > designed the way you and Alan are recommending, it would be easy. > > > > I'm trying to convince Felipe to change the DWC3 driver design to > > accommodate this, but I hold out little hope for that :) > > yeah, I'm not thinking on taking that patch, sorry. Didn't you say SNPS > had agreed on rebuilding the FPGA system so that it's a more standard > PCIe implementation ? > > I still owe you another possible implementation for the whole PM thing, > sorry about the delay. Dropped the other folks from CC since they probably aren't interested. The FPGA rework is very low priority, those guys have more important stuff to work on at the moment. Plus management doesn't understand why the current design won't work, since the Synopsys driver supports it OK. So I'm not sure when the FPGA rework will happen. -- Paul -- 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
