On Mon, May 07, 2012 at 16:14:42, Shilimkar, Santosh wrote: > 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: > >> <snip> > >> 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. > I am working on creating patch-sets for am33xx device on the same direction, that means, am33xx will not fallow, neither ARCH_OMAP3 nor ARCH_OMAP4. am33xx will be separate device under ARCH_OMAP2PLUS, with "SOC_OMAPAM33XX". This also means, neither cpu_is_omap34xx() not cpu_is_omap44xx() will be true for am33xx. We will have separate cpu_is_am33xx() class for this. Shortly I will submit patch-series for this. Just FYI, I have some cleanup patches, which actually tries to cleanup some of the existing ARCH_OMAPx dependency in code, making addition of devices easier under ARCH_OMAP2PLUS. Thanks, Vaibhav -- 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
