Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-11 Thread Tony Lindgren 
Hi,

* Premi, Sanjeev pr...@ti.com [090810 20:15]:
  
 
  -Original Message-
  From: Tony Lindgren [mailto:t...@atomide.com] 
  Sent: Friday, August 07, 2009 1:53 PM
  To: Kevin Hilman
  Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
  Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
  
 
 snip--snip
 
   
   Adding conditionals like
   
 if (omap3_has_iva2())
...
   
   and
   
 if (omap3_has_sgx()) 
...
   
   rather than having a long list of cpu_is checks that have 
  to be changed
   each time a new SoC comes out.
  
  Agreed.
  
  Tony
  
  
 
 Tony, Kevin,
 
 Here is a work in progress patch implementing the conditionals.
 
 I am looking for your suggestions on these:
 1) The detection of ES2.0 is different between OMAP3530 and OMAP3430.
For 3430 ES2.0, (idcode  28) == 0x0
For 3530 ES2.0, (idcode  28) == 0x1
 
What can be easy way to make this distinction?

Hmm, looks like in switch (rev) case 1 is not used, so I guess you
can use that? Hmm, might be worth checking if the 3530 ES2.0 is really
based on the 3430 ES2.1 core though..

 
 2) How do we handle the power domain differences between OMAP34x
and the new OMAP3517 and OMAP05 devices. The hawkeye is different,
but, would it make sense to omap_revision to be like:
0x34050034, 0x34170034 - when we reuse the 34xx class.

Can't you use the bits documented in cpu.h:

/*
 * omap_rev bits:
 * CPU id bits  (0730, 1510, 1710, 2422...) [31:16]
 * CPU revision (See _REV_ defined in cpu.h)[15:08]
 * CPU class bits (15xx, 16xx, 24xx, 34xx...)   [07:00]
 */
unsigned int omap_rev(void);

Basically 0x3505??34, 0x3517??34 and so on? The cpu_is_omap34xx() is 
omap_rev()  0xff.

 
 3) Currently, the macros like OMAP3430_REV_ES1_0 are defined to
be whole numbers. I am trying to change them to something like:
 
 #define OMAP34XX_REV(type,rev)  (OMAP34XX_CLASS  (type  16)  (rev  12))
 
 And use as (if needed):
 
 #define OMAP3430_REV_ES3_1  OMAP34XX_REV(0x30, 0x4)
 
 #define OMAP3403_REV_ES3_1  OMAP34XX_REV(0x03, 0x4)
 
What is your view?
 
In fact, wouldn't it be better if we tested for si rev independent
from si type?

Well cpu_is_omap34xx() should be enough in most places, but I guess here you'd
want to test for the exact revision, and just define:
#define OMAP3505_REV_ES?_?  0x3505??34

 
 4) These macros are, possibly, duplicating the data in omap_revision:
 
 #define CHIP_IS_OMAP3430ES3_0 (1  5)
 #define CHIP_IS_OMAP3430ES3_1 (1  6)
 
But, might be used for faster checking. Is this duplication necessary?

These are currently needed for the clock framework, eventually we should
unify them..

 
 5) Assuming that we are able to maintain current, macros, would this
help in reducing the duplication?
 
 struct omap_id {
   u16 id; /* e.g. 0x3430, 0x3517, ... */
   u8  class;  /* 34x */
   u8  subclass;   /* 0x30, 0x03, 0x05, 0x15, 0x17 ... */
   u8  rev;/* 0x10 (for ES 1.0), 0x21 (for ES2.1) etc. */
   /* use nibble as decimal separator */
 }

Yeah we could do something like that as a separate patch eventually.

Few more comments inlined below.

 
 I have tried many approaches, before sending this mail,
 so there might be few duplications in the code below.
 The cpu_is_35xx() macros are also incomplete for now.
 
 Best regards,
 Sanjeev
 
 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
 index a98201c..f17d4db 100644
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -25,9 +25,47 @@
  #include mach/control.h
  #include mach/cpu.h
  
 +#define OMAP3_CONTROL_OMAP_STATUS0x044c
 +
 +#define OMAP3_SGX_SHIFT  13
 +#define OMAP3_SGX_MASK   (3  OMAP3_SGX_SHIFT)
 +#define  FEAT_SGX_FULL   0
 +#define  FEAT_SGX_HALF   1
 +#define  FEAT_SGX_NONE   2
 +
 +#define OMAP3_IVA_SHIFT  12
 +#define OMAP3_IVA_MASK   (1  OMAP3_SGX_SHIFT)
 +#define  FEAT_IVA0
 +#define  FEAT_IVA_NONE   1
 +
 +#define OMAP3_L2CACHE_SHIFT  10
 +#define OMAP3_L2CACHE_MASK   (3  OMAP3_L2CACHE_SHIFT)
 +#define  FEAT_L2CACHE_0KB0
 +#define  FEAT_L2CACHE_64KB   1
 +#define  FEAT_L2CACHE_128KB  2
 +#define  FEAT_L2CACHE_256KB  3
 +
 +#define OMAP3_ISP_SHIFT  5
 +#define OMAP3_ISP_MASK   (1 OMAP3_ISP_SHIFT)
 +#define  FEAT_ISP0
 +#define  FEAT_ISP_NONE   1
 +
 +#define OMAP3_NEON_SHIFT 4
 +#define OMAP3_NEON_MASK  (1 OMAP3_NEON_SHIFT)
 +#define  FEAT_NEON   0
 +#define  FEAT_NEON_NONE  1
 +
  static struct omap_chip_id omap_chip;
  static

RE: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-11 Thread Premi, Sanjeev 
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
 Sent: Tuesday, August 11, 2009 5:22 PM
 To: Tony Lindgren
 Cc: Kevin Hilman; linux-omap@vger.kernel.org
 Subject: RE: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

  -Original Message-
  From: Tony Lindgren [mailto:t...@atomide.com]
  Sent: Tuesday, August 11, 2009 1:33 PM
  To: Premi, Sanjeev
  Cc: Kevin Hilman; linux-omap@vger.kernel.org
  Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
 
  Hi,
 
  * Premi, Sanjeev pr...@ti.com [090810 20:15]:
  
  
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, August 07, 2009 1:53 PM
To: Kevin Hilman
Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
   
  
   snip--snip
  

 Adding conditionals like

   if (omap3_has_iva2())
  ...

 and

   if (omap3_has_sgx())
  ...

 rather than having a long list of cpu_is checks that have
