> > >> > OMAP3630 is "just" an OMAP3430 in disguise. > > >> > I don't think it deserves a new class. It should probably be handled like > > >> > it was done for 1610 and 1710. > > >> > > > >> > Theoretically, it should be considered as a 3430 ES4.0, because it is an > > >> > OMAP3430 ES3 + couple of bug fixes + couple of improvements. > > >> > > > >> > I think, that the proposal from Sanjeev to support 35xx > > >> > (http://marc.info/?l=linux-omap&m=125050987112798&w=2 ) might be leveraged > > >> > to handle 36xx as well. > > >> > > > >> > > >> 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. > > >> > > >> 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. > > > > And you're sure these HW IP changes require software changes? Please > > provide examples. Yes, I'm pretty sure some of them require software changes. No examples on the 3630 that I can disclose right now, but consider for instance the case of the TLL Save-and-Restore feature on 3430 - it's broken on ES3.0 and below and works great after. Or extra register bits in UHH_HOSTCONFIG introduced in ES3.0. The HW IP versions are still the same across these revisions, but the SOC ES version has changed. > > > > So, TI is changing HW IP in a way that requires software changes and > > not providing a way for software to detect these changes? > > > > IMHO, This is completely broken HW design. Agreed. I've already pinged some HW design folks to point this out. > > I agree, we should be able to detect various processors during the > init and then just set the necessary feature flags. I seem not to have understood the initially proposed solution when I made that comment. Consider the objection withdrawn. I agree - all we require is the ability to detect the chip version at init, and to set any flag that might be needed by code executing later. It is a better solution. I misunderstood the discussion to mean "the 3630 would not be detectable as a separate chip from the 3430 at all". It doesn't really matter where we make the distinction, as long as it is possible to add code to behave differently on the two chips (or other revisions of the OMAP3). 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
