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