* Felipe Balbi <balbi@xxxxxx> [120924 06:08]: > Hi, > > On Mon, Sep 24, 2012 at 03:54:22PM +0300, Philippe De Swert wrote: > > Hi, > > > > On 24/09/2012, Felipe Balbi <balbi@xxxxxx> wrote: > > > SoB's mail doesn't From mail. > > > > Well still in the progress of migrating of my personal to work laptop. > > Since the patch does not seem correct the replacement will have > > matching addresses. > > > > >> /*-------------------------------------------------------------------------*/ > > >> > > >> #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \ > > >> - defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) > > >> + defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \ > > >> + defined(CONFIG_ARCH_OMAP2PLUS) > > > > > > Weird, how can you build OMAP2PLUS without SOC_OMAPXXXX ?? > > > > It seems entirely possible. I quickly tried to look if it got defined > > somewhere and it does not seem to be set anywhere. That is why I got > > the impression it was replaced by CONFIG_ARCH_OMAP2PLUS. I'll dig > > deeper to find out why SOC_OMAPXXXX is not set if it should be. > > > > From the .config I got (used menuconfig) > > > > # > > # TI OMAP2/3/4 Specific Features > > # > > CONFIG_ARCH_OMAP2PLUS_TYPICAL=y > > CONFIG_SOC_HAS_OMAP2_SDRC=y > > # CONFIG_ARCH_OMAP2 is not set > > CONFIG_ARCH_OMAP3=y > > # CONFIG_ARCH_OMAP4 is not set > > # CONFIG_SOC_OMAP5 is not set > > # CONFIG_SOC_OMAP3430 is not set > > # CONFIG_SOC_TI81XX is not set > > # CONFIG_SOC_AM33XX is not set > > CONFIG_OMAP_PACKAGE_CBB=y > > > > Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not > > get set (while it is not a 3430 but a 3630 I am using). Maybe > > CONFIG_ARCH_OMAP3 would have been a better choice then? > > that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all > OMAP3 boards ? And another question: why don't we have a matching > SOC_OMAP3530, SOC_OMAP3630 and so on ? ARCH_OMAP3 will probably eventually just disappear and be replaced with ARCH_OMAP2PLUS + SOC_XXXX. But there's no need to do it right now as most of that should be internal to arch/arm/mach-omap2 anyways. I would just set the driver to depend on ARCH_OMAP2PLUS, and rely on the platform_data and DT to do something if specified. That means that on 2420 musb should not probe unless tusb6010 in specified. It seems that things like fifo_mode and generic_interrupt can all be set during the probe based on the platform_data or DT passed information? Regards, Tony -- 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
