RE: [PATCH 3/3 v2] musb: AM35x: Workaround for fifo read issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux