From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Mon, 7 May 2012 10:32:29 -0700 Subject: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support In-Reply-To: <79CD15C6BA57404B839C016229A409A83EA1778E@DBDE01.ent.ti.com> References: <1322808204-12878-3-git-send-email-hvaibhav@ti.com> <79CD15C6BA57404B839C016229A409A83EA10A64@DBDE01.ent.ti.com> <20120503155717.GE5140@atomide.com> <79CD15C6BA57404B839C016229A409A83EA1348F@DBDE01.ent.ti.com> <871un1j769.fsf@ti.com> <79CD15C6BA57404B839C016229A409A83EA1409D@DBDE01.ent.ti.com> <20120504200547.GU5613@atomide.com> <79CD15C6BA57404B839C016229A409A83EA1778E@DBDE01.ent.ti.com> Message-ID: <20120507173229.GA5088@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Hiremath, Vaibhav [120507 07:41]: > On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote: > > > > I suggest doing some clean-up patches before adding SOC_AM33XX where > > you just convert those to be > > > > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2) > > > > or something similar depending if they already are inside mach-omap2 > > directory. This will make them future proof for adding new SoCs > > without having to patch all over the place. BTW, just noticied that the above won't work the right way in the multi-omap case when all of them are compiled in.. > Cool, I also thought exactly same solution on this, but next thought came to > my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2 > option. However, it will be a good temporary solution for our problem, lets > review them first (I will submit shortly). ..so probably the best way to deal with that is with the additional CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted at: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67938.html Can you please take a look and see how that works for am33xx? Regards, Tony