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 ? > > BTW, this is also wrong as OMAP2PLUS is also used to enable AM3xxx and > > TI8xxx, and those platforms don't use generic_interrupt(). > > It would not break them from what I could see in musb_core.c > > musb->isr = generic_interrupt; > status = musb_platform_init(musb); <--- isr would be (re)set here good point. Still that code would be hanging there with no users... Fair enough, it's better to have extra code when it's not needed, then having no code when it's needed :-) That entire musb->isr crap is quite screwed up anyway and it's just because TI's non-OMAP processors (daxxx, amxxx, ti8xxx, etc) decided that the wrapper should read MUSB's address space (including IRQ registers) and since MUSB's IRQ registers are clear-on-read we need to handle the IRQ from wrapper drivers, which is pretty screwed up as well. Ideally, we wouldn't have all of these exposed symbols flying around :-s -- balbi
Attachment:
signature.asc
Description: Digital signature
