> -----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. > > > > 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