to be changed
 each time a new SoC comes out.
   
Agreed.
   
Tony
   
   
  
   Tony, Kevin,
  
   Here is a work in progress patch implementing the conditionals.
  
   I am looking for your suggestions on these:
   1) The detection of ES2.0 is different between OMAP3530 and
  OMAP3430.
  For 3430 ES2.0, (idcode  28) == 0x0
  For 3530 ES2.0, (idcode  28) == 0x1
  
  What can be easy way to make this distinction?
 
  Hmm, looks like in switch (rev) case 1 is not used, so I guess you
  can use that? Hmm, might be worth checking if the 3530
 ES2.0 is really
  based on the 3430 ES2.1 core though..
 
 [sp] Yes, it is.

 
   2) How do we handle the power domain differences between OMAP34x
  and the new OMAP3517 and OMAP05 devices. The hawkeye is
  different,
  but, would it make sense to omap_revision to be like:
  0x34050034, 0x34170034 - when we reuse the 34xx class.
 
  Can't you use the bits documented in cpu.h:

 [sp] I was trying to use these bit only; but was trying to avoid
  multiple declarations for each silicon rev like this:
 #define OMAP3430_REV_ES1_00x34300034
 #define OMAP3430_REV_ES2_00x34301034
 #define OMAP3430_REV_ES2_10x34302034
 #define OMAP3430_REV_ES3_00x34303034
 #define OMAP3430_REV_ES3_10x34304034

  In my earlier patches, I had tried using masks for the
 ES revision;
  but the current code uses these values in direct assignment.

   omap_revision = OMAP3430_REV_ES3_1;

  If we could use a mask for omap_revision bits, I believe
  we won't need to multiple definitions for each si revision
  for all the variants - 3505, 3517, and so on.
 
  /*
   * omap_rev bits:
   * CPU id bits  (0730, 1510, 1710, 2422...) [31:16]
   * CPU revision (See _REV_ defined in cpu.h)[15:08]
   * CPU class bits (15xx, 16xx, 24xx, 34xx...)   [07:00]
   */
  unsigned int omap_rev(void);
 
  Basically 0x3505??34, 0x3517??34 and so on? The
 cpu_is_omap34xx() is
  omap_rev()  0xff.
 
 
   3) Currently, the macros like OMAP3430_REV_ES1_0 are defined to
  be whole numbers. I am trying to change them to something like:
  
   #define OMAP34XX_REV(type,rev)  (OMAP34XX_CLASS  (type 
  16)  (rev  12))
  
   And use as (if needed):
  
   #define OMAP3430_REV_ES3_1  OMAP34XX_REV(0x30, 0x4)
  
   #define OMAP3403_REV_ES3_1  OMAP34XX_REV(0x03, 0x4)
  
  What is your view?
  
  In fact, wouldn't it be better if we tested for si rev
  independent
  from si type?
 
  Well cpu_is_omap34xx() should be enough in most places, but I
  guess here you'd
  want to test for the exact revision, and just define:
  #define OMAP3505_REV_ES?_?  0x3505??34

 [sp] This is the multiplicity on definitions I am trying to avoid
  as same revision will be valid across OMAP3505 and OMAP3517
  in this case. Holds good even for 3503, 3515, 3525 and 3530.

 
 
   4) These macros are, possibly, duplicating the data in
  omap_revision:
  
   #define CHIP_IS_OMAP3430ES3_0 (1  5)
   #define CHIP_IS_OMAP3430ES3_1 (1  6)
  
  But, might be used for faster checking. Is this
  duplication necessary?
 
  These are currently needed for the clock framework,
  eventually we should
  unify them..
 
 
   5) Assuming that we are able to maintain current, macros,
 would this
  help in reducing the duplication?
  
   struct omap_id {
 u16 id; /* e.g. 0x3430, 0x3517, ... */
 u8  class;  /* 34x */
 u8  subclass;   /* 0x30, 0x03, 0x05, 0x15, 0x17 ... */
 u8  rev;/* 0x10 (for ES 1.0), 0x21 (for
  ES2.1) etc. */
 /* use nibble as decimal separator */
   }
 
  Yeah we could do something like that as a separate patch eventually.
 
  Few more comments inlined below.
 
  
   I have tried many approaches, before sending this mail

RE: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-10 Thread Premi, Sanjeev 
 

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com] 
 Sent: Friday, August 07, 2009 1:53 PM
 To: Kevin Hilman
 Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
 Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
 

snip--snip

  
  Adding conditionals like
  
if (omap3_has_iva2())
   ...
  
  and
  
if (omap3_has_sgx()) 
   ...
  
  rather than having a long list of cpu_is checks that have 
 to be changed
  each time a new SoC comes out.
 
 Agreed.
 
 Tony
 
 

Tony, Kevin,

Here is a work in progress patch implementing the conditionals.

I am looking for your suggestions on these:
1) The detection of ES2.0 is different between OMAP3530 and OMAP3430.
   For 3430 ES2.0, (idcode  28) == 0x0
   For 3530 ES2.0, (idcode  28) == 0x1

   What can be easy way to make this distinction?

2) How do we handle the power domain differences between OMAP34x
   and the new OMAP3517 and OMAP05 devices. The hawkeye is different,
   but, would it make sense to omap_revision to be like:
   0x34050034, 0x34170034 - when we reuse the 34xx class.

3) Currently, the macros like OMAP3430_REV_ES1_0 are defined to
   be whole numbers. I am trying to change them to something like:

#define OMAP34XX_REV(type,rev)  (OMAP34XX_CLASS  (type  16)  (rev  12))

And use as (if needed):

#define OMAP3430_REV_ES3_1  OMAP34XX_REV(0x30, 0x4)

#define OMAP3403_REV_ES3_1  OMAP34XX_REV(0x03, 0x4)

   What is your view?

   In fact, wouldn't it be better if we tested for si rev independent
   from si type?

4) These macros are, possibly, duplicating the data in omap_revision:

#define CHIP_IS_OMAP3430ES3_0   (1  5)
#define CHIP_IS_OMAP3430ES3_1   (1  6)

   But, might be used for faster checking. Is this duplication necessary?

