| Message ID | E0D41E29EB0DAC4E9F3FF173962E9E9402534261B3@dbde02.ent.ti.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
Hi Allen, > -----Original Message----- > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > owner@vger.kernel.org] On Behalf Of Pais, Allen > Sent: Sunday, September 20, 2009 9:47 AM > To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, Hariprasad > Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config > entries. > > > This patch creates the architectural macros for OMAP3630. > > Signed-off-by: Allen Pais <allen.pais@ti.com> > > arch/arm/mach-omap2/Kconfig | 13 ++ > arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 75b1c7e..618b7d5 100755 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -19,11 +19,20 @@ config ARCH_OMAP34XX > bool "OMAP34xx Based System" > depends on ARCH_OMAP3 > > +config ARCH_OMAP36XX > + bool "OMAP36xx Based System" > + depends on ARCH_OMAP3 > + > config ARCH_OMAP3430 > bool "OMAP3430 support" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select ARCH_OMAP_OTG > > +config ARCH_OMAP3630 > + bool "OMAP3630 support" > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX > + select ARCH_OMAP_OTG > + > comment "OMAP Board Type" > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > > @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP > bool "OMAP 3430 SDP board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > +config MACH_OMAP_3630SDP > + bool "OMAP 3630 SDP board" > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > + > config MACH_NOKIA_N8X0 > bool "Nokia N800/N810" > depends on ARCH_OMAP2420 > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > omap/include/mach/cpu.h > index 7a5f9e8..73c656c 100755 > --- a/arch/arm/plat-omap/include/mach/cpu.h > +++ b/arch/arm/plat-omap/include/mach/cpu.h > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > IS_OMAP_CLASS(16xx, 0x16) > IS_OMAP_CLASS(24xx, 0x24) > IS_OMAP_CLASS(34xx, 0x34) > +IS_OMAP_CLASS(36xx, 0x36) OMAP3630 is "just" an OMAP3430 in disguise. I don't think it deserves a new class. It should probably be handled like it was done for 1610 and 1710. Theoretically, it should be considered as a 3430 ES4.0, because it is an OMAP3430 ES3 + couple of bug fixes + couple of improvements. I think, that the proposal from Sanjeev to support 35xx (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be leveraged to handle 36xx as well. Regards, Benoit > IS_OMAP_SUBCLASS(242x, 0x242) > IS_OMAP_SUBCLASS(243x, 0x243) > IS_OMAP_SUBCLASS(343x, 0x343) > +IS_OMAP_SUBCLASS(363x, 0x363) > > #define cpu_is_omap7xx() 0 > #define cpu_is_omap15xx() 0 > @@ -170,6 +172,8 @@ IS_OMAP_SUBCLASS(343x, 0x343) > #define cpu_is_omap243x() 0 > #define cpu_is_omap34xx() 0 > #define cpu_is_omap343x() 0 > +#define cpu_is_omap36xx() 0 > +#define cpu_is_omap363x() 0 > #define cpu_is_omap44xx() 0 > #define cpu_is_omap443x() 0 > > @@ -245,6 +249,14 @@ IS_OMAP_SUBCLASS(343x, 0x343) > # undef cpu_is_omap343x > # define cpu_is_omap343x() 1 > # endif > +# if defined(CONFIG_ARCH_OMAP36XX) > +# undef cpu_is_omap36xx > +# define cpu_is_omap36xx() 1 > +# endif > +# if defined(CONFIG_ARCH_OMAP3630) > +# undef cpu_is_omap363x > +# define cpu_is_omap363x() 1 > +# endif > #endif > > /* > @@ -287,6 +299,7 @@ IS_OMAP_TYPE(2422, 0x2422) > IS_OMAP_TYPE(2423, 0x2423) > IS_OMAP_TYPE(2430, 0x2430) > IS_OMAP_TYPE(3430, 0x3430) > +IS_OMAP_TYPE(3630, 0x3630) > > #define cpu_is_omap310() 0 > #define cpu_is_omap730() 0 > @@ -302,6 +315,7 @@ IS_OMAP_TYPE(3430, 0x3430) > #define cpu_is_omap2423() 0 > #define cpu_is_omap2430() 0 > #define cpu_is_omap3430() 0 > +#define cpu_is_omap3630() 0 > > /* > * Whether we have MULTI_OMAP1 or not, we still need to distinguish > @@ -354,6 +368,11 @@ IS_OMAP_TYPE(3430, 0x3430) > # define cpu_is_omap3430() is_omap3430() > #endif > > +#if defined(CONFIG_ARCH_OMAP36XX) > +# undef cpu_is_omap3630 > +# define cpu_is_omap3630() 1 > +#endif > + > # if defined(CONFIG_ARCH_OMAP4) > # undef cpu_is_omap44xx > # undef cpu_is_omap443x > @@ -365,7 +384,7 @@ IS_OMAP_TYPE(3430, 0x3430) > #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ > cpu_is_omap16xx()) > #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ > - cpu_is_omap44xx()) > + cpu_is_omap36xx || cpu_is_omap44xx()) > > /* Various silicon revisions for omap2 */ > #define OMAP242X_CLASS 0x24200024 > @@ -382,6 +401,9 @@ IS_OMAP_TYPE(3430, 0x3430) > #define OMAP3430_REV_ES3_0 0x34303034 > #define OMAP3430_REV_ES3_1 0x34304034 > > +#define OMAP363X_CLASS 0x36300036 > +#define OMAP3630_REV_ES1_0 0x36300036 > + > #define OMAP443X_CLASS 0x44300034 > > /* > @@ -406,6 +428,12 @@ IS_OMAP_TYPE(3430, 0x3430) > #define CHIP_IS_OMAP3430ES3_0 (1 << 5) > #define CHIP_IS_OMAP3430ES3_1 (1 << 6) > > +/* OMAP 3630 CHIP is backword compatible to 3430 > + * 3630 ES1 IS compatible with 3430 ES2 */ > + > +#define CHIP_IS_OMAP3630 (1 << 2) > +#define CHIP_IS_OMAP3630ES1 (1 << 4) > + > #define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430) > > /* > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Allen, > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > +config MACH_OMAP_3630SDP > + bool "OMAP 3630 SDP board" > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > + > config MACH_NOKIA_N8X0 > bool "Nokia N800/N810" > depends on ARCH_OMAP2420 > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > omap/include/mach/cpu.h > index 7a5f9e8..73c656c 100755 > --- a/arch/arm/plat-omap/include/mach/cpu.h > +++ b/arch/arm/plat-omap/include/mach/cpu.h > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > IS_OMAP_CLASS(16xx, 0x16) > IS_OMAP_CLASS(24xx, 0x24) > IS_OMAP_CLASS(34xx, 0x34) > +IS_OMAP_CLASS(36xx, 0x36) ############################### OMAP3630 is "just" an OMAP3430 in disguise. I don't think it deserves a new class. It should probably be handled like it was done for 1610 and 1710. Theoretically, it should be considered as a 3430 ES4.0, because it is an OMAP3430 ES3 + couple of bug fixes + couple of improvements. I think, that the proposal from Sanjeev to support 35xx (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be leveraged to handle 36xx as well. ############################### I too second Benoit point here. A single runtime macro like "cpu_is_omap36xx()" should be good enough to add additional code for 3630. May be we can keep all 3430 switches by default enabled for 3630 and wherever necessary additional 3630 specific code can be added using the runtime switch like " cpu_is_omap36xx()". Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>-----Original Message----- >From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of >Cousson, Benoit >Sent: Sunday, September 20, 2009 10:08 AM >To: Pais, Allen; linux-omap@vger.kernel.org >Cc: Raju, Veeramanikandan; Bongale, Hariprasad >Subject: RE: [PATCH][RFC] OMAP3630: Create architecture macros and config entries. > >Hi Allen, > >> -----Original Message----- >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- >> owner@vger.kernel.org] On Behalf Of Pais, Allen >> Sent: Sunday, September 20, 2009 9:47 AM >> To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, Hariprasad >> Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config >> entries. >> >> >> This patch creates the architectural macros for OMAP3630. >> >> Signed-off-by: Allen Pais <allen.pais@ti.com> >> >> arch/arm/mach-omap2/Kconfig | 13 ++ >> arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- >> >> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig >> index 75b1c7e..618b7d5 100755 >> --- a/arch/arm/mach-omap2/Kconfig >> +++ b/arch/arm/mach-omap2/Kconfig >> @@ -19,11 +19,20 @@ config ARCH_OMAP34XX >> bool "OMAP34xx Based System" >> depends on ARCH_OMAP3 >> >> +config ARCH_OMAP36XX >> + bool "OMAP36xx Based System" >> + depends on ARCH_OMAP3 >> + >> config ARCH_OMAP3430 >> bool "OMAP3430 support" >> depends on ARCH_OMAP3 && ARCH_OMAP34XX >> select ARCH_OMAP_OTG >> >> +config ARCH_OMAP3630 >> + bool "OMAP3630 support" >> + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX >> + select ARCH_OMAP_OTG >> + >> comment "OMAP Board Type" >> depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 >> >> @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP >> bool "OMAP 3430 SDP board" >> depends on ARCH_OMAP3 && ARCH_OMAP34XX >> >> +config MACH_OMAP_3630SDP >> + bool "OMAP 3630 SDP board" >> + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX >> + >> config MACH_NOKIA_N8X0 >> bool "Nokia N800/N810" >> depends on ARCH_OMAP2420 >> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- >> omap/include/mach/cpu.h >> index 7a5f9e8..73c656c 100755 >> --- a/arch/arm/plat-omap/include/mach/cpu.h >> +++ b/arch/arm/plat-omap/include/mach/cpu.h >> @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) >> IS_OMAP_CLASS(16xx, 0x16) >> IS_OMAP_CLASS(24xx, 0x24) >> IS_OMAP_CLASS(34xx, 0x34) >> +IS_OMAP_CLASS(36xx, 0x36) > >OMAP3630 is "just" an OMAP3430 in disguise. >I don't think it deserves a new class. It should probably be handled like it was done for 1610 and >1710. > >Theoretically, it should be considered as a 3430 ES4.0, because it is an OMAP3430 ES3 + couple of bug >fixes + couple of improvements. > >I think, that the proposal from Sanjeev to support 35xx (http://marc.info/?l=linux- >omap&m=125050987112798&w=2 ) might be leveraged to handle 36xx as well. How would we handle the various ES revs for 3630? > >Regards, >Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > owner@vger.kernel.org] On Behalf Of Cousson, Benoit > Sent: Sunday, September 20, 2009 10:08 AM > To: Pais, Allen; linux-omap@vger.kernel.org > Cc: Raju, Veeramanikandan; Bongale, Hariprasad > Subject: RE: [PATCH][RFC] OMAP3630: Create architecture macros and config > entries. > > Hi Allen, > > > -----Original Message----- > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > owner@vger.kernel.org] On Behalf Of Pais, Allen > > Sent: Sunday, September 20, 2009 9:47 AM > > To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, > Hariprasad > > Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config > > entries. > > > > > > This patch creates the architectural macros for OMAP3630. > > > > Signed-off-by: Allen Pais <allen.pais@ti.com> > > > > arch/arm/mach-omap2/Kconfig | 13 ++ > > arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- > > > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > > index 75b1c7e..618b7d5 100755 > > --- a/arch/arm/mach-omap2/Kconfig > > +++ b/arch/arm/mach-omap2/Kconfig > > @@ -19,11 +19,20 @@ config ARCH_OMAP34XX > > bool "OMAP34xx Based System" > > depends on ARCH_OMAP3 > > > > +config ARCH_OMAP36XX > > + bool "OMAP36xx Based System" > > + depends on ARCH_OMAP3 > > + > > config ARCH_OMAP3430 > > bool "OMAP3430 support" > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > select ARCH_OMAP_OTG > > > > +config ARCH_OMAP3630 > > + bool "OMAP3630 support" > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX > > + select ARCH_OMAP_OTG > > + > > comment "OMAP Board Type" > > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > > > > @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP > > bool "OMAP 3430 SDP board" > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > > > +config MACH_OMAP_3630SDP > > + bool "OMAP 3630 SDP board" > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > > + > > config MACH_NOKIA_N8X0 > > bool "Nokia N800/N810" > > depends on ARCH_OMAP2420 > > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > > omap/include/mach/cpu.h > > index 7a5f9e8..73c656c 100755 > > --- a/arch/arm/plat-omap/include/mach/cpu.h > > +++ b/arch/arm/plat-omap/include/mach/cpu.h > > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > > IS_OMAP_CLASS(16xx, 0x16) > > IS_OMAP_CLASS(24xx, 0x24) > > IS_OMAP_CLASS(34xx, 0x34) > > +IS_OMAP_CLASS(36xx, 0x36) > > OMAP3630 is "just" an OMAP3430 in disguise. > I don't think it deserves a new class. It should probably be handled like > it was done for 1610 and 1710. > > Theoretically, it should be considered as a 3430 ES4.0, because it is an > OMAP3430 ES3 + couple of bug fixes + couple of improvements. > > I think, that the proposal from Sanjeev to support 35xx > (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be leveraged > to handle 36xx as well. > I respectfully tend to disagree with this, since there are some components inside the chip that aren't specifically fixes, so IMHO they need to start from scratch about silicon revisions because of that. If there are many common points between 34xx/35xx/36xx, then rename the reused functions/defines to omap3, instead of omap34xx/omap35xx/omap36xx. Regards, Sergio > Regards, > Benoit > > > IS_OMAP_SUBCLASS(242x, 0x242) > > IS_OMAP_SUBCLASS(243x, 0x243) > > IS_OMAP_SUBCLASS(343x, 0x343) > > +IS_OMAP_SUBCLASS(363x, 0x363) > > > > #define cpu_is_omap7xx() 0 > > #define cpu_is_omap15xx() 0 > > @@ -170,6 +172,8 @@ IS_OMAP_SUBCLASS(343x, 0x343) > > #define cpu_is_omap243x() 0 > > #define cpu_is_omap34xx() 0 > > #define cpu_is_omap343x() 0 > > +#define cpu_is_omap36xx() 0 > > +#define cpu_is_omap363x() 0 > > #define cpu_is_omap44xx() 0 > > #define cpu_is_omap443x() 0 > > > > @@ -245,6 +249,14 @@ IS_OMAP_SUBCLASS(343x, 0x343) > > # undef cpu_is_omap343x > > # define cpu_is_omap343x() 1 > > # endif > > +# if defined(CONFIG_ARCH_OMAP36XX) > > +# undef cpu_is_omap36xx > > +# define cpu_is_omap36xx() 1 > > +# endif > > +# if defined(CONFIG_ARCH_OMAP3630) > > +# undef cpu_is_omap363x > > +# define cpu_is_omap363x() 1 > > +# endif > > #endif > > > > /* > > @@ -287,6 +299,7 @@ IS_OMAP_TYPE(2422, 0x2422) > > IS_OMAP_TYPE(2423, 0x2423) > > IS_OMAP_TYPE(2430, 0x2430) > > IS_OMAP_TYPE(3430, 0x3430) > > +IS_OMAP_TYPE(3630, 0x3630) > > > > #define cpu_is_omap310() 0 > > #define cpu_is_omap730() 0 > > @@ -302,6 +315,7 @@ IS_OMAP_TYPE(3430, 0x3430) > > #define cpu_is_omap2423() 0 > > #define cpu_is_omap2430() 0 > > #define cpu_is_omap3430() 0 > > +#define cpu_is_omap3630() 0 > > > > /* > > * Whether we have MULTI_OMAP1 or not, we still need to distinguish > > @@ -354,6 +368,11 @@ IS_OMAP_TYPE(3430, 0x3430) > > # define cpu_is_omap3430() is_omap3430() > > #endif > > > > +#if defined(CONFIG_ARCH_OMAP36XX) > > +# undef cpu_is_omap3630 > > +# define cpu_is_omap3630() 1 > > +#endif > > + > > # if defined(CONFIG_ARCH_OMAP4) > > # undef cpu_is_omap44xx > > # undef cpu_is_omap443x > > @@ -365,7 +384,7 @@ IS_OMAP_TYPE(3430, 0x3430) > > #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() > || \ > > cpu_is_omap16xx()) > > #define cpu_class_is_omap2() (cpu_is_omap24xx() || > cpu_is_omap34xx() || \ > > - cpu_is_omap44xx()) > > + cpu_is_omap36xx || cpu_is_omap44xx()) > > > > /* Various silicon revisions for omap2 */ > > #define OMAP242X_CLASS 0x24200024 > > @@ -382,6 +401,9 @@ IS_OMAP_TYPE(3430, 0x3430) > > #define OMAP3430_REV_ES3_0 0x34303034 > > #define OMAP3430_REV_ES3_1 0x34304034 > > > > +#define OMAP363X_CLASS 0x36300036 > > +#define OMAP3630_REV_ES1_0 0x36300036 > > + > > #define OMAP443X_CLASS 0x44300034 > > > > /* > > @@ -406,6 +428,12 @@ IS_OMAP_TYPE(3430, 0x3430) > > #define CHIP_IS_OMAP3430ES3_0 (1 << 5) > > #define CHIP_IS_OMAP3430ES3_1 (1 << 6) > > > > +/* OMAP 3630 CHIP is backword compatible to 3430 > > + * 3630 ES1 IS compatible with 3430 ES2 */ > > + > > +#define CHIP_IS_OMAP3630 (1 << 2) > > +#define CHIP_IS_OMAP3630ES1 (1 << 4) > > + > > #define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430) > > > > /* > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > Hi Allen, > > > > > -----Original Message----- > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > > owner@vger.kernel.org] On Behalf Of Pais, Allen > > > Sent: Sunday, September 20, 2009 9:47 AM > > > To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, > > Hariprasad > > > Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config > > > entries. > > > > > > > > > This patch creates the architectural macros for OMAP3630. > > > > > > Signed-off-by: Allen Pais <allen.pais@ti.com> > > > > > > arch/arm/mach-omap2/Kconfig | 13 ++ > > > arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- > > > > > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > > > index 75b1c7e..618b7d5 100755 > > > --- a/arch/arm/mach-omap2/Kconfig > > > +++ b/arch/arm/mach-omap2/Kconfig > > > @@ -19,11 +19,20 @@ config ARCH_OMAP34XX > > > bool "OMAP34xx Based System" > > > depends on ARCH_OMAP3 > > > > > > +config ARCH_OMAP36XX > > > + bool "OMAP36xx Based System" > > > + depends on ARCH_OMAP3 > > > + > > > config ARCH_OMAP3430 > > > bool "OMAP3430 support" > > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > > select ARCH_OMAP_OTG > > > > > > +config ARCH_OMAP3630 > > > + bool "OMAP3630 support" > > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX > > > + select ARCH_OMAP_OTG > > > + > > > comment "OMAP Board Type" > > > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > > > > > > @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP > > > bool "OMAP 3430 SDP board" > > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > > > > > +config MACH_OMAP_3630SDP > > > + bool "OMAP 3630 SDP board" > > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > > > + > > > config MACH_NOKIA_N8X0 > > > bool "Nokia N800/N810" > > > depends on ARCH_OMAP2420 > > > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > > > omap/include/mach/cpu.h > > > index 7a5f9e8..73c656c 100755 > > > --- a/arch/arm/plat-omap/include/mach/cpu.h > > > +++ b/arch/arm/plat-omap/include/mach/cpu.h > > > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > > > IS_OMAP_CLASS(16xx, 0x16) > > > IS_OMAP_CLASS(24xx, 0x24) > > > IS_OMAP_CLASS(34xx, 0x34) > > > +IS_OMAP_CLASS(36xx, 0x36) > > > > OMAP3630 is "just" an OMAP3430 in disguise. > > I don't think it deserves a new class. It should probably be handled like > > it was done for 1610 and 1710. > > > > Theoretically, it should be considered as a 3430 ES4.0, because it is an > > OMAP3430 ES3 + couple of bug fixes + couple of improvements. > > > > I think, that the proposal from Sanjeev to support 35xx > > (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be leveraged > > to handle 36xx as well. > > > > I respectfully tend to disagree with this, since there are some components > inside the chip that aren't specifically fixes, so IMHO they need to start > from scratch about silicon revisions because of that. > > If there are many common points between 34xx/35xx/36xx, then rename the > reused functions/defines to omap3, instead of omap34xx/omap35xx/omap36xx. > > Regards, > Sergio > I agree with Sergio. While it is definitely possible to write code treating the 3430 and the 3630 as the same, they are not the same animal. We will need to distinguish between the two at more than a few locations in code, and we might as well add the ability to do that now. I see a need to distinguish between 3430 and 3630 in several locations - there are changes in hardware IPs that are not reflected in the IP revision information (meaning we cannot always go by CPU_HAS_FEATURE() ), and we will need some kind of a cpu_is_* check for sure. Regards, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Allen, Some comments inlined below: > -----Original Message----- > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > owner@vger.kernel.org] On Behalf Of Pais, Allen > Sent: Sunday, September 20, 2009 2:47 AM > To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, Hariprasad > Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config > entries. > > > This patch creates the architectural macros for OMAP3630. > > Signed-off-by: Allen Pais <allen.pais@ti.com> > > arch/arm/mach-omap2/Kconfig | 13 ++ > arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 75b1c7e..618b7d5 100755 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -19,11 +19,20 @@ config ARCH_OMAP34XX > bool "OMAP34xx Based System" > depends on ARCH_OMAP3 > > +config ARCH_OMAP36XX > + bool "OMAP36xx Based System" > + depends on ARCH_OMAP3 > + > config ARCH_OMAP3430 > bool "OMAP3430 support" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > select ARCH_OMAP_OTG > > +config ARCH_OMAP3630 > + bool "OMAP3630 support" > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX Why not: depends on ARCH_OMAP3 && ARCH_OMAP36XX ? IMHO, the 36XX support shouldn't depend on 34XX. > + select ARCH_OMAP_OTG > + > comment "OMAP Board Type" > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > > @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP > bool "OMAP 3430 SDP board" > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > +config MACH_OMAP_3630SDP > + bool "OMAP 3630 SDP board" > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > + > config MACH_NOKIA_N8X0 > bool "Nokia N800/N810" > depends on ARCH_OMAP2420 > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > omap/include/mach/cpu.h > index 7a5f9e8..73c656c 100755 > --- a/arch/arm/plat-omap/include/mach/cpu.h > +++ b/arch/arm/plat-omap/include/mach/cpu.h > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > IS_OMAP_CLASS(16xx, 0x16) > IS_OMAP_CLASS(24xx, 0x24) > IS_OMAP_CLASS(34xx, 0x34) > +IS_OMAP_CLASS(36xx, 0x36) > > IS_OMAP_SUBCLASS(242x, 0x242) > IS_OMAP_SUBCLASS(243x, 0x243) > IS_OMAP_SUBCLASS(343x, 0x343) > +IS_OMAP_SUBCLASS(363x, 0x363) > > #define cpu_is_omap7xx() 0 > #define cpu_is_omap15xx() 0 > @@ -170,6 +172,8 @@ IS_OMAP_SUBCLASS(343x, 0x343) > #define cpu_is_omap243x() 0 > #define cpu_is_omap34xx() 0 > #define cpu_is_omap343x() 0 > +#define cpu_is_omap36xx() 0 > +#define cpu_is_omap363x() 0 > #define cpu_is_omap44xx() 0 > #define cpu_is_omap443x() 0 > > @@ -245,6 +249,14 @@ IS_OMAP_SUBCLASS(343x, 0x343) > # undef cpu_is_omap343x > # define cpu_is_omap343x() 1 > # endif > +# if defined(CONFIG_ARCH_OMAP36XX) > +# undef cpu_is_omap36xx > +# define cpu_is_omap36xx() 1 > +# endif > +# if defined(CONFIG_ARCH_OMAP3630) > +# undef cpu_is_omap363x > +# define cpu_is_omap363x() 1 > +# endif > #endif > > /* > @@ -287,6 +299,7 @@ IS_OMAP_TYPE(2422, 0x2422) > IS_OMAP_TYPE(2423, 0x2423) > IS_OMAP_TYPE(2430, 0x2430) > IS_OMAP_TYPE(3430, 0x3430) > +IS_OMAP_TYPE(3630, 0x3630) > > #define cpu_is_omap310() 0 > #define cpu_is_omap730() 0 > @@ -302,6 +315,7 @@ IS_OMAP_TYPE(3430, 0x3430) > #define cpu_is_omap2423() 0 > #define cpu_is_omap2430() 0 > #define cpu_is_omap3430() 0 > +#define cpu_is_omap3630() 0 > > /* > * Whether we have MULTI_OMAP1 or not, we still need to distinguish > @@ -354,6 +368,11 @@ IS_OMAP_TYPE(3430, 0x3430) > # define cpu_is_omap3430() is_omap3430() > #endif > > +#if defined(CONFIG_ARCH_OMAP36XX) > +# undef cpu_is_omap3630 > +# define cpu_is_omap3630() 1 > +#endif > + > # if defined(CONFIG_ARCH_OMAP4) > # undef cpu_is_omap44xx > # undef cpu_is_omap443x > @@ -365,7 +384,7 @@ IS_OMAP_TYPE(3430, 0x3430) > #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ > cpu_is_omap16xx()) > #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ > - cpu_is_omap44xx()) > + cpu_is_omap36xx || cpu_is_omap44xx()) > > /* Various silicon revisions for omap2 */ > #define OMAP242X_CLASS 0x24200024 > @@ -382,6 +401,9 @@ IS_OMAP_TYPE(3430, 0x3430) > #define OMAP3430_REV_ES3_0 0x34303034 > #define OMAP3430_REV_ES3_1 0x34304034 > > +#define OMAP363X_CLASS 0x36300036 > +#define OMAP3630_REV_ES1_0 0x36300036 > + > #define OMAP443X_CLASS 0x44300034 > > /* > @@ -406,6 +428,12 @@ IS_OMAP_TYPE(3430, 0x3430) > #define CHIP_IS_OMAP3430ES3_0 (1 << 5) > #define CHIP_IS_OMAP3430ES3_1 (1 << 6) > > +/* OMAP 3630 CHIP is backword compatible to 3430 > + * 3630 ES1 IS compatible with 3430 ES2 */ I think its enough to say: /* OMAP 3630 ES1 chip is backwards compatible with 3430 ES2 */ That's all the comments I have. Regards, Sergio > + > +#define CHIP_IS_OMAP3630 (1 << 2) > +#define CHIP_IS_OMAP3630ES1 (1 << 4) > + > #define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430) > > /* > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Sergio, I agree to the point you stated, that 34xx should not depend on 36xx, this would call for code duplication in my opinion. we'll need to add many more files in the mach-omap2/ w.r.t to 36xx. I don't see a approach which could reduce the duplication, any comments on the same would be very helpful to us. Thanks - Allen
Hi Sergio, > -----Original Message----- > From: Aguirre Rodriguez, Sergio Alberto > Sent: Monday, September 21, 2009 8:32 PM > To: Cousson, Benoit; Pais, Allen; linux-omap@vger.kernel.org > Cc: Raju, Veeramanikandan; Bongale, Hariprasad > Subject: RE: [PATCH][RFC] OMAP3630: Create architecture macros and config > entries. > > > > > -----Original Message----- > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > owner@vger.kernel.org] On Behalf Of Cousson, Benoit > > Sent: Sunday, September 20, 2009 10:08 AM > > To: Pais, Allen; linux-omap@vger.kernel.org > > Cc: Raju, Veeramanikandan; Bongale, Hariprasad > > Subject: RE: [PATCH][RFC] OMAP3630: Create architecture macros and > config > > entries. > > > > Hi Allen, > > > > > -----Original Message----- > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > > owner@vger.kernel.org] On Behalf Of Pais, Allen > > > Sent: Sunday, September 20, 2009 9:47 AM > > > To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, > > Hariprasad > > > Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config > > > entries. > > > > > > > > > This patch creates the architectural macros for OMAP3630. > > > > > > Signed-off-by: Allen Pais <allen.pais@ti.com> > > > > > > arch/arm/mach-omap2/Kconfig | 13 ++ > > > arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- > > > > > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > > > index 75b1c7e..618b7d5 100755 > > > --- a/arch/arm/mach-omap2/Kconfig > > > +++ b/arch/arm/mach-omap2/Kconfig > > > @@ -19,11 +19,20 @@ config ARCH_OMAP34XX > > > bool "OMAP34xx Based System" > > > depends on ARCH_OMAP3 > > > > > > +config ARCH_OMAP36XX > > > + bool "OMAP36xx Based System" > > > + depends on ARCH_OMAP3 > > > + > > > config ARCH_OMAP3430 > > > bool "OMAP3430 support" > > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > > select ARCH_OMAP_OTG > > > > > > +config ARCH_OMAP3630 > > > + bool "OMAP3630 support" > > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX > > > + select ARCH_OMAP_OTG > > > + > > > comment "OMAP Board Type" > > > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > > > > > > @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP > > > bool "OMAP 3430 SDP board" > > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > > > > > +config MACH_OMAP_3630SDP > > > + bool "OMAP 3630 SDP board" > > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > > > + > > > config MACH_NOKIA_N8X0 > > > bool "Nokia N800/N810" > > > depends on ARCH_OMAP2420 > > > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > > > omap/include/mach/cpu.h > > > index 7a5f9e8..73c656c 100755 > > > --- a/arch/arm/plat-omap/include/mach/cpu.h > > > +++ b/arch/arm/plat-omap/include/mach/cpu.h > > > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > > > IS_OMAP_CLASS(16xx, 0x16) > > > IS_OMAP_CLASS(24xx, 0x24) > > > IS_OMAP_CLASS(34xx, 0x34) > > > +IS_OMAP_CLASS(36xx, 0x36) > > > > OMAP3630 is "just" an OMAP3430 in disguise. > > I don't think it deserves a new class. It should probably be handled > like > > it was done for 1610 and 1710. > > > > Theoretically, it should be considered as a 3430 ES4.0, because it is an > > OMAP3430 ES3 + couple of bug fixes + couple of improvements. > > > > I think, that the proposal from Sanjeev to support 35xx > > (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be > leveraged > > to handle 36xx as well. > > > > I respectfully tend to disagree with this, since there are some components > inside the chip that aren't specifically fixes, so IMHO they need to start > from scratch about silicon revisions because of that. Could you be more specific? To what point are you answering? Who are "they"? > If there are many common points between 34xx/35xx/36xx, then rename the > reused functions/defines to omap3, instead of omap34xx/omap35xx/omap36xx. Sure, it is the minimum, but then we still have to handle the differences. Do we use a chip specific function or the feature approach? Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Anand, > -----Original Message----- > From: Gadiyar, Anand > Sent: Monday, September 21, 2009 8:42 PM > To: Aguirre Rodriguez, Sergio Alberto; Cousson, Benoit; Pais, Allen; > linux-omap@vger.kernel.org > Cc: Raju, Veeramanikandan; Bongale, Hariprasad > Subject: RE: [PATCH][RFC] OMAP3630: Create architecture macros and config > entries. > > > > > > > Hi Allen, > > > > > > > -----Original Message----- > > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > > > owner@vger.kernel.org] On Behalf Of Pais, Allen > > > > Sent: Sunday, September 20, 2009 9:47 AM > > > > To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, > > > Hariprasad > > > > Subject: [PATCH][RFC] OMAP3630: Create architecture macros and > config > > > > entries. > > > > > > > > > > > > This patch creates the architectural macros for OMAP3630. > > > > > > > > Signed-off-by: Allen Pais <allen.pais@ti.com> > > > > > > > > arch/arm/mach-omap2/Kconfig | 13 ++ > > > > arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- > > > > > > > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach- > omap2/Kconfig > > > > index 75b1c7e..618b7d5 100755 > > > > --- a/arch/arm/mach-omap2/Kconfig > > > > +++ b/arch/arm/mach-omap2/Kconfig > > > > @@ -19,11 +19,20 @@ config ARCH_OMAP34XX > > > > bool "OMAP34xx Based System" > > > > depends on ARCH_OMAP3 > > > > > > > > +config ARCH_OMAP36XX > > > > + bool "OMAP36xx Based System" > > > > + depends on ARCH_OMAP3 > > > > + > > > > config ARCH_OMAP3430 > > > > bool "OMAP3430 support" > > > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > > > select ARCH_OMAP_OTG > > > > > > > > +config ARCH_OMAP3630 > > > > + bool "OMAP3630 support" > > > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX > > > > + select ARCH_OMAP_OTG > > > > + > > > > comment "OMAP Board Type" > > > > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > > > > > > > > @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP > > > > bool "OMAP 3430 SDP board" > > > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > > > > > > > > +config MACH_OMAP_3630SDP > > > > + bool "OMAP 3630 SDP board" > > > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > > > > + > > > > config MACH_NOKIA_N8X0 > > > > bool "Nokia N800/N810" > > > > depends on ARCH_OMAP2420 > > > > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > > > > omap/include/mach/cpu.h > > > > index 7a5f9e8..73c656c 100755 > > > > --- a/arch/arm/plat-omap/include/mach/cpu.h > > > > +++ b/arch/arm/plat-omap/include/mach/cpu.h > > > > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > > > > IS_OMAP_CLASS(16xx, 0x16) > > > > IS_OMAP_CLASS(24xx, 0x24) > > > > IS_OMAP_CLASS(34xx, 0x34) > > > > +IS_OMAP_CLASS(36xx, 0x36) > > > > > > OMAP3630 is "just" an OMAP3430 in disguise. > > > I don't think it deserves a new class. It should probably be handled > like > > > it was done for 1610 and 1710. > > > > > > Theoretically, it should be considered as a 3430 ES4.0, because it is > an > > > OMAP3430 ES3 + couple of bug fixes + couple of improvements. > > > > > > I think, that the proposal from Sanjeev to support 35xx > > > (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be > leveraged > > > to handle 36xx as well. > > > > > > > I respectfully tend to disagree with this, since there are some > components > > inside the chip that aren't specifically fixes, so IMHO they need to > start > > from scratch about silicon revisions because of that. > > > > If there are many common points between 34xx/35xx/36xx, then rename the > > reused functions/defines to omap3, instead of > omap34xx/omap35xx/omap36xx. > > > > Regards, > > Sergio > > > > I agree with Sergio. > > While it is definitely possible to write code treating the 3430 > and the 3630 as the same, they are not the same animal. We will > need to distinguish between the two at more than a few locations > in code, and we might as well add the ability to do that now. I agree, I didn't say anything different. > I see a need to distinguish between 3430 and 3630 in several locations > - there are changes in hardware IPs that are not reflected in the IP > revision information (meaning we cannot always go by CPU_HAS_FEATURE() ), > and we will need some kind of a cpu_is_* check for sure. Then it is pretty bad... Do you have an explicit list of such IPs? Maybe even in that case it might be useful to still use a CPU_HAS_FEATURE, but use the chip version to detect the feature version. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Pandita, Vikram > Sent: Monday, September 21, 2009 11:47 PM > To: Cousson, Benoit; Pais, Allen; linux-omap@vger.kernel.org > Subject: RE: [PATCH][RFC] OMAP3630: Create architecture > macros and config entries. > > > > >-----Original Message----- > >From: linux-omap-owner@vger.kernel.org > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of > >Cousson, Benoit > >Sent: Sunday, September 20, 2009 10:08 AM > >To: Pais, Allen; linux-omap@vger.kernel.org > >Cc: Raju, Veeramanikandan; Bongale, Hariprasad > >Subject: RE: [PATCH][RFC] OMAP3630: Create architecture > macros and config entries. > > > >Hi Allen, > > > >> -----Original Message----- > >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > >> owner@vger.kernel.org] On Behalf Of Pais, Allen > >> Sent: Sunday, September 20, 2009 9:47 AM > >> To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; > Bongale, Hariprasad > >> Subject: [PATCH][RFC] OMAP3630: Create architecture macros > and config > >> entries. > >> > >> > >> This patch creates the architectural macros for OMAP3630. > >> > >> Signed-off-by: Allen Pais <allen.pais@ti.com> > >> > >> arch/arm/mach-omap2/Kconfig | 13 ++ > >> arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- > >> > >> diff --git a/arch/arm/mach-omap2/Kconfig > b/arch/arm/mach-omap2/Kconfig > >> index 75b1c7e..618b7d5 100755 > >> --- a/arch/arm/mach-omap2/Kconfig > >> +++ b/arch/arm/mach-omap2/Kconfig > >> @@ -19,11 +19,20 @@ config ARCH_OMAP34XX > >> bool "OMAP34xx Based System" > >> depends on ARCH_OMAP3 > >> > >> +config ARCH_OMAP36XX > >> + bool "OMAP36xx Based System" > >> + depends on ARCH_OMAP3 > >> + > >> config ARCH_OMAP3430 > >> bool "OMAP3430 support" > >> depends on ARCH_OMAP3 && ARCH_OMAP34XX > >> select ARCH_OMAP_OTG > >> > >> +config ARCH_OMAP3630 > >> + bool "OMAP3630 support" > >> + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX > >> + select ARCH_OMAP_OTG > >> + > >> comment "OMAP Board Type" > >> depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > >> > >> @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP > >> bool "OMAP 3430 SDP board" > >> depends on ARCH_OMAP3 && ARCH_OMAP34XX > >> > >> +config MACH_OMAP_3630SDP > >> + bool "OMAP 3630 SDP board" > >> + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > >> + > >> config MACH_NOKIA_N8X0 > >> bool "Nokia N800/N810" > >> depends on ARCH_OMAP2420 > >> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > >> omap/include/mach/cpu.h > >> index 7a5f9e8..73c656c 100755 > >> --- a/arch/arm/plat-omap/include/mach/cpu.h > >> +++ b/arch/arm/plat-omap/include/mach/cpu.h > >> @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > >> IS_OMAP_CLASS(16xx, 0x16) > >> IS_OMAP_CLASS(24xx, 0x24) > >> IS_OMAP_CLASS(34xx, 0x34) > >> +IS_OMAP_CLASS(36xx, 0x36) > > > >OMAP3630 is "just" an OMAP3430 in disguise. > >I don't think it deserves a new class. It should probably be > handled like it was done for 1610 and > >1710. > > > >Theoretically, it should be considered as a 3430 ES4.0, > because it is an OMAP3430 ES3 + couple of bug > >fixes + couple of improvements. > > > >I think, that the proposal from Sanjeev to support 35xx > (http://marc.info/?l=linux- > >omap&m=125050987112798&w=2 ) might be leveraged to handle > 36xx as well. > > > How would we handle the various ES revs for 3630? > [sp] The si rev should be treated standalone independent of the actual si. See thread: http://marc.info/?t=125197476300001&r=1&w=2 Best regards, Sanjeev > > > >Regards, > >Benoit > -- > To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Gadiyar, Anand > Sent: Tuesday, September 22, 2009 12:12 AM > To: Aguirre Rodriguez, Sergio Alberto; Cousson, Benoit; Pais, > Allen; linux-omap@vger.kernel.org > Cc: Raju, Veeramanikandan; Bongale, Hariprasad > Subject: RE: [PATCH][RFC] OMAP3630: Create architecture > macros and config entries. > snip -- snip --- snip > > > > I respectfully tend to disagree with this, since there are > some components > > inside the chip that aren't specifically fixes, so IMHO > they need to start > > from scratch about silicon revisions because of that. > > > > If there are many common points between 34xx/35xx/36xx, > then rename the > > reused functions/defines to omap3, instead of > omap34xx/omap35xx/omap36xx. [sp] We had same discussion in context of OMAP3517. And the Where the IPs and features etc have been more than just fixes. I will be submitting a patch later today; that will illustrate that cpu_is_xxx() changes are usually limited. > > > > Regards, > > Sergio > > > > I agree with Sergio. > > While it is definitely possible to write code treating the 3430 > and the 3630 as the same, they are not the same animal. We will > need to distinguish between the two at more than a few locations > in code, and we might as well add the ability to do that now. > > I see a need to distinguish between 3430 and 3630 in several locations > - there are changes in hardware IPs that are not reflected in the IP > revision information (meaning we cannot always go by > CPU_HAS_FEATURE() ), > and we will need some kind of a cpu_is_* check for sure. [sp] See my response above. Also, we seem to be at a juncture where may seemlingly similar but Different silicons are coming up. I believe it is the *best* time to come up with a framework where the IP/feature based checks can be Streamlined. Best regards, Sanjeev > > Regards, > Anand > -- > To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"Gadiyar, Anand" <gadiyar@ti.com> writes: >> > >> > Hi Allen, >> > >> > > -----Original Message----- >> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- >> > > owner@vger.kernel.org] On Behalf Of Pais, Allen >> > > Sent: Sunday, September 20, 2009 9:47 AM >> > > To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, >> > Hariprasad >> > > Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config >> > > entries. >> > > >> > > >> > > This patch creates the architectural macros for OMAP3630. >> > > >> > > Signed-off-by: Allen Pais <allen.pais@ti.com> >> > > >> > > arch/arm/mach-omap2/Kconfig | 13 ++ >> > > arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- >> > > >> > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig >> > > index 75b1c7e..618b7d5 100755 >> > > --- a/arch/arm/mach-omap2/Kconfig >> > > +++ b/arch/arm/mach-omap2/Kconfig >> > > @@ -19,11 +19,20 @@ config ARCH_OMAP34XX >> > > bool "OMAP34xx Based System" >> > > depends on ARCH_OMAP3 >> > > >> > > +config ARCH_OMAP36XX >> > > + bool "OMAP36xx Based System" >> > > + depends on ARCH_OMAP3 >> > > + >> > > config ARCH_OMAP3430 >> > > bool "OMAP3430 support" >> > > depends on ARCH_OMAP3 && ARCH_OMAP34XX >> > > select ARCH_OMAP_OTG >> > > >> > > +config ARCH_OMAP3630 >> > > + bool "OMAP3630 support" >> > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX >> > > + select ARCH_OMAP_OTG >> > > + >> > > comment "OMAP Board Type" >> > > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 >> > > >> > > @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP >> > > bool "OMAP 3430 SDP board" >> > > depends on ARCH_OMAP3 && ARCH_OMAP34XX >> > > >> > > +config MACH_OMAP_3630SDP >> > > + bool "OMAP 3630 SDP board" >> > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX >> > > + >> > > config MACH_NOKIA_N8X0 >> > > bool "Nokia N800/N810" >> > > depends on ARCH_OMAP2420 >> > > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- >> > > omap/include/mach/cpu.h >> > > index 7a5f9e8..73c656c 100755 >> > > --- a/arch/arm/plat-omap/include/mach/cpu.h >> > > +++ b/arch/arm/plat-omap/include/mach/cpu.h >> > > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) >> > > IS_OMAP_CLASS(16xx, 0x16) >> > > IS_OMAP_CLASS(24xx, 0x24) >> > > IS_OMAP_CLASS(34xx, 0x34) >> > > +IS_OMAP_CLASS(36xx, 0x36) >> > >> > OMAP3630 is "just" an OMAP3430 in disguise. >> > I don't think it deserves a new class. It should probably be handled like >> > it was done for 1610 and 1710. >> > >> > Theoretically, it should be considered as a 3430 ES4.0, because it is an >> > OMAP3430 ES3 + couple of bug fixes + couple of improvements. >> > >> > I think, that the proposal from Sanjeev to support 35xx >> > (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be leveraged >> > to handle 36xx as well. >> > >> >> I respectfully tend to disagree with this, since there are some components >> inside the chip that aren't specifically fixes, so IMHO they need to start >> from scratch about silicon revisions because of that. >> >> If there are many common points between 34xx/35xx/36xx, then rename the >> reused functions/defines to omap3, instead of omap34xx/omap35xx/omap36xx. >> >> Regards, >> Sergio >> > > I agree with Sergio. > > While it is definitely possible to write code treating the 3430 > and the 3630 as the same, they are not the same animal. We will > need to distinguish between the two at more than a few locations > in code, and we might as well add the ability to do that now. > > I see a need to distinguish between 3430 and 3630 in several locations > - there are changes in hardware IPs that are not reflected in the IP > revision information (meaning we cannot always go by CPU_HAS_FEATURE() ), > and we will need some kind of a cpu_is_* check for sure. And you're sure these HW IP changes require software changes? Please provide examples. So, TI is changing HW IP in a way that requires software changes and not providing a way for software to detect these changes? IMHO, This is completely broken HW design. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Kevin Hilman <khilman@deeprootsystems.com> [090922 08:12]: > "Gadiyar, Anand" <gadiyar@ti.com> writes: > > >> > > >> > Hi Allen, > >> > > >> > > -----Original Message----- > >> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > >> > > owner@vger.kernel.org] On Behalf Of Pais, Allen > >> > > Sent: Sunday, September 20, 2009 9:47 AM > >> > > To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, > >> > Hariprasad > >> > > Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config > >> > > entries. > >> > > > >> > > > >> > > This patch creates the architectural macros for OMAP3630. > >> > > > >> > > Signed-off-by: Allen Pais <allen.pais@ti.com> > >> > > > >> > > arch/arm/mach-omap2/Kconfig | 13 ++ > >> > > arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- > >> > > > >> > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > >> > > index 75b1c7e..618b7d5 100755 > >> > > --- a/arch/arm/mach-omap2/Kconfig > >> > > +++ b/arch/arm/mach-omap2/Kconfig > >> > > @@ -19,11 +19,20 @@ config ARCH_OMAP34XX > >> > > bool "OMAP34xx Based System" > >> > > depends on ARCH_OMAP3 > >> > > > >> > > +config ARCH_OMAP36XX > >> > > + bool "OMAP36xx Based System" > >> > > + depends on ARCH_OMAP3 > >> > > + > >> > > config ARCH_OMAP3430 > >> > > bool "OMAP3430 support" > >> > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > >> > > select ARCH_OMAP_OTG > >> > > > >> > > +config ARCH_OMAP3630 > >> > > + bool "OMAP3630 support" > >> > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX > >> > > + select ARCH_OMAP_OTG > >> > > + > >> > > comment "OMAP Board Type" > >> > > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > >> > > > >> > > @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP > >> > > bool "OMAP 3430 SDP board" > >> > > depends on ARCH_OMAP3 && ARCH_OMAP34XX > >> > > > >> > > +config MACH_OMAP_3630SDP > >> > > + bool "OMAP 3630 SDP board" > >> > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX > >> > > + > >> > > config MACH_NOKIA_N8X0 > >> > > bool "Nokia N800/N810" > >> > > depends on ARCH_OMAP2420 > >> > > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > >> > > omap/include/mach/cpu.h > >> > > index 7a5f9e8..73c656c 100755 > >> > > --- a/arch/arm/plat-omap/include/mach/cpu.h > >> > > +++ b/arch/arm/plat-omap/include/mach/cpu.h > >> > > @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) > >> > > IS_OMAP_CLASS(16xx, 0x16) > >> > > IS_OMAP_CLASS(24xx, 0x24) > >> > > IS_OMAP_CLASS(34xx, 0x34) > >> > > +IS_OMAP_CLASS(36xx, 0x36) > >> > > >> > OMAP3630 is "just" an OMAP3430 in disguise. > >> > I don't think it deserves a new class. It should probably be handled like > >> > it was done for 1610 and 1710. > >> > > >> > Theoretically, it should be considered as a 3430 ES4.0, because it is an > >> > OMAP3430 ES3 + couple of bug fixes + couple of improvements. > >> > > >> > I think, that the proposal from Sanjeev to support 35xx > >> > (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be leveraged > >> > to handle 36xx as well. > >> > > >> > >> I respectfully tend to disagree with this, since there are some components > >> inside the chip that aren't specifically fixes, so IMHO they need to start > >> from scratch about silicon revisions because of that. > >> > >> If there are many common points between 34xx/35xx/36xx, then rename the > >> reused functions/defines to omap3, instead of omap34xx/omap35xx/omap36xx. > >> > >> Regards, > >> Sergio > >> > > > > I agree with Sergio. > > > > While it is definitely possible to write code treating the 3430 > > and the 3630 as the same, they are not the same animal. We will > > need to distinguish between the two at more than a few locations > > in code, and we might as well add the ability to do that now. > > > > I see a need to distinguish between 3430 and 3630 in several locations > > - there are changes in hardware IPs that are not reflected in the IP > > revision information (meaning we cannot always go by CPU_HAS_FEATURE() ), > > and we will need some kind of a cpu_is_* check for sure. > > And you're sure these HW IP changes require software changes? Please > provide examples. > > So, TI is changing HW IP in a way that requires software changes and > not providing a way for software to detect these changes? > > IMHO, This is completely broken HW design. I agree, we should be able to detect various processors during the init and then just set the necessary feature flags. Please provide clear cases why we should treat 3630 as a separate chip from 3430. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Premi, Sanjeev > Sent: Tuesday, September 22, 2009 5:18 PM > To: Gadiyar, Anand; Aguirre Rodriguez, Sergio Alberto; > Cousson, Benoit; Pais, Allen; linux-omap@vger.kernel.org > Cc: Raju, Veeramanikandan; Bongale, Hariprasad > Subject: RE: [PATCH][RFC] OMAP3630: Create architecture > macros and config entries. > > > > > -----Original Message----- > > From: linux-omap-owner@vger.kernel.org > > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of > Gadiyar, Anand > > Sent: Tuesday, September 22, 2009 12:12 AM > > To: Aguirre Rodriguez, Sergio Alberto; Cousson, Benoit; Pais, > > Allen; linux-omap@vger.kernel.org > > Cc: Raju, Veeramanikandan; Bongale, Hariprasad > > Subject: RE: [PATCH][RFC] OMAP3630: Create architecture > > macros and config entries. > > > > snip -- snip --- snip > > > > > > > I respectfully tend to disagree with this, since there are > > some components > > > inside the chip that aren't specifically fixes, so IMHO > > they need to start > > > from scratch about silicon revisions because of that. > > > > > > If there are many common points between 34xx/35xx/36xx, > > then rename the > > > reused functions/defines to omap3, instead of > > omap34xx/omap35xx/omap36xx. > > [sp] We had same discussion in context of OMAP3517. And the > Where the IPs and features etc have been more than just > fixes. > > I will be submitting a patch later today; that will > illustrate that cpu_is_xxx() changes are usually limited. [sp] Do take a look at the patch-set I just submitted: Common mechanism to identify Si revision ~sanjeev > > > > > > Regards, > > > Sergio > > > > > > > I agree with Sergio. > > > > While it is definitely possible to write code treating the 3430 > > and the 3630 as the same, they are not the same animal. We will > > need to distinguish between the two at more than a few locations > > in code, and we might as well add the ability to do that now. > > > > I see a need to distinguish between 3430 and 3630 in > several locations > > - there are changes in hardware IPs that are not reflected in the IP > > revision information (meaning we cannot always go by > > CPU_HAS_FEATURE() ), > > and we will need some kind of a cpu_is_* check for sure. > > [sp] See my response above. > > Also, we seem to be at a juncture where may seemlingly similar but > Different silicons are coming up. I believe it is the *best* time to > come up with a framework where the IP/feature based checks can be > Streamlined. > > Best regards, > Sanjeev > > > > > Regards, > > Anand > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-omap" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >> > OMAP3630 is "just" an OMAP3430 in disguise. > > >> > I don't think it deserves a new class. It should probably be handled like > > >> > it was done for 1610 and 1710. > > >> > > > >> > Theoretically, it should be considered as a 3430 ES4.0, because it is an > > >> > OMAP3430 ES3 + couple of bug fixes + couple of improvements. > > >> > > > >> > I think, that the proposal from Sanjeev to support 35xx > > >> > (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be leveraged > > >> > to handle 36xx as well. > > >> > > > >> > > >> I respectfully tend to disagree with this, since there are some components > > >> inside the chip that aren't specifically fixes, so IMHO they need to start > > >> from scratch about silicon revisions because of that. > > >> > > >> If there are many common points between 34xx/35xx/36xx, then rename the > > >> reused functions/defines to omap3, instead of omap34xx/omap35xx/omap36xx. > > >> > > >> Regards, > > >> Sergio > > >> > > > > > > I agree with Sergio. > > > > > > While it is definitely possible to write code treating the 3430 > > > and the 3630 as the same, they are not the same animal. We will > > > need to distinguish between the two at more than a few locations > > > in code, and we might as well add the ability to do that now. > > > > > > I see a need to distinguish between 3430 and 3630 in several locations > > > - there are changes in hardware IPs that are not reflected in the IP > > > revision information (meaning we cannot always go by CPU_HAS_FEATURE() ), > > > and we will need some kind of a cpu_is_* check for sure. > > > > And you're sure these HW IP changes require software changes? Please > > provide examples. Yes, I'm pretty sure some of them require software changes. No examples on the 3630 that I can disclose right now, but consider for instance the case of the TLL Save-and-Restore feature on 3430 - it's broken on ES3.0 and below and works great after. Or extra register bits in UHH_HOSTCONFIG introduced in ES3.0. The HW IP versions are still the same across these revisions, but the SOC ES version has changed. > > > > So, TI is changing HW IP in a way that requires software changes and > > not providing a way for software to detect these changes? > > > > IMHO, This is completely broken HW design. Agreed. I've already pinged some HW design folks to point this out. > > I agree, we should be able to detect various processors during the > init and then just set the necessary feature flags. I seem not to have understood the initially proposed solution when I made that comment. Consider the objection withdrawn. I agree - all we require is the ability to detect the chip version at init, and to set any flag that might be needed by code executing later. It is a better solution. I misunderstood the discussion to mean "the 3630 would not be detectable as a separate chip from the 3430 at all". It doesn't really matter where we make the distinction, as long as it is possible to add code to behave differently on the two chips (or other revisions of the OMAP3). Regards, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 75b1c7e..618b7d5 100755 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -19,11 +19,20 @@ config ARCH_OMAP34XX bool "OMAP34xx Based System" depends on ARCH_OMAP3 +config ARCH_OMAP36XX + bool "OMAP36xx Based System" + depends on ARCH_OMAP3 + config ARCH_OMAP3430 bool "OMAP3430 support" depends on ARCH_OMAP3 && ARCH_OMAP34XX select ARCH_OMAP_OTG +config ARCH_OMAP3630 + bool "OMAP3630 support" + depends on ARCH_OMAP3 && ARCH_OMAP34XX && ARCH_OMAP36XX + select ARCH_OMAP_OTG + comment "OMAP Board Type" depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP bool "OMAP 3430 SDP board" depends on ARCH_OMAP3 && ARCH_OMAP34XX +config MACH_OMAP_3630SDP + bool "OMAP 3630 SDP board" + depends on ARCH_OMAP3 && ARCH_OMAP34XX & ARCH_OMAP36XX + config MACH_NOKIA_N8X0 bool "Nokia N800/N810" depends on ARCH_OMAP2420 diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 7a5f9e8..73c656c 100755 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) IS_OMAP_CLASS(16xx, 0x16) IS_OMAP_CLASS(24xx, 0x24) IS_OMAP_CLASS(34xx, 0x34) +IS_OMAP_CLASS(36xx, 0x36) IS_OMAP_SUBCLASS(242x, 0x242) IS_OMAP_SUBCLASS(243x, 0x243) IS_OMAP_SUBCLASS(343x, 0x343) +IS_OMAP_SUBCLASS(363x, 0x363) #define cpu_is_omap7xx() 0 #define cpu_is_omap15xx() 0 @@ -170,6 +172,8 @@ IS_OMAP_SUBCLASS(343x, 0x343) #define cpu_is_omap243x() 0 #define cpu_is_omap34xx() 0 #define cpu_is_omap343x() 0 +#define cpu_is_omap36xx() 0 +#define cpu_is_omap363x() 0 #define cpu_is_omap44xx() 0 #define cpu_is_omap443x() 0 @@ -245,6 +249,14 @@ IS_OMAP_SUBCLASS(343x, 0x343) # undef cpu_is_omap343x # define cpu_is_omap343x() 1 # endif +# if defined(CONFIG_ARCH_OMAP36XX) +# undef cpu_is_omap36xx +# define cpu_is_omap36xx() 1 +# endif +# if defined(CONFIG_ARCH_OMAP3630) +# undef cpu_is_omap363x +# define cpu_is_omap363x() 1 +# endif #endif /* @@ -287,6 +299,7 @@ IS_OMAP_TYPE(2422, 0x2422) IS_OMAP_TYPE(2423, 0x2423) IS_OMAP_TYPE(2430, 0x2430) IS_OMAP_TYPE(3430, 0x3430) +IS_OMAP_TYPE(3630, 0x3630) #define cpu_is_omap310() 0 #define cpu_is_omap730() 0 @@ -302,6 +315,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 #define cpu_is_omap3430() 0 +#define cpu_is_omap3630() 0 /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish @@ -354,6 +368,11 @@ IS_OMAP_TYPE(3430, 0x3430) # define cpu_is_omap3430() is_omap3430() #endif +#if defined(CONFIG_ARCH_OMAP36XX) +# undef cpu_is_omap3630 +# define cpu_is_omap3630() 1 +#endif + # if defined(CONFIG_ARCH_OMAP4) # undef cpu_is_omap44xx # undef cpu_is_omap443x @@ -365,7 +384,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx()) + cpu_is_omap36xx || cpu_is_omap44xx()) /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS 0x24200024 @@ -382,6 +401,9 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP3430_REV_ES3_0 0x34303034 #define OMAP3430_REV_ES3_1 0x34304034 +#define OMAP363X_CLASS 0x36300036 +#define OMAP3630_REV_ES1_0 0x36300036 + #define OMAP443X_CLASS 0x44300034 /* @@ -406,6 +428,12 @@ IS_OMAP_TYPE(3430, 0x3430) #define CHIP_IS_OMAP3430ES3_0 (1 << 5) #define CHIP_IS_OMAP3430ES3_1 (1 << 6) +/* OMAP 3630 CHIP is backword compatible to 3430 + * 3630 ES1 IS compatible with 3430 ES2 */ + +#define CHIP_IS_OMAP3630 (1 << 2) +#define CHIP_IS_OMAP3630ES1 (1 << 4) + #define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430) /*
This patch creates the architectural macros for OMAP3630. Signed-off-by: Allen Pais <allen.pais@ti.com> arch/arm/mach-omap2/Kconfig | 13 ++ arch/arm/plat-omap/include/mach/cpu.h | 30 +++++- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html