On Mon, May 7, 2012 at 4:02 PM, Cousson, Benoit <b-cousson@xxxxxx> wrote: > Hi Paul, > > > On 5/2/2012 11:09 AM, Paul Walmsley wrote: >> >> On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: >> >>> I will be waiting for your comment and conformation on, which family >>> AM33xx >>> device should fall in? Please refer to the mail-chain - >>> >>> http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg67275.html >> >> >> This decision turns out to be pretty important; it certainly affects the >> AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. >> >> Here is my suggestion, based on our previous practice. I am not so >> sure that it is the best way, but it seems pretty reasonable" >> >> Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as >> far as I can tell. The main area of similarity between the other >> CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU >> subsystem is quite different between, say, the 3430/3630 and the AM33xx. >> Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM >> interface, OMAP4-style interconnect, etc. Plus, most of the >> CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like >> the PM code. >> >> This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that >> option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, >> PL310, etc. None of that is true for AM335x. >> >> So first we have to decide whether the CONFIG_ARCH_OMAP* options should >> have a strong dependency on the MPU type, as they currently do; or whether >> they should focus on the way the SoC is integrated. > > > I think as well that these devices should be considered as part of the OMAP4 > family. > The CPU type should not be the parameter that decide the OMAP family, it is > just an IP, that can change on some variant, whereas the whole PRCM > infrastructure / interconnect is mostly the same. > I agree. In fact more and more I think of this problem, looks like we should get rid off ARCH_OMAP* and just is SOC_* going forward. Common ARM code already takes care of different CPU version and as Benoit mentioned it is just one of the IP in the entire SOC. I saw tony commenting in similarly on of the patch set. Regards Santosh -- 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