5) Assuming that we are able to maintain current, macros, would this
   help in reducing the duplication?

struct omap_id {
u16 id; /* e.g. 0x3430, 0x3517, ... */
u8  class;  /* 34x */
u8  subclass;   /* 0x30, 0x03, 0x05, 0x15, 0x17 ... */
u8  rev;/* 0x10 (for ES 1.0), 0x21 (for ES2.1) etc. */
/* use nibble as decimal separator */
}

I have tried many approaches, before sending this mail,
so there might be few duplications in the code below.
The cpu_is_35xx() macros are also incomplete for now.

Best regards,
Sanjeev

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..f17d4db 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -25,9 +25,47 @@
 #include mach/control.h
 #include mach/cpu.h
 
+#define OMAP3_CONTROL_OMAP_STATUS  0x044c
+
+#define OMAP3_SGX_SHIFT13
+#define OMAP3_SGX_MASK (3  OMAP3_SGX_SHIFT)
+#defineFEAT_SGX_FULL   0
+#defineFEAT_SGX_HALF   1
+#defineFEAT_SGX_NONE   2
+
+#define OMAP3_IVA_SHIFT12
+#define OMAP3_IVA_MASK (1  OMAP3_SGX_SHIFT)
+#defineFEAT_IVA0
+#defineFEAT_IVA_NONE   1
+
+#define OMAP3_L2CACHE_SHIFT10
+#define OMAP3_L2CACHE_MASK (3  OMAP3_L2CACHE_SHIFT)
+#defineFEAT_L2CACHE_0KB0
+#defineFEAT_L2CACHE_64KB   1
+#defineFEAT_L2CACHE_128KB  2
+#defineFEAT_L2CACHE_256KB  3
+
+#define OMAP3_ISP_SHIFT5
+#define OMAP3_ISP_MASK (1 OMAP3_ISP_SHIFT)
+#defineFEAT_ISP0
+#defineFEAT_ISP_NONE   1
+
+#define OMAP3_NEON_SHIFT   4
+#define OMAP3_NEON_MASK(1 OMAP3_NEON_SHIFT)
+#defineFEAT_NEON   0
+#defineFEAT_NEON_NONE  1
+
 static struct omap_chip_id omap_chip;
 static unsigned int omap_revision;
 
+struct omap_feature {
+   u8 avail;
+   u32 attrib;
+};
+
+static struct omap_feature feat_sgx;
+static struct omap_feature feat_iva;
+static struct omap_feature feat_l2cache;
 
 unsigned int omap_rev(void)
 {
@@ -35,6 +73,24 @@ unsigned int omap_rev(void)
 }
 EXPORT_SYMBOL(omap_rev);
 
+unsigned int omap3_has_sgx(void)
+{
+   return feat_sgx.avail;
+}
+EXPORT_SYMBOL(omap3_has_sgx);
+
+unsigned int omap3_has_iva(void)
+{
+   return feat_iva.avail;
+}
+EXPORT_SYMBOL(omap3_has_iva);
+
+unsigned int omap3_has_l2cache(void)
+{
+   return feat_l2cache.avail;
+}
+EXPORT_SYMBOL(omap3_has_l2cache);
+
 /**
  * omap_chip_is - test whether currently running OMAP matches a chip type
  * @oc: omap_chip_t to test against
@@ -155,12 +211,32 @@ void __init omap24xx_check_revision(void)
pr_info(\n);
 }
 
-void __init omap34xx_check_revision(void)
+void __init omap3_check_features(void)
+{
+   u32 status;
+
+   status = omap_ctrl_readl(OMAP3_CONTROL_OMAP_STATUS);
+
+   /* Check for SGX

Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-07 Thread Tony Lindgren 
* Kevin Hilman khil...@deeprootsystems.com [090806 17:56]:
 Premi, Sanjeev pr...@ti.com writes:
 
  -Original Message-
  From: Tony Lindgren [mailto:t...@atomide.com] 
  Sent: Thursday, August 06, 2009 5:20 PM
  To: Premi, Sanjeev
  Cc: linux-omap@vger.kernel.org
  Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
  
  * Premi, Sanjeev pr...@ti.com [090806 14:34]:

-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com] 
Sent: Thursday, August 06, 2009 4:34 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

Hi,

* Sanjeev Premi pr...@ti.com [090806 13:36]:
 Added runtime check via omap2_set_globals_35xx().
 
 Parts of this patch have been derived from an earlier
 earlier patch submitted by Tony Lindgren t...@atomide.com
 
  [1] http://marc.info/?l=linux-omapm=123301852702797w=2
  [2] http://marc.info/?l=linux-omapm=123334055822212w=2
 
 Signed-off-by: Sanjeev Premi pr...@ti.com
 ---
  arch/arm/mach-omap2/id.c |  115 
--
  arch/arm/plat-omap/common.c  |   18 +-
  arch/arm/plat-omap/include/mach/common.h |1 +
  arch/arm/plat-omap/include/mach/cpu.h|   64 
  -
  4 files changed, 173 insertions(+), 25 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
 index a98201c..06770aa 100644
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -28,6 +28,14 @@
  static struct omap_chip_id omap_chip;
  static unsigned int omap_revision;
  
 +/* The new OMAP35x devices have assymetric names - 
OMAP3505 and OMAP3517.
 + * It is not possible to define a common macro to 
  identify them.
 + *
 + * A quick way is to separate them across 
  'generations' as below.
 + */
 +#define OMAP35XX_G1 0x1 /* Applies to 3503, 
