[RFC][PATCH] OMAP3: introduce OMAP3630

[RFC][PATCH] OMAP3: introduce OMAP3630

[Nishanth Menon]

Device intro:
OMAP3630 is the latest in the family of OMAP3 devices
and among the changes it introduces are:

New OPP levels for new voltage and frequency levels. a bunch of
Bug fixes to various modules feature additions, notably with ISP,
sDMA etc.

Details about the chip is available here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12836&contentId=52606

Strategy used:
Strategy to introduce this device into Linux was discussed here:
Ref: http://marc.info/?t=125343303400003&r=1&w=2

Two approaches were available:
a) Consider 3630 generation of devices as a new family of silicon
b) Consider 3630 as an offshoot of 3430 family of devices

As a common consensus, (b) seems to be more valid for 3630 as:
* There are changes which are easily handled by looking at rev
* Most of existing 34xx infrastructure can be reused(almost 90%+)
	- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
	  all over the place
	- lesser chance of bugs due to reuse of proven code flow
	- 36xx specific handling can still be done where required
	  within the existing infrastructure

NOTE:
* If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
  added on top of the existing 3630 ones are renumbered

This patch was tested on SDP3430.

Signed-off-by: Madhusudhan Chikkature Rajashekar <madhu.cr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Cc: Allen Pais <allen.pais@ti.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Sergio Alberto Aguirre Rodriguez <saaguirre@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/id.c              |   33 ++++++++++++++++++++++++++++++---
 arch/arm/plat-omap/include/mach/cpu.h |    6 ++++++
 2 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 03b80f2..79193c6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
 {
 	u32 cpuid, idcode;
 	u16 hawkeye;
+	u16 omap_type;
 	u8 rev;
 	char *rev_name = "ES1.0";
 
@@ -210,7 +211,10 @@ void __init omap3_check_revision(void)
 	hawkeye = (idcode >> 12) & 0xffff;
 	rev = (idcode >> 28) & 0xff;
 
-	if (hawkeye == 0xb7ae) {
+	omap_type = omap_rev() >> 16;
+	switch (hawkeye) {
+	case 0xb7ae:
+		/* Handle 34xx devices */
 		switch (rev) {
 		case 0:
 			omap_revision = OMAP3430_REV_ES2_0;
@@ -231,12 +235,35 @@ void __init omap3_check_revision(void)
 		default:
 			/* Use the latest known revision as default */
 			omap_revision = OMAP3430_REV_ES3_1;
-			rev_name = "Unknown revision\n";
+			rev_name = "Unknown 34xx revision\n";
+			/* Fall through */
 		}
+		break;
+	case 0xb891:
+		/* Handle 36xx devices */
+		/* Over ride for display purposes */
+		omap_type = 0x3630;
+		switch (rev) {
+		case 0:
+			omap_revision = OMAP3630_REV_ES1_0;
+			rev_name = "ES1.0";
+			break;
+		default:
+			/* Use the latest known revision as default */
+			omap_revision = OMAP3630_REV_ES1_0;
+			rev_name = "Unknown 36xx revision\n";
+			/* Fall through */
+		}
+		break;
+	default:
+		/* Unknown default to latest rev as default*/
+		omap_revision = OMAP3630_REV_ES1_0;
+		rev_name = "Unknown revision\n";
+		/* Fall through */
 	}
 
 out:
-	pr_info("OMAP%04x %s\n", omap_rev() >> 16, rev_name);
+	pr_info("OMAP%04x %s\n", omap_type, rev_name);
 }
 
 #define OMAP3_SHOW_FEATURE(feat)		\
diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h
index 431fec4..af1080f 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
 #define OMAP3430_REV_ES2_1	0x34302034
 #define OMAP3430_REV_ES3_0	0x34303034
 #define OMAP3430_REV_ES3_1	0x34304034
+/* NOTE: Add 36xx series below
+ * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
+ * added above the 3630 defines and series renumbered to ensure
+ * rev() > checks to work
+ */
+#define OMAP3630_REV_ES1_0	0x34305034
 
 #define OMAP443X_CLASS		0x44300034
 
-- 
1.6.0.4

Re: [RFC][PATCH] OMAP3: introduce OMAP3630

[Felipe Balbi]

Hi,

On Thu, Oct 08, 2009 at 06:47:03AM +0200, ext Nishanth Menon wrote:
> Device intro:
> OMAP3630 is the latest in the family of OMAP3 devices
> and among the changes it introduces are:
> 
> New OPP levels for new voltage and frequency levels. a bunch of
> Bug fixes to various modules feature additions, notably with ISP,
> sDMA etc.
> 
> Details about the chip is available here:
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12836&contentId=52606
> 
> Strategy used:
> Strategy to introduce this device into Linux was discussed here:
> Ref: http://marc.info/?t=125343303400003&r=1&w=2
> 
> Two approaches were available:
> a) Consider 3630 generation of devices as a new family of silicon
> b) Consider 3630 as an offshoot of 3430 family of devices
> 
> As a common consensus, (b) seems to be more valid for 3630 as:
> * There are changes which are easily handled by looking at rev
> * Most of existing 34xx infrastructure can be reused(almost 90%+)
> 	- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
> 	  all over the place
> 	- lesser chance of bugs due to reuse of proven code flow
> 	- 36xx specific handling can still be done where required
> 	  within the existing infrastructure
> 
> NOTE:
> * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
>   added on top of the existing 3630 ones are renumbered
> 
> This patch was tested on SDP3430.

