Re: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux