Gupta, Ajay Kumar wrote: > Fixes/workaround based on CONFIG_MACH_OMAP3517EVM will be good only for > OMAP3517EVM and would not scale well to other boards based on AM35x. > (As commented earlier by Sergei) > > I just got to know of another board "LIZARD" based on AM35x so we really > need to find a solution for this. > > This problem is due to the fact that AM35x is based on OMAP35x but musb ip > Is updated to RTL1.8 using CPPI4.1 DMA engine thus we need to have a > config option to differentiate musb ips between actual OMAP3 and AM35x > platforms. > > I am thinking of adding new config option OMAP_MUSB_RTL18 which should be > selected by all the boards based on AM35x in arch/arm/mach-omap2/Kconfig. > > The same config option can be used for all the workaround/fixes specific > to AM35x musb platform. > > ------------------ > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index b72ae06..3ab1156 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -95,6 +95,7 @@ config MACH_OMAP3517EVM > bool "OMAP3517/ AM3517 EVM board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select OMAP_PACKAGE_CBB > + select OMAP_MUSB_RTL18 > > config PMIC_TPS65023 > bool "TPS65023 Power Module" > ------------------ > > Does anyone has a better option to fix this issue or any > comment on this approach? > 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). - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