no test on 3630 boards ?

> Signed-off-by: Madhusudhan Chikkature Rajashekar <madhu.cr@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
> Cc: Allen Pais <allen.pais@ti.com>
> Cc: Anand Gadiyar <gadiyar@ti.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Sanjeev Premi <premi@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Sergio Alberto Aguirre Rodriguez <saaguirre@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/mach-omap2/id.c              |   33 ++++++++++++++++++++++++++++++---
>  arch/arm/plat-omap/include/mach/cpu.h |    6 ++++++
>  2 files changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 03b80f2..79193c6 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
>  {
>  	u32 cpuid, idcode;
>  	u16 hawkeye;
> +	u16 omap_type;
>  	u8 rev;
>  	char *rev_name = "ES1.0";
>  
> @@ -210,7 +211,10 @@ void __init omap3_check_revision(void)
>  	hawkeye = (idcode >> 12) & 0xffff;
>  	rev = (idcode >> 28) & 0xff;
>  
> -	if (hawkeye == 0xb7ae) {
> +	omap_type = omap_rev() >> 16;
> +	switch (hawkeye) {
> +	case 0xb7ae:
> +		/* Handle 34xx devices */
>  		switch (rev) {
>  		case 0:
>  			omap_revision = OMAP3430_REV_ES2_0;
> @@ -231,12 +235,35 @@ void __init omap3_check_revision(void)
>  		default:
>  			/* Use the latest known revision as default */
>  			omap_revision = OMAP3430_REV_ES3_1;
> -			rev_name = "Unknown revision\n";
> +			rev_name = "Unknown 34xx revision\n";
> +			/* Fall through */

there's a break right below, you don't really fall through...

>  		}
> +		break;
> +	case 0xb891:
> +		/* Handle 36xx devices */
> +		/* Over ride for display purposes */

multi-lined comment style is:

/* line 1
 * line 2
 * .
 * .
 * .
 * line N
 */

> +		omap_type = 0x3630;
> +		switch (rev) {
> +		case 0:
> +			omap_revision = OMAP3630_REV_ES1_0;
> +			rev_name = "ES1.0";
> +			break;
> +		default:
> +			/* Use the latest known revision as default */
> +			omap_revision = OMAP3630_REV_ES1_0;
> +			rev_name = "Unknown 36xx revision\n";
> +			/* Fall through */

don't fall through.

> +		}
> +		break;
> +	default:
> +		/* Unknown default to latest rev as default*/
> +		omap_revision = OMAP3630_REV_ES1_0;
> +		rev_name = "Unknown revision\n";
> +		/* Fall through */

unnecessary comment.

-- 
balbi

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Shilimkar, Santosh]

> -----Original Message-----
> From: Menon, Nishanth
> Sent: Thursday, October 08, 2009 10:17 AM
> To: linux-omap
> Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan; Pandita, Vikram;
> Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi,
> Sanjeev; Shilimkar, Santosh; Aguirre Rodriguez, Sergio Alberto; Tony
> Lindgren
> Subject: [RFC][PATCH] OMAP3: introduce OMAP3630
> 
> Device intro:
> OMAP3630 is the latest in the family of OMAP3 devices
> and among the changes it introduces are:
> 
> New OPP levels for new voltage and frequency levels. a bunch of
> Bug fixes to various modules feature additions, notably with ISP,
> sDMA etc.
> 
> Details about the chip is available here:
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=61
> 23&navigationId=12836&contentId=52606
> 
> Strategy used:
> Strategy to introduce this device into Linux was discussed here:
> Ref: http://marc.info/?t=125343303400003&r=1&w=2
> 
> Two approaches were available:
> a) Consider 3630 generation of devices as a new family of silicon
> b) Consider 3630 as an offshoot of 3430 family of devices
> 
> As a common consensus, (b) seems to be more valid for 3630 as:
> * There are changes which are easily handled by looking at rev
> * Most of existing 34xx infrastructure can be reused(almost 90%+)
> 	- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
> 	  all over the place
> 	- lesser chance of bugs due to reuse of proven code flow
> 	- 36xx specific handling can still be done where required
> 	  within the existing infrastructure
> 
> NOTE:
> * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
>   added on top of the existing 3630 ones are renumbered
> 
> This patch was tested on SDP3430.
> 
> Signed-off-by: Madhusudhan Chikkature Rajashekar <madhu.cr@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
> Cc: Allen Pais <allen.pais@ti.com>
> Cc: Anand Gadiyar <gadiyar@ti.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Sanjeev Premi <premi@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Sergio Alberto Aguirre Rodriguez <saaguirre@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/mach-omap2/id.c              |   33
> ++++++++++++++++++++++++++++++---
>  arch/arm/plat-omap/include/mach/cpu.h |    6 ++++++
>  2 files changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 03b80f2..79193c6 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
>  {
>  	u32 cpuid, idcode;
>  	u16 hawkeye;
> +	u16 omap_type;
>  	u8 rev;
>  	char *rev_name = "ES1.0";
> 
> @@ -210,7 +211,10 @@ void __init omap3_check_revision(void)
>  	hawkeye = (idcode >> 12) & 0xffff;
>  	rev = (idcode >> 28) & 0xff;
> 
> -	if (hawkeye == 0xb7ae) {
> +	omap_type = omap_rev() >> 16;
> +	switch (hawkeye) {
> +	case 0xb7ae:
> +		/* Handle 34xx devices */
>  		switch (rev) {
>  		case 0:
>  			omap_revision = OMAP3430_REV_ES2_0;
> @@ -231,12 +235,35 @@ void __init omap3_check_revision(void)
>  		default:
>  			/* Use the latest known revision as default */
>  			omap_revision = OMAP3430_REV_ES3_1;
> -			rev_name = "Unknown revision\n";
> +			rev_name = "Unknown 34xx revision\n";
> +			/* Fall through */
>  		}
> +		break;
> +	case 0xb891:
> +		/* Handle 36xx devices */
> +		/* Over ride for display purposes */
> +		omap_type = 0x3630;
> +		switch (rev) {
> +		case 0:
> +			omap_revision = OMAP3630_REV_ES1_0;
> +			rev_name = "ES1.0";
> +			break;
> +		default:
> +			/* Use the latest known revision as default */
> +			omap_revision = OMAP3630_REV_ES1_0;
> +			rev_name = "Unknown 36xx revision\n";
> +			/* Fall through */
> +		}
> +		break;
> +	default:
> +		/* Unknown default to latest rev as default*/
> +		omap_revision = OMAP3630_REV_ES1_0;
> +		rev_name = "Unknown revision\n";
> +		/* Fall through */
>  	}
> 
>  out:
> -	pr_info("OMAP%04x %s\n", omap_rev() >> 16, rev_name);
> +	pr_info("OMAP%04x %s\n", omap_type, rev_name);
>  }
> 
>  #define OMAP3_SHOW_FEATURE(feat)		\
> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
> omap/include/mach/cpu.h
> index 431fec4..af1080f 100644
> --- a/arch/arm/plat-omap/include/mach/cpu.h
> +++ b/arch/arm/plat-omap/include/mach/cpu.h
> @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
>  #define OMAP3430_REV_ES2_1	0x34302034
>  #define OMAP3430_REV_ES3_0	0x34303034
>  #define OMAP3430_REV_ES3_1	0x34304034
> +/* NOTE: Add 36xx series below
> + * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
> + * added above the 3630 defines and series renumbered to ensure
> + * rev() > checks to work
> + */
> +#define OMAP3630_REV_ES1_0	0x34305034
> 
>  #define OMAP443X_CLASS		0x44300034
Was expecting that this patch will add "cpu_is_omap36xx()" in cpu.h 
apart from above. Is this handled in another patch ?


Regards,
Santosh

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Pandita, Vikram]