3515, 3525 and 3530 */
 +#define OMAP35XX_G2 0x2 /* Applies to 3505 and 3517 */
 +
  
  unsigned int omap_rev(void)
  {
 @@ -155,12 +163,71 @@ void __init omap24xx_check_revision(void)
  pr_info(\n);
  }
  
 +static void __init omap34xx_set_revision(u8 rev, char 
  *rev_name)
 +{
 +switch (rev) {
 +case 0:
 +omap_revision = OMAP3430_REV_ES2_0;
 +strcat(rev_name, ES2.0);
 +break;
 +case 2:
 +omap_revision = OMAP3430_REV_ES2_1;
 +strcat(rev_name, ES2.1);
 +break;
 +case 3:
 +omap_revision = OMAP3430_REV_ES3_0;
 +strcat(rev_name, ES3.0);
 +break;
 +case 4:
 +omap_revision = OMAP3430_REV_ES3_1;
 +strcat(rev_name, ES3.1);
 +break;
 +default:
 +/* Use the latest known revision as default */
 +omap_revision = OMAP3430_REV_ES3_1;
 +strcat(rev_name, Unknown revision);
 +}
 +}
 +
 +static void __init omap35xx_set_revision(u8 rev, u8 gen, 
char *rev_name)
 +{
 +omap_revision = OMAP35XX_CLASS ;
 +
 +if (gen == OMAP35XX_G1) {
 +switch (rev) {
 +case 0: /* Take care of some older boards */
 +case 1:
 +omap_revision |= OMAP35XX_MASK_ES2_0;
 +strcat(rev_name, ES2.0);
 +break;
 +case 2:
 +omap_revision |= OMAP35XX_MASK_ES2_1;
 +strcat(rev_name, ES2.1);
 +break;
 +case 3:
 +omap_revision |= OMAP35XX_MASK_ES3_0;
 +strcat(rev_name, ES3.0);
 +break;
 +case 4:
 +omap_revision |= OMAP35XX_MASK_ES3_1;
 +strcat(rev_name, ES3.1);
 +break;
 +default:
 +/* Use the latest known 
  revision as default */
 +omap_revision |= OMAP35XX_MASK_ES3_0;
 +strcat(rev_name, Unknown revision);
 +}
 +} else {
 +strcat(rev_name, ES1.0);
 +}
 +}
 +

To me it looks like you're checking the exact same cores as 
we already do
for 34xx. That is, (idcode  28)  0xff for both 34xx and 
35xx. So basically
they have the same omap cores.
   
   No, the cores in OMAP3505 and OMAP3517 are very different.
   I have listed major differences in PATCH 2/6.
   
   These devices differ in following areas:
- Power management capabilities
  (Only 1 power domain, 1 OPP, etc.)
- EMIF4 instead of SDRC
- Support for DDR2
- EMAC
- USB

[PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-06 Thread Sanjeev Premi 
Added runtime check via omap2_set_globals_35xx().

Parts of this patch have been derived from an earlier
earlier patch submitted by Tony Lindgren t...@atomide.com

 [1] http://marc.info/?l=linux-omapm=123301852702797w=2
 [2] http://marc.info/?l=linux-omapm=123334055822212w=2

Signed-off-by: Sanjeev Premi pr...@ti.com
---
 arch/arm/mach-omap2/id.c |  115 --
 arch/arm/plat-omap/common.c  |   18 +-
 arch/arm/plat-omap/include/mach/common.h |1 +
 arch/arm/plat-omap/include/mach/cpu.h|   64 -
 4 files changed, 173 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..06770aa 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,14 @@
 static struct omap_chip_id omap_chip;
 static unsigned int omap_revision;
 
+/* The new OMAP35x devices have assymetric names - OMAP3505 and OMAP3517.
+ * It is not possible to define a common macro to identify them.
+ *
+ * A quick way is to separate them across 'generations' as below.
+ */
+#define OMAP35XX_G10x1 /* Applies to 3503, 3515, 3525 and 3530 */
+#define OMAP35XX_G20x2 /* Applies to 3505 and 3517 */
+
 
 unsigned int omap_rev(void)
 {
@@ -155,12 +163,71 @@ void __init omap24xx_check_revision(void)
pr_info(\n);
 }
 
+static void __init omap34xx_set_revision(u8 rev, char *rev_name)
+{
+   switch (rev) {
+   case 0:
+   omap_revision = OMAP3430_REV_ES2_0;
+   strcat(rev_name, ES2.0);
+   break;
+   case 2:
+   omap_revision = OMAP3430_REV_ES2_1;
+   strcat(rev_name, ES2.1);
+   break;
+   case 3:
+   omap_revision = OMAP3430_REV_ES3_0;
+   strcat(rev_name, ES3.0);
+   break;
+   case 4:
+   omap_revision = OMAP3430_REV_ES3_1;
+   strcat(rev_name, ES3.1);
+   break;
+   default:
+   /* Use the latest known revision as default */
+   omap_revision = OMAP3430_REV_ES3_1;
+   strcat(rev_name, Unknown revision);
+   }
+}
+
+static void __init omap35xx_set_revision(u8 rev, u8 gen, char *rev_name)
+{
+   omap_revision = OMAP35XX_CLASS ;
+
+   if (gen == OMAP35XX_G1) {
+   switch (rev) {
+   case 0: /* Take care of some older boards */
+   case 1:
+   omap_revision |= OMAP35XX_MASK_ES2_0;
+   strcat(rev_name, ES2.0);
+   break;
+   case 2:
+   omap_revision |= OMAP35XX_MASK_ES2_1;
+   strcat(rev_name, ES2.1);
+   break;
+   case 3:
+   omap_revision |= OMAP35XX_MASK_ES3_0;
+   strcat(rev_name, ES3.0);
+   break;
+   case 4:
+   omap_revision |= OMAP35XX_MASK_ES3_1;
+   strcat(rev_name, ES3.1);
+   break;
+   default:
+   /* Use the latest known revision as default */
+   omap_revision |= OMAP35XX_MASK_ES3_0;
+   strcat(rev_name, Unknown revision);
+   }
+   } else {
+   strcat(rev_name, ES1.0);
+   }
+}
+
 void __init omap34xx_check_revision(void)
 {
u32 cpuid, idcode;
u16 hawkeye;
u8 rev;
-   char *rev_name = ES1.0;
+   char rev_name[16] = ;
 
/*
 * We cannot access revision registers on ES1.0.
@@ -184,28 +251,12 @@ void __init omap34xx_check_revision(void)
rev = (idcode  28)  0xff;
 
if (hawkeye == 0xb7ae) {
-   switch (rev) {
-   case 0:
-   omap_revision = OMAP3430_REV_ES2_0;
-   rev_name = ES2.0;
-   break;
-   case 2:
-   omap_revision = OMAP3430_REV_ES2_1;
-   rev_name = ES2.1;
-   break;
-   case 3:
-   omap_revision = OMAP3430_REV_ES3_0;
-   rev_name = ES3.0;
-   break;
-   case 4:
-   omap_revision = OMAP3430_REV_ES3_1;
-   rev_name = ES3.1;
-   break;
-   default:
-   /* Use the latest known revision as default */
-   omap_revision = OMAP3430_REV_ES3_1;
-   rev_name = Unknown revision\n;
-   }
+   if (cpu_is_omap35xx())
+   omap35xx_set_revision(rev, OMAP35XX_G1, rev_name);
+   else
+   omap34xx_set_revision(rev, rev_name);
+   } else if (hawkeye == 0xb868) {
+   omap35xx_set_revision(rev, OMAP35XX_G2, rev_name);
}
 
 out:
