> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Premi, Sanjeev
> Sent: Tuesday, September 22, 2009 5:18 PM
> To: Gadiyar, Anand; Aguirre Rodriguez, Sergio Alberto;
> Cousson, Benoit; Pais, Allen; [email protected]
> Cc: Raju, Veeramanikandan; Bongale, Hariprasad
> Subject: RE: [PATCH][RFC] OMAP3630: Create architecture
> macros and config entries.
>
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of
> Gadiyar, Anand
> > Sent: Tuesday, September 22, 2009 12:12 AM
> > To: Aguirre Rodriguez, Sergio Alberto; Cousson, Benoit; Pais,
> > Allen; [email protected]
> > 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 [email protected]
> > 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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