>-----Original Message-----
>From: Shilimkar, Santosh
>>
>> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
>> omap/include/mach/cpu.h
>> index 431fec4..af1080f 100644
>> --- a/arch/arm/plat-omap/include/mach/cpu.h
>> +++ b/arch/arm/plat-omap/include/mach/cpu.h
>> @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
>>  #define OMAP3430_REV_ES2_1	0x34302034
>>  #define OMAP3430_REV_ES3_0	0x34303034
>>  #define OMAP3430_REV_ES3_1	0x34304034
>> +/* NOTE: Add 36xx series below
>> + * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
>> + * added above the 3630 defines and series renumbered to ensure
>> + * rev() > checks to work
>> + */
>> +#define OMAP3630_REV_ES1_0	0x34305034
>>
>>  #define OMAP443X_CLASS		0x44300034
>Was expecting that this patch will add "cpu_is_omap36xx()" in cpu.h
>apart from above. Is this handled in another patch ?

Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference.
Hence at run time, the check could be:

if (omap_rev() == OMAP3630_REV_ES1_0)
	xxxxx

cpu_is_omap34xx() will be true for 36xx as well.

>
>
>Regards,
>Santosh

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Premi, Sanjeev]

> -----Original Message-----
> From: Pandita, Vikram 
> Sent: Thursday, October 08, 2009 7:01 PM
> To: Shilimkar, Santosh; Menon, Nishanth; linux-omap
> Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, 
> Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre 
> Rodriguez, Sergio Alberto; Tony Lindgren
> Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630
> 
> 
> 
> >-----Original Message-----
> >From: Shilimkar, Santosh
> >>
> >> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
> >> omap/include/mach/cpu.h
> >> index 431fec4..af1080f 100644
> >> --- a/arch/arm/plat-omap/include/mach/cpu.h
> >> +++ b/arch/arm/plat-omap/include/mach/cpu.h
> >> @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
> >>  #define OMAP3430_REV_ES2_1	0x34302034
> >>  #define OMAP3430_REV_ES3_0	0x34303034
> >>  #define OMAP3430_REV_ES3_1	0x34304034
> >> +/* NOTE: Add 36xx series below
> >> + * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
> >> + * added above the 3630 defines and series renumbered to ensure
> >> + * rev() > checks to work
> >> + */
> >> +#define OMAP3630_REV_ES1_0	0x34305034
> >>
> >>  #define OMAP443X_CLASS		0x44300034
> >Was expecting that this patch will add "cpu_is_omap36xx()" in cpu.h
> >apart from above. Is this handled in another patch ?
> 
> Idea is to re-use all 34xx code for 36xx, as per the mail 
> thread on list, and given in reference.
> Hence at run time, the check could be:
> 
> if (omap_rev() == OMAP3630_REV_ES1_0)
> 	xxxxx
> 
> cpu_is_omap34xx() will be true for 36xx as well.