@@ -241,6

Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-06 Thread Tony Lindgren 
Hi,

* Sanjeev Premi pr...@ti.com [090806 13:36]:
 Added runtime check via omap2_set_globals_35xx().
 
 Parts of this patch have been derived from an earlier
 earlier patch submitted by Tony Lindgren t...@atomide.com
 
  [1] http://marc.info/?l=linux-omapm=123301852702797w=2
  [2] http://marc.info/?l=linux-omapm=123334055822212w=2
 
 Signed-off-by: Sanjeev Premi pr...@ti.com
 ---
  arch/arm/mach-omap2/id.c |  115 
 --
  arch/arm/plat-omap/common.c  |   18 +-
  arch/arm/plat-omap/include/mach/common.h |1 +
  arch/arm/plat-omap/include/mach/cpu.h|   64 -
  4 files changed, 173 insertions(+), 25 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
 index a98201c..06770aa 100644
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -28,6 +28,14 @@
  static struct omap_chip_id omap_chip;
  static unsigned int omap_revision;
  
 +/* The new OMAP35x devices have assymetric names - OMAP3505 and OMAP3517.
 + * It is not possible to define a common macro to identify them.
 + *
 + * A quick way is to separate them across 'generations' as below.
 + */
 +#define OMAP35XX_G1  0x1 /* Applies to 3503, 3515, 3525 and 3530 */
 +#define OMAP35XX_G2  0x2 /* Applies to 3505 and 3517 */
 +
  
  unsigned int omap_rev(void)
  {
 @@ -155,12 +163,71 @@ void __init omap24xx_check_revision(void)
   pr_info(\n);
  }
  
 +static void __init omap34xx_set_revision(u8 rev, char *rev_name)
 +{
 + switch (rev) {
 + case 0:
 + omap_revision = OMAP3430_REV_ES2_0;
 + strcat(rev_name, ES2.0);
 + break;
 + case 2:
 + omap_revision = OMAP3430_REV_ES2_1;
 + strcat(rev_name, ES2.1);
 + break;
 + case 3:
 + omap_revision = OMAP3430_REV_ES3_0;
 + strcat(rev_name, ES3.0);
 + break;
 + case 4:
 + omap_revision = OMAP3430_REV_ES3_1;
 + strcat(rev_name, ES3.1);
 + break;
 + default:
 + /* Use the latest known revision as default */
 + omap_revision = OMAP3430_REV_ES3_1;
 + strcat(rev_name, Unknown revision);
 + }
 +}
 +
 +static void __init omap35xx_set_revision(u8 rev, u8 gen, char *rev_name)
 +{
 + omap_revision = OMAP35XX_CLASS ;
 +
 + if (gen == OMAP35XX_G1) {
 + switch (rev) {
 + case 0: /* Take care of some older boards */
 + case 1:
 + omap_revision |= OMAP35XX_MASK_ES2_0;
 + strcat(rev_name, ES2.0);
 + break;
 + case 2:
 + omap_revision |= OMAP35XX_MASK_ES2_1;
 + strcat(rev_name, ES2.1);
 + break;
 + case 3:
 + omap_revision |= OMAP35XX_MASK_ES3_0;
 + strcat(rev_name, ES3.0);
 + break;
 + case 4:
 + omap_revision |= OMAP35XX_MASK_ES3_1;
 + strcat(rev_name, ES3.1);
 + break;
 + default:
 + /* Use the latest known revision as default */
 + omap_revision |= OMAP35XX_MASK_ES3_0;
 + strcat(rev_name, Unknown revision);
 + }
 + } else {
 + strcat(rev_name, ES1.0);
 + }
 +}
 +

To me it looks like you're checking the exact same cores as we already do
for 34xx. That is, (idcode  28)  0xff for both 34xx and 35xx. So basically
they have the same omap cores.

Considering this I don't see much sense adding cpu_is_35xx() category
because cpu_is_34xx() already covers these processors. Just like cpu_is_16xx()
covers both 1610 and 1710.

