Hi, On Mon, Sep 24, 2012 at 09:09:14AM -0700, Tony Lindgren wrote: > * 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? Then maybe it's best to just remove the ifdefs and always provide generic_interrupt() ? Anyone against it ? -- balbi
Attachment:
signature.asc
Description: Digital signature