[sp] This case seems quite similar to the OMAP35x.
     Can you look at this thread:

     http://marc.info/?l=linux-omap&m=125372581804902&w=2

     It applies equally well here as well...
     I will be submitting updated patch tomorrow.

Best regards,
Sanjeev

> 
> >
> >
> >Regards,
> >Santosh
> 

Re: [RFC][PATCH] OMAP3: introduce OMAP3630

[Nishanth Menon]

Premi, Sanjeev had written, on 10/08/2009 09:23 AM, the following:
>> -----Original Message-----
>> From: Pandita, Vikram 
>> Sent: Thursday, October 08, 2009 7:01 PM
>> To: Shilimkar, Santosh; Menon, Nishanth; linux-omap
>> Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, 
>> Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre 
>> Rodriguez, Sergio Alberto; Tony Lindgren
>> Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630
>>
>>
>>
>>> -----Original Message-----
>>> From: Shilimkar, Santosh
>>>> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
>>>> omap/include/mach/cpu.h
>>>> index 431fec4..af1080f 100644
>>>> --- a/arch/arm/plat-omap/include/mach/cpu.h
>>>> +++ b/arch/arm/plat-omap/include/mach/cpu.h
>>>> @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
>>>>  #define OMAP3430_REV_ES2_1	0x34302034
>>>>  #define OMAP3430_REV_ES3_0	0x34303034
>>>>  #define OMAP3430_REV_ES3_1	0x34304034
>>>> +/* NOTE: Add 36xx series below
>>>> + * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
>>>> + * added above the 3630 defines and series renumbered to ensure
>>>> + * rev() > checks to work
>>>> + */
>>>> +#define OMAP3630_REV_ES1_0	0x34305034
>>>>
>>>>  #define OMAP443X_CLASS		0x44300034
>>> Was expecting that this patch will add "cpu_is_omap36xx()" in cpu.h
>>> apart from above. Is this handled in another patch ?
>> Idea is to re-use all 34xx code for 36xx, as per the mail 
>> thread on list, and given in reference.
>> Hence at run time, the check could be:
>>
>> if (omap_rev() == OMAP3630_REV_ES1_0)
>> 	xxxxx
>>
>> cpu_is_omap34xx() will be true for 36xx as well.
> 
> [sp] This case seems quite similar to the OMAP35x.
>      Can you look at this thread:
> 
>      http://marc.info/?l=linux-omap&m=125372581804902&w=2
> 
>      It applies equally well here as well...
>      I will be submitting updated patch tomorrow.
yes, any specifics should be  feature based IMHO. we will need to extend 
the feature list.

-- 
Regards,
Nishanth Menon

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Pais, Allen]

Nishanth,

 Would there be CONFIG_ARCH_OMAP3630?

- Allen

________________________________________
From: Menon, Nishanth
Sent: Thursday, October 08, 2009 9:40 AM
To: Premi, Sanjeev
Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630

Premi, Sanjeev had written, on 10/08/2009 09:23 AM, the following:
>> -----Original Message-----
>> From: Pandita, Vikram
>> Sent: Thursday, October 08, 2009 7:01 PM
>> To: Shilimkar, Santosh; Menon, Nishanth; linux-omap
>> Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar,
>> Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre
>> Rodriguez, Sergio Alberto; Tony Lindgren
>> Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630
>>
>>
>>
>>> -----Original Message-----
>>> From: Shilimkar, Santosh
>>>> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
>>>> omap/include/mach/cpu.h
>>>> index 431fec4..af1080f 100644
>>>> --- a/arch/arm/plat-omap/include/mach/cpu.h
>>>> +++ b/arch/arm/plat-omap/include/mach/cpu.h
>>>> @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
>>>>  #define OMAP3430_REV_ES2_1        0x34302034
>>>>  #define OMAP3430_REV_ES3_0        0x34303034
>>>>  #define OMAP3430_REV_ES3_1        0x34304034
>>>> +/* NOTE: Add 36xx series below
>>>> + * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
>>>> + * added above the 3630 defines and series renumbered to ensure
>>>> + * rev() > checks to work
>>>> + */
>>>> +#define OMAP3630_REV_ES1_0        0x34305034
>>>>
>>>>  #define OMAP443X_CLASS            0x44300034
>>> Was expecting that this patch will add "cpu_is_omap36xx()" in cpu.h
>>> apart from above. Is this handled in another patch ?
>> Idea is to re-use all 34xx code for 36xx, as per the mail
>> thread on list, and given in reference.
>> Hence at run time, the check could be:
>>
>> if (omap_rev() == OMAP3630_REV_ES1_0)
>>      xxxxx
>>
>> cpu_is_omap34xx() will be true for 36xx as well.
>
> [sp] This case seems quite similar to the OMAP35x.
>      Can you look at this thread:
>
>      http://marc.info/?l=linux-omap&m=125372581804902&w=2
>
>      It applies equally well here as well...
>      I will be submitting updated patch tomorrow.
yes, any specifics should be  feature based IMHO. we will need to extend
the feature list.

--
Regards,
Nishanth Menon

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Menon, Nishanth]

> -----Original Message-----
> From: Pais, Allen
> Sent: Thursday, October 08, 2009 10:04 AM
> To: Menon, Nishanth; Premi, Sanjeev
> 
> Nishanth,
> 
>  Would there be CONFIG_ARCH_OMAP3630?
There is no need for it.
> 
> ________________________________________
> From: Menon, Nishanth
> Sent: Thursday, October 08, 2009 9:40 AM
> To: Premi, Sanjeev
> Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar,
> Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman;
> Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
> Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630

Stop top posting please.

Regards,
Nishanth Menon

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Shilimkar, Santosh]

> -----Original Message-----
> From: Menon, Nishanth
> Sent: Thursday, October 08, 2009 8:11 PM
> To: Premi, Sanjeev
> Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar,
> Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman;
> Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
> Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630
> 
> Premi, Sanjeev had written, on 10/08/2009 09:23 AM, the following:
> >> -----Original Message-----
> >> From: Pandita, Vikram
> >> Sent: Thursday, October 08, 2009 7:01 PM
> >> To: Shilimkar, Santosh; Menon, Nishanth; linux-omap
> >> Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar,
> >> Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre
> >> Rodriguez, Sergio Alberto; Tony Lindgren
> >> Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Shilimkar, Santosh
> >>>> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
> >>>> omap/include/mach/cpu.h
> >>>> index 431fec4..af1080f 100644
> >>>> --- a/arch/arm/plat-omap/include/mach/cpu.h
> >>>> +++ b/arch/arm/plat-omap/include/mach/cpu.h
> >>>> @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
> >>>>  #define OMAP3430_REV_ES2_1	0x34302034
> >>>>  #define OMAP3430_REV_ES3_0	0x34303034
> >>>>  #define OMAP3430_REV_ES3_1	0x34304034
> >>>> +/* NOTE: Add 36xx series below
> >>>> + * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
> >>>> + * added above the 3630 defines and series renumbered to ensure
> >>>> + * rev() > checks to work
> >>>> + */
> >>>> +#define OMAP3630_REV_ES1_0	0x34305034
> >>>>
> >>>>  #define OMAP443X_CLASS		0x44300034
> >>> Was expecting that this patch will add "cpu_is_omap36xx()" in cpu.h
> >>> apart from above. Is this handled in another patch ?
> >> Idea is to re-use all 34xx code for 36xx, as per the mail
> >> thread on list, and given in reference.
> >> Hence at run time, the check could be:
> >>
> >> if (omap_rev() == OMAP3630_REV_ES1_0)
> >> 	xxxxx
> >>
> >> cpu_is_omap34xx() will be true for 36xx as well.
> >
> > [sp] This case seems quite similar to the OMAP35x.
> >      Can you look at this thread:
> >
> >      http://marc.info/?l=linux-omap&m=125372581804902&w=2
> >
> >      It applies equally well here as well...
> >      I will be submitting updated patch tomorrow.
> yes, any specifics should be  feature based IMHO. we will need to extend
> the feature list.

If we are going to handle the delta 3630 changes w.r.t 3430 with feature based approach, its probably is the best thing.

But in case delat code will be added like below then having a cpu_is_omap36xx() makes more sense. 
>> if (omap_rev() == OMAP3630_REV_ES1_0)
> >> 	xxxxx
There is no harm having both cpu_is_omap36xx() and cpu_is_omap34xx() true for 3630
Regards,
Santosh

Re: [RFC][PATCH] OMAP3: introduce OMAP3630

[Nishanth Menon]

Shilimkar, Santosh had written, on 10/08/2009 11:29 PM, the following:
>> -----Original Message-----
>> From: Menon, Nishanth
>> Sent: Thursday, October 08, 2009 8:11 PM
>> To: Premi, Sanjeev
>> Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar,
>> Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman;
>> Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
>> Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630
>>
[...]
>>>>>> +#define OMAP3630_REV_ES1_0	0x34305034
>>>>>>
>>>>>>  #define OMAP443X_CLASS		0x44300034
>>>>> Was expecting that this patch will add "cpu_is_omap36xx()" in cpu.h
>>>>> apart from above. Is this handled in another patch ?
>>>> Idea is to re-use all 34xx code for 36xx, as per the mail
>>>> thread on list, and given in reference.
>>>> Hence at run time, the check could be:
>>>>
>>>> if (omap_rev() == OMAP3630_REV_ES1_0)
>>>> 	xxxxx
>>>>
>>>> cpu_is_omap34xx() will be true for 36xx as well.
>>> [sp] This case seems quite similar to the OMAP35x.
>>>      Can you look at this thread:
>>>
>>>      http://marc.info/?l=linux-omap&m=125372581804902&w=2
>>>
>>>      It applies equally well here as well...
>>>      I will be submitting updated patch tomorrow.
>> yes, any specifics should be  feature based IMHO. we will need to extend
>> the feature list.
> 
> If we are going to handle the delta 3630 changes w.r.t 3430 with feature based approach, its probably is the best thing.
yes. i guess I can take this as an ACK ;)
> 
> But in case delat code will be added like below then having a cpu_is_omap36xx() makes more sense. 
>>> if (omap_rev() == OMAP3630_REV_ES1_0)
>>>> 	xxxxx
> There is no harm having both cpu_is_omap36xx() and cpu_is_omap34xx() true for 3630
what is the need for this? if feature settings can handle the deltas.
give me specific example where this will be needed. if needed, we can 
add this at a later point.