Let's just rather add more feature tests for IVA2 etc as needed, then
cpu_is_35something() becomse just cpu_is_34xx()  cpu_has_iva2() or similar.


  void __init omap34xx_check_revision(void)
  {
   u32 cpuid, idcode;
   u16 hawkeye;
   u8 rev;
 - char *rev_name = ES1.0;
 + char rev_name[16] = ;
  
   /*
* We cannot access revision registers on ES1.0.
 @@ -184,28 +251,12 @@ void __init omap34xx_check_revision(void)
   rev = (idcode  28)  0xff;
  
   if (hawkeye == 0xb7ae) {
 - switch (rev) {
 - case 0:
 - omap_revision = OMAP3430_REV_ES2_0;
 - rev_name = ES2.0;
 - break;
 - case 2:
 - omap_revision = OMAP3430_REV_ES2_1;
 - rev_name = ES2.1;
 - break;
 - case 3:
 - omap_revision = OMAP3430_REV_ES3_0;
 - rev_name = ES3.0;
 - break;
 - case 4:
 - omap_revision = OMAP3430_REV_ES3_1;
 - rev_name = ES3.1;
 - break;
 - default:
 -

RE: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-06 Thread Premi, Sanjeev 
 
 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com] 
 Sent: Thursday, August 06, 2009 4:34 PM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
 
 Hi,
 
 * Sanjeev Premi pr...@ti.com [090806 13:36]:
  Added runtime check via omap2_set_globals_35xx().
  
  Parts of this patch have been derived from an earlier
  earlier patch submitted by Tony Lindgren t...@atomide.com
  
   [1] http://marc.info/?l=linux-omapm=123301852702797w=2
   [2] http://marc.info/?l=linux-omapm=123334055822212w=2
  
  Signed-off-by: Sanjeev Premi pr...@ti.com
  ---
   arch/arm/mach-omap2/id.c |  115 
 --
   arch/arm/plat-omap/common.c  |   18 +-
   arch/arm/plat-omap/include/mach/common.h |1 +
   arch/arm/plat-omap/include/mach/cpu.h|   64 -
   4 files changed, 173 insertions(+), 25 deletions(-)
  
  diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
  index a98201c..06770aa 100644
  --- a/arch/arm/mach-omap2/id.c
  +++ b/arch/arm/mach-omap2/id.c
  @@ -28,6 +28,14 @@
   static struct omap_chip_id omap_chip;
   static unsigned int omap_revision;
   
  +/* The new OMAP35x devices have assymetric names - 
 OMAP3505 and OMAP3517.
  + * It is not possible to define a common macro to identify them.
  + *
  + * A quick way is to separate them across 'generations' as below.
  + */
  +#define OMAP35XX_G10x1 /* Applies to 3503, 
 3515, 3525 and 3530 */
  +#define OMAP35XX_G20x2 /* Applies to 3505 and 3517 */
  +
   
   unsigned int omap_rev(void)
   {
  @@ -155,12 +163,71 @@ void __init omap24xx_check_revision(void)
  pr_info(\n);
   }
   
  +static void __init omap34xx_set_revision(u8 rev, char *rev_name)
  +{
  +   switch (rev) {
  +   case 0:
  +   omap_revision = OMAP3430_REV_ES2_0;
  +   strcat(rev_name, ES2.0);
  +   break;
  +   case 2:
  +   omap_revision = OMAP3430_REV_ES2_1;
  +   strcat(rev_name, ES2.1);
  +   break;
  +   case 3:
  +   omap_revision = OMAP3430_REV_ES3_0;
  +   strcat(rev_name, ES3.0);
  +   break;
  +   case 4:
  +   omap_revision = OMAP3430_REV_ES3_1;
  +   strcat(rev_name, ES3.1);
  +   break;
  +   default:
  +   /* Use the latest known revision as default */
  +   omap_revision = OMAP3430_REV_ES3_1;
  +   strcat(rev_name, Unknown revision);
  +   }
  +}
  +
  +static void __init omap35xx_set_revision(u8 rev, u8 gen, 
 char *rev_name)
  +{
  +   omap_revision = OMAP35XX_CLASS ;
  +
  +   if (gen == OMAP35XX_G1) {
  +   switch (rev) {
  +   case 0: /* Take care of some older boards */
  +   case 1:
  +   omap_revision |= OMAP35XX_MASK_ES2_0;
  +   strcat(rev_name, ES2.0);
  +   break;
  +   case 2:
  +   omap_revision |= OMAP35XX_MASK_ES2_1;
  +   strcat(rev_name, ES2.1);
  +   break;
  +   case 3:
  +   omap_revision |= OMAP35XX_MASK_ES3_0;
  +   strcat(rev_name, ES3.0);
  +   break;
  +   case 4:
  +   omap_revision |= OMAP35XX_MASK_ES3_1;
  +   strcat(rev_name, ES3.1);
  +   break;
  +   default:
  +   /* Use the latest known revision as default */
  +   omap_revision |= OMAP35XX_MASK_ES3_0;
  +   strcat(rev_name, Unknown revision);
  +   }
  +   } else {
  +   strcat(rev_name, ES1.0);
  +   }
  +}
  +
 
 To me it looks like you're checking the exact same cores as 
 we already do
 for 34xx. That is, (idcode  28)  0xff for both 34xx and 
 35xx. So basically
 they have the same omap cores.

No, the cores in OMAP3505 and OMAP3517 are very different.
I have listed major differences in PATCH 2/6.

These devices differ in following areas:
 - Power management capabilities
   (Only 1 power domain, 1 OPP, etc.)
 - EMIF4 instead of SDRC
 - Support for DDR2
 - EMAC
 - USB
 - HECC

 
 Considering this I don't see much sense adding cpu_is_35xx() category
 because cpu_is_34xx() already covers these processors. Just 
 like cpu_is_16xx()
 covers both 1610 and 1710.
 
 Let's just rather add more feature tests for IVA2 etc as needed, then
 cpu_is_35something() becomse just cpu_is_34xx()  
 cpu_has_iva2() or similar.

I did feel the need for these tests as well, and have an internal patch.
It was in my queue for submission next.


 
 
   void __init omap34xx_check_revision(void)
   {
  u32 cpuid, idcode;
  u16 hawkeye;
  u8 rev;
  -   char *rev_name = ES1.0;
  +   char rev_name[16] = ;
   
  /*
   * We cannot access revision registers on ES1.0.
  @@ -184,28 +251,12 @@ void __init omap34xx_check_revision(void)
  rev = (idcode  28)  0xff;
   
  if (hawkeye == 0xb7ae

RE: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-06 Thread Premi, Sanjeev 
 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com] 
 Sent: Thursday, August 06, 2009 5:20 PM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
 
 * Premi, Sanjeev pr...@ti.com [090806 14:34]:
   
   -Original Message-
   From: Tony Lindgren [mailto:t...@atomide.com] 
   Sent: Thursday, August 06, 2009 4:34 PM
   To: Premi, Sanjeev
   Cc: linux-omap@vger.kernel.org
   Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
   
   Hi,
   
   * Sanjeev Premi pr...@ti.com [090806 13:36]:
Added runtime check via omap2_set_globals_35xx().

Parts of this patch have been derived from an earlier
earlier patch submitted by Tony Lindgren t...@atomide.com

 [1] http://marc.info/?l=linux-omapm=123301852702797w=2
 [2] http://marc.info/?l=linux-omapm=123334055822212w=2

Signed-off-by: Sanjeev Premi pr...@ti.com
---
 arch/arm/mach-omap2/id.c |  115 
   --
 arch/arm/plat-omap/common.c  |   18 +-
 arch/arm/plat-omap/include/mach/common.h |1 +
 arch/arm/plat-omap/include/mach/cpu.h|   64 
 -
 4 files changed, 173 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..06770aa 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,14 @@
 static struct omap_chip_id omap_chip;
 static unsigned int omap_revision;
 
+/* The new OMAP35x devices have assymetric names - 
   OMAP3505 and OMAP3517.
+ * It is not possible to define a common macro to 
 identify them.
+ *
+ * A quick way is to separate them across 
 'generations' as below.
+ */
+#define OMAP35XX_G10x1 /* Applies to 3503, 
   3515, 3525 and 3530 */
+#define OMAP35XX_G20x2 /* Applies to 3505 and 3517 */
+
 
 unsigned int omap_rev(void)
 {
@@ -155,12 +163,71 @@ void __init omap24xx_check_revision(void)
pr_info(\n);
 }
 
+static void __init omap34xx_set_revision(u8 rev, char 
 *rev_name)
+{
+   switch (rev) {
+   case 0:
+   omap_revision = OMAP3430_REV_ES2_0;
+   strcat(rev_name, ES2.0);
+   break;
+   case 2:
+   omap_revision = OMAP3430_REV_ES2_1;
+   strcat(rev_name, ES2.1);
+   break;
+   case 3:
+   omap_revision = OMAP3430_REV_ES3_0;
+   strcat(rev_name, ES3.0);
+   break;
+   case 4:
+   omap_revision = OMAP3430_REV_ES3_1;
+   strcat(rev_name, ES3.1);
+   break;
+   default:
+   /* Use the latest known revision as default */
+   omap_revision = OMAP3430_REV_ES3_1;
+   strcat(rev_name, Unknown revision);
+   }
+}
+
+static void __init omap35xx_set_revision(u8 rev, u8 gen, 
   char *rev_name)
+{
+   omap_revision = OMAP35XX_CLASS ;
+
+   if (gen == OMAP35XX_G1) {
+   switch (rev) {
+   case 0: /* Take care of some older boards */
+   case 1:
+   omap_revision |= OMAP35XX_MASK_ES2_0;
+   strcat(rev_name, ES2.0);
+   break;
+   case 2:
+   omap_revision |= OMAP35XX_MASK_ES2_1;
+   strcat(rev_name, ES2.1);
+   break;
+   case 3:
+   omap_revision |= OMAP35XX_MASK_ES3_0;
+   strcat(rev_name, ES3.0);
+   break;
+   case 4:
+   omap_revision |= OMAP35XX_MASK_ES3_1;
+   strcat(rev_name, ES3.1);
+   break;
+   default:
+   /* Use the latest known 
 revision as default */
+   omap_revision |= OMAP35XX_MASK_ES3_0;
+   strcat(rev_name, Unknown revision);
+   }
+   } else {
+   strcat(rev_name, ES1.0);
+   }
+}
+
   
   To me it looks like you're checking the exact same cores as 
   we already do
   for 34xx. That is, (idcode  28)  0xff for both 34xx and 
   35xx. So basically
   they have the same omap cores.
  
  No, the cores in OMAP3505 and OMAP3517 are very different.
  I have listed major differences in PATCH 2/6.
  
  These devices differ in following areas:
   - Power management capabilities
 (Only 1 power domain, 1 OPP, etc.)
   - EMIF4 instead of SDRC
   - Support for DDR2
   - EMAC
   - USB
   - HECC
 
 Sure, but from compiler flags and io point of view they can still

Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-06 Thread Tony Lindgren 
* Premi, Sanjeev pr...@ti.com [090806 17:11]:
  -Original Message-
  From: Tony Lindgren [mailto:t...@atomide.com] 
  Sent: Thursday, August 06, 2009 5:20 PM
  To: Premi, Sanjeev
  Cc: linux-omap@vger.kernel.org
  Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
  
  * Premi, Sanjeev pr...@ti.com [090806 14:34]:

-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com] 
Sent: Thursday, August 06, 2009 4:34 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

Hi,

* Sanjeev Premi pr...@ti.com [090806 13:36]:
 Added runtime check via omap2_set_globals_35xx().
 
 Parts of this patch have been derived from an earlier
 earlier patch submitted by Tony Lindgren t...@atomide.com
 
  [1] http://marc.info/?l=linux-omapm=123301852702797w=2
  [2] http://marc.info/?l=linux-omapm=123334055822212w=2
 
 Signed-off-by: Sanjeev Premi pr...@ti.com
 ---
  arch/arm/mach-omap2/id.c |  115 
--
  arch/arm/plat-omap/common.c  |   18 +-
  arch/arm/plat-omap/include/mach/common.h |1 +
  arch/arm/plat-omap/include/mach/cpu.h|   64 
  -
  4 files changed, 173 insertions(+), 25 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
 index a98201c..06770aa 100644
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -28,6 +28,14 @@
  static struct omap_chip_id omap_chip;
  static unsigned int omap_revision;
  
 +/* The new OMAP35x devices have assymetric names - 
OMAP3505 and OMAP3517.
 + * It is not possible to define a common macro to 
  identify them.
 + *
 + * A quick way is to separate them across 
  'generations' as below.
 + */
 +#define OMAP35XX_G1  0x1 /* Applies to 3503, 
3515, 3525 and 3530 */
 +#define OMAP35XX_G2  0x2 /* Applies to 3505 and 3517 */
 +
  
  unsigned int omap_rev(void)
  {
 @@ -155,12 +163,71 @@ void __init omap24xx_check_revision(void)
   pr_info(\n);
  }
  
 +static void __init omap34xx_set_revision(u8 rev, char 
  *rev_name)
 +{
 + switch (rev) {
 + case 0:
 + omap_revision = OMAP3430_REV_ES2_0;
 + strcat(rev_name, ES2.0);
 + break;
 + case 2:
 + omap_revision = OMAP3430_REV_ES2_1;
 + strcat(rev_name, ES2.1);
 + break;
 + case 3:
 + omap_revision = OMAP3430_REV_ES3_0;
 + strcat(rev_name, ES3.0);
 + break;
 + case 4:
 + omap_revision = OMAP3430_REV_ES3_1;
 + strcat(rev_name, ES3.1);
 + break;
 + default:
 + /* Use the latest known revision as default */
 + omap_revision = OMAP3430_REV_ES3_1;
 + strcat(rev_name, Unknown revision);
 + }
 +}
 +
 +static void __init omap35xx_set_revision(u8 rev, u8 gen, 
char *rev_name)
 +{
 + omap_revision = OMAP35XX_CLASS ;
 +
 + if (gen == OMAP35XX_G1) {
 + switch (rev) {
 + case 0: /* Take care of some older boards */
 + case 1:
 + omap_revision |= OMAP35XX_MASK_ES2_0;
 + strcat(rev_name, ES2.0);
 + break;
 + case 2:
 + omap_revision |= OMAP35XX_MASK_ES2_1;
 + strcat(rev_name, ES2.1);
 + break;
 + case 3:
 + omap_revision |= OMAP35XX_MASK_ES3_0;
 + strcat(rev_name, ES3.0);
 + break;
 + case 4:
 + omap_revision |= OMAP35XX_MASK_ES3_1;
 + strcat(rev_name, ES3.1);
 + break;
 + default:
 + /* Use the latest known 
  revision as default */
 + omap_revision |= OMAP35XX_MASK_ES3_0;
 + strcat(rev_name, Unknown revision);
 + }
 + } else {
 + strcat(rev_name, ES1.0);
 + }
 +}
 +

To me it looks like you're checking the exact same cores as 
we already do
for 34xx. That is, (idcode  28)  0xff for both 34xx and 
35xx. So basically
they have the same omap cores.
   
   No, the cores in OMAP3505 and OMAP3517 are very different.
   I have listed major differences in PATCH 2/6.
   
   These devices differ in following areas:
- Power management capabilities
  (Only 1 power domain, 1 OPP, etc.)
- EMIF4 instead of SDRC
- Support for DDR2
- EMAC
- USB

Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x

2009-08-06 Thread Kevin Hilman 
Premi, Sanjeev pr...@ti.com writes:

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com] 
 Sent: Thursday, August 06, 2009 5:20 PM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
 
 * Premi, Sanjeev pr...@ti.com [090806 14:34]:
   
   -Original Message-
   From: Tony Lindgren [mailto:t...@atomide.com] 
   Sent: Thursday, August 06, 2009 4:34 PM
   To: Premi, Sanjeev
   Cc: linux-omap@vger.kernel.org
   Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
   
   Hi,
   
   * Sanjeev Premi pr...@ti.com [090806 13:36]:
