[PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav at ti.com> [120508 10:04]:
> On Tue, May 08, 2012 at 21:18:29, Tony Lindgren wrote:
> > * Hiremath, Vaibhav <hvaibhav at ti.com> [120507 22:52]:
> > > On Tue, May 08, 2012 at 01:05:01, Tony Lindgren wrote:
> > > > * Tony Lindgren <tony at atomide.com> [120507 12:22]:
> > > > > * Paul Walmsley <paul at pwsan.com> [120507 12:11]:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 4 May 2012, Tony Lindgren wrote:
> > > > > > 
> > > > > > > How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series?
> > > > > > > Then this becomes just:
> > > > > > > 
> > > > > > > #ifdef CONFIG_SOC_OMAP3PLUS
> > > > > > 
> > > > > > We might want to consider having separate CONFIG_SOC_* values for each 
> > > > > > SoC.  So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, 
> > > > > > CONFIG_SOC_OMAP3630, etc.
> > > > > 
> > > > > Hmm but this would be in addition to the SOC specific options. The goal
> > > > > is to cut down the ifdeffery needed all over the place to add new SoCs,
> > > > > see the experimental patch I posted:
> > > > > 
> > > > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html
> > > > 
> > > > Of course we could make this finer grained based on features
> > > > like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some
> > > > grouping like that in mind.
> > > > 
> > > 
> > > This is much better approach than both ARCH_OMAPx and SOC_OMAPxxxx.
> > 
> > OK good, so now the question is just what groupings we need.. Got any
> > suggestions?
> > 
> 
> Tony
> 
> I have submitted first round of cleanup patches in the same direction, can 
> you please take a look at them? Most of them are trivial and should be 
> considered for upstream.
> 
> I am trying to take cleanup thing one-by-one, and keep submitting them. 
> Please let me know if you have any suggestions or pointers for me.

Yes looking good thanks, made few comments there as you noticed.

Tony