Regards,
Nishanth Menon

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Friday, October 09, 2009 7:40 PM
> Cc: Premi, Sanjeev; Pandita, Vikram; linux-omap; Chikkature Rajashekar,
> Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman;
> Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
> Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630
> 
> Shilimkar, Santosh had written, on 10/08/2009 11:29 PM, the following:
> >> -----Original Message-----
> >> From: Menon, Nishanth
> >> Sent: Thursday, October 08, 2009 8:11 PM
> >> To: Premi, Sanjeev
> >> Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature
> Rajashekar,
> >> Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin
> Hilman;
> >> Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
> >> Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630
> >>
> [...]
> >>>>>> +#define OMAP3630_REV_ES1_0	0x34305034
> >>>>>>
> >>>>>>  #define OMAP443X_CLASS		0x44300034
> >>>>> Was expecting that this patch will add "cpu_is_omap36xx()" in cpu.h
> >>>>> apart from above. Is this handled in another patch ?
> >>>> Idea is to re-use all 34xx code for 36xx, as per the mail
> >>>> thread on list, and given in reference.
> >>>> Hence at run time, the check could be:
> >>>>
> >>>> if (omap_rev() == OMAP3630_REV_ES1_0)
> >>>> 	xxxxx
> >>>>
> >>>> cpu_is_omap34xx() will be true for 36xx as well.
> >>> [sp] This case seems quite similar to the OMAP35x.
> >>>      Can you look at this thread:
> >>>
> >>>      http://marc.info/?l=linux-omap&m=125372581804902&w=2
> >>>
> >>>      It applies equally well here as well...
> >>>      I will be submitting updated patch tomorrow.
> >> yes, any specifics should be  feature based IMHO. we will need to
> extend
> >> the feature list.
> >
> > If we are going to handle the delta 3630 changes w.r.t 3430 with feature
> based approach, its probably is the best thing.
> yes. i guess I can take this as an ACK ;)
> >
> > But in case delat code will be added like below then having a
> cpu_is_omap36xx() makes more sense.
> >>> if (omap_rev() == OMAP3630_REV_ES1_0)
> >>>> 	xxxxx
> > There is no harm having both cpu_is_omap36xx() and cpu_is_omap34xx()
> true for 3630
> what is the need for this? if feature settings can handle the deltas.
> give me specific example where this will be needed. if needed, we can
> add this at a later point.
No need if you follow the feature based approach. 

" But in case delta code will be added like ....... So there was a IF condition :)


Regards,
Santosh

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Aguirre Rodriguez, Sergio Alberto]

Nishanth, 

> -----Original Message-----
> From: Menon, Nishanth 
> Sent: Wednesday, October 07, 2009 11:47 PM
> To: linux-omap
> Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan; 
> Pandita, Vikram; Pais, Allen; Gadiyar, Anand; Cousson, 
> Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar, Santosh; 
> Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
> Subject: [RFC][PATCH] OMAP3: introduce OMAP3630
> 
> Device intro:
> OMAP3630 is the latest in the family of OMAP3 devices
> and among the changes it introduces are:
> 
> New OPP levels for new voltage and frequency levels. a bunch of
> Bug fixes to various modules feature additions, notably with ISP,
> sDMA etc.
> 
> Details about the chip is available here:
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?t
> emplateId=6123&navigationId=12836&contentId=52606
> 
> Strategy used:
> Strategy to introduce this device into Linux was discussed here:
> Ref: http://marc.info/?t=125343303400003&r=1&w=2
> 
> Two approaches were available:
> a) Consider 3630 generation of devices as a new family of silicon
> b) Consider 3630 as an offshoot of 3430 family of devices
> 
> As a common consensus, (b) seems to be more valid for 3630 as:
> * There are changes which are easily handled by looking at rev
> * Most of existing 34xx infrastructure can be reused(almost 90%+)
> 	- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
> 	  all over the place