Added runtime check via omap2_set_globals_35xx().

Parts of this patch have been derived from an earlier
earlier patch submitted by Tony Lindgren t...@atomide.com

 [1] http://marc.info/?l=linux-omapm=123301852702797w=2
 [2] http://marc.info/?l=linux-omapm=123334055822212w=2

Signed-off-by: Sanjeev Premi pr...@ti.com
---
 arch/arm/mach-omap2/id.c |  115 
   --
 arch/arm/plat-omap/common.c  |   18 +-
 arch/arm/plat-omap/include/mach/common.h |1 +
 arch/arm/plat-omap/include/mach/cpu.h|   64 
 -
 4 files changed, 173 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..06770aa 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,14 @@
 static struct omap_chip_id omap_chip;
 static unsigned int omap_revision;
 
+/* The new OMAP35x devices have assymetric names - 
   OMAP3505 and OMAP3517.
+ * It is not possible to define a common macro to 
 identify them.
+ *
+ * A quick way is to separate them across 
 'generations' as below.
+ */
+#define OMAP35XX_G1   0x1 /* Applies to 3503, 
   3515, 3525 and 3530 */
+#define OMAP35XX_G2   0x2 /* Applies to 3505 and 3517 */
+
 
 unsigned int omap_rev(void)
 {
@@ -155,12 +163,71 @@ void __init omap24xx_check_revision(void)
   pr_info(\n);
 }
 
