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. -- balbi
Attachment:
signature.asc
Description: Digital signature
