kirkwood devicetree respin

[Felipe Balbi]

On Wed, Mar 21, 2012 at 08:06:12PM +0000, Paul Zimmerman wrote:
> > From: linux-usb-owner at vger.kernel.org [mailto:linux-usb-owner at vger.kernel.org] 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120322/3aba701b/attachment.pgp>