+static void __init omap34xx_set_revision(u8 rev, char 
 *rev_name)
+{
+  switch (rev) {
+  case 0:
+  omap_revision = OMAP3430_REV_ES2_0;
+  strcat(rev_name, ES2.0);
+  break;
+  case 2:
+  omap_revision = OMAP3430_REV_ES2_1;
+  strcat(rev_name, ES2.1);
+  break;
+  case 3:
+  omap_revision = OMAP3430_REV_ES3_0;
+  strcat(rev_name, ES3.0);
+  break;
+  case 4:
+  omap_revision = OMAP3430_REV_ES3_1;
+  strcat(rev_name, ES3.1);
+  break;
+  default:
+  /* Use the latest known revision as default */
+  omap_revision = OMAP3430_REV_ES3_1;
+  strcat(rev_name, Unknown revision);
+  }
+}
+
+static void __init omap35xx_set_revision(u8 rev, u8 gen, 
   char *rev_name)
+{
+  omap_revision = OMAP35XX_CLASS ;
+
+  if (gen == OMAP35XX_G1) {
+  switch (rev) {
+  case 0: /* Take care of some older boards */
+  case 1:
+  omap_revision |= OMAP35XX_MASK_ES2_0;
+  strcat(rev_name, ES2.0);
+  break;
+  case 2:
+  omap_revision |= OMAP35XX_MASK_ES2_1;
+  strcat(rev_name, ES2.1);
+  break;
+  case 3:
+  omap_revision |= OMAP35XX_MASK_ES3_0;
+  strcat(rev_name, ES3.0);
+  break;
+  case 4:
+  omap_revision |= OMAP35XX_MASK_ES3_1;
+  strcat(rev_name, ES3.1);
+  break;
+  default:
+  /* Use the latest known 
 revision as default */
+  omap_revision |= OMAP35XX_MASK_ES3_0;
+  strcat(rev_name, Unknown revision);
+  }
+  } else {
+  strcat(rev_name, ES1.0);
+  }
+}
+
   
   To me it looks like you're checking the exact same cores as 
   we already do
   for 34xx. That is, (idcode  28)  0xff for both 34xx and 
   35xx. So basically
   they have the same omap cores.
  
  No, the cores in OMAP3505 and OMAP3517 are very different.
  I have listed major differences in PATCH 2/6.
  
  These devices differ in following areas:
   - Power management capabilities
 (Only 1 power domain, 1 OPP, etc.)
   - EMIF4 instead of SDRC
   - Support for DDR2
   - EMAC
   - USB
   - HECC
 
 Sure, but from compiler flags and io point of view they can still
 be treated as 34xx