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

[Hiremath, Vaibhav]

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.

Thanks,
Vaibhav