Hi, > >It would not scale very well - we already have multi-omap builds > >that select support for multiple boards. If the AM35x boards are > >part of such builds, then mutually exclusive config options won't > >work - already n8x0 MUSB is exclusive with 243x/omap3. > > > >If it is possible to detect the AM35x at runtime, then we could > >handle this well. Also, a similar set of changes will be needed for > >the DMA code as well (right now we can pick only one of the DMA > >engines at a time). > > it's time to split out platform code from musb core. I was thinking of > having omap2430.c blackfin.c tusb6010.c davinci.c be a platform_device > that instantiates musb_hdrc platform_device. It would also ioremap() the > area and pass the gotten/enabled clock to musb. Then we can have all of > the platforms enabled since the board files would pass down the > platform_device for the platform code. Something like:
This approach would anyway not help the original issue discussed in this thread. We need to have some config option to differentiate musb ips between OMAP3 and AM35x. Another issue: Currently almost 90% of the code is same between drivers/usb/musb/da8xx.c and drivers/usb/musb/am3517.c. any idea on how to avoid duplication? Can we merge these two files and have compilation flags based on musb capability alone (like HAS_CPPI41) rather than CONFIG_ARCH_xx? This approach would also help the original issue of discussed in this thread. -Ajay > > arch/arm/mach-omap2/usb-musb.c: > [..] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
