public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Premi, Sanjeev" <premi@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 3/6] OMAP3: Add runtime check for OMAP35x
Date: Fri, 7 Aug 2009 11:23:25 +0300	[thread overview]
Message-ID: <20090807082322.GZ2358@atomide.com> (raw)
In-Reply-To: <87fxc56lfz.fsf@deeprootsystems.com>

* Kevin Hilman <khilman@deeprootsystems.com> [090806 17:56]:
> "Premi, Sanjeev" <premi@ti.com> writes:
> 
> >> -----Original Message-----
> >> From: Tony Lindgren [mailto:tony@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 <premi@ti.com> [090806 14:34]:
> >> >  
> >> > > -----Original Message-----
> >> > > From: Tony Lindgren [mailto:tony@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 <premi@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 <tony@atomide.com>
> >> > > > 
> >> > > >  [1] http://marc.info/?l=linux-omap&m=123301852702797&w=2
> >> > > >  [2] http://marc.info/?l=linux-omap&m=123334055822212&w=2
> >> > > > 
> >> > > > Signed-off-by: Sanjeev Premi <premi@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.
> >> 
> >> How about just add the individual type detection for 35xx processors,
> >> and then have something like this:
> >> 
> >> #define cpu_is_omap35xx()	(cpu_is_omap34xx() && 
> >> (cpu_is_omap3510() || \
> >> 					cpu_is_omap3520() || 
> >> cpu_is_omap3530())
> >> 
> >> That should pretty much shrink this patch series down to 
> >> about 50 lines or
> >> so of code.
> >
> > Okay, I will try this. Just not sure if some of the differences
> > in OMAP3530 and OMAP3430 can be detected.
> >
> > Will submit a patch soon.
> 
> 
> IMO, we should not be using cpu_is_* for detecting the differences
> between 34xx and 35xx, but rather we could query the features like
> you're doing in PATCH 4/6.
> 
> 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

  reply	other threads:[~2009-08-07  8:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06 10:36 [PATCH 3/6] OMAP3: Add runtime check for OMAP35x Sanjeev Premi
2009-08-06 11:04 ` Tony Lindgren
2009-08-06 11:34   ` Premi, Sanjeev
2009-08-06 11:50     ` Tony Lindgren
2009-08-06 14:11       ` Premi, Sanjeev
2009-08-06 14:18         ` Tony Lindgren
2009-08-06 14:55         ` Kevin Hilman
2009-08-07  8:23           ` Tony Lindgren [this message]
2009-08-10 15:10             ` Premi, Sanjeev
2009-08-11  8:02               ` Tony Lindgren
2009-08-11 11:52                 ` Premi, Sanjeev
2009-08-11 17:09                   ` Premi, Sanjeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090807082322.GZ2358@atomide.com \
    --to=tony@atomide.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=premi@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox