Hi, > > 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. AM35x musb needs different initialization sequence which involves PHY configuration etc. being done in drivers/usb/musb/am3517.c. am3517.c also need to handle different ISR routine and all CPPi4.1 DMA related programmings. > > 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). We do have such mechanism cpu_is_omap3517() but how about compilation flags for am3517.c? Do you intend to have different initialization sequence, ISR function and CPPI4.1 DMA programmings within drivers/usb/musb/omap2430.c ? -Ajay > > - 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