And how about cpu_is_omap3() ?

That would be valid across 34xx (zoom2, n900), 35xx (beagle, pandora), and 36xx (zoom3).

IMO, returning positive in a 3630/3530 to cpu_is_omap34xx() could make the code
quite unreadable.

1. If you need to do something 34xx specific, then use cpu_is_34xx()
2. If your code is valid for all 34xx, 35xx, 36xx, then why not using cpu_is_omap3() ?

What do you think?

> 	- lesser chance of bugs due to reuse of proven code flow
> 	- 36xx specific handling can still be done where required
> 	  within the existing infrastructure
> 
> NOTE:
> * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
>   added on top of the existing 3630 ones are renumbered
> 
> This patch was tested on SDP3430.

Maybe this should say:

This patch didn't broke SDP3430.

XD

Regards,
Sergio

RE: [RFC][PATCH] OMAP3: introduce OMAP3630

[Menon, Nishanth]

> -----Original Message-----
> From: Aguirre Rodriguez, Sergio Alberto
> Sent: Thursday, October 08, 2009 9:31 AM
> To: Menon, Nishanth; linux-omap
> Cc: Chikkature Rajashekar, Madhusudhan; Pandita, Vikram; Pais, Allen;
> Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar,
> Santosh; Tony Lindgren
> Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630
> 
> Nishanth,
> 
> > -----Original Message-----
> > From: Menon, Nishanth
> > Sent: Wednesday, October 07, 2009 11:47 PM
> > To: linux-omap
> > Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan;
> > Pandita, Vikram; Pais, Allen; Gadiyar, Anand; Cousson,
> > Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar, Santosh;
> > Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
> > Subject: [RFC][PATCH] OMAP3: introduce OMAP3630
> >
> > Device intro:
> > OMAP3630 is the latest in the family of OMAP3 devices
> > and among the changes it introduces are:
> >
> > New OPP levels for new voltage and frequency levels. a bunch of
> > Bug fixes to various modules feature additions, notably with ISP,
> > sDMA etc.
> >
> > Details about the chip is available here:
> > http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?t
> > emplateId=6123&navigationId=12836&contentId=52606
> >
> > Strategy used:
> > Strategy to introduce this device into Linux was discussed here:
> > Ref: http://marc.info/?t=125343303400003&r=1&w=2
> >
> > Two approaches were available:
> > a) Consider 3630 generation of devices as a new family of silicon
> > b) Consider 3630 as an offshoot of 3430 family of devices
> >
> > As a common consensus, (b) seems to be more valid for 3630 as:
> > * There are changes which are easily handled by looking at rev
> > * Most of existing 34xx infrastructure can be reused(almost 90%+)
> > 	- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
> > 	  all over the place
> 
> And how about cpu_is_omap3() ?
> 
> That would be valid across 34xx (zoom2, n900), 35xx (beagle, pandora), and
> 36xx (zoom3).
> 
> IMO, returning positive in a 3630/3530 to cpu_is_omap34xx() could make the
> code
> quite unreadable.
> 
> 1. If you need to do something 34xx specific, then use cpu_is_34xx()
> 2. If your code is valid for all 34xx, 35xx, 36xx, then why not using
> cpu_is_omap3() ?
> 
> What do you think?

Not at this stage, lets bring in rename over time once 35xx changes from Sanjeev are also in.. 

> 
> > 	- lesser chance of bugs due to reuse of proven code flow
> > 	- 36xx specific handling can still be done where required
> > 	  within the existing infrastructure
> >
> > NOTE:
> > * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
> >   added on top of the existing 3630 ones are renumbered
> >
> > This patch was tested on SDP3430.
> 
> Maybe this should say:
> 
> This patch didn't broke SDP3430.
> 
No. it means what it says -> I tested this patch and booted the l-o kernel on SDP3430==> OMAP3430 is fine.

Regards,
Nishanth Menon