[PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device

[Hiremath, Vaibhav]

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 at ti.com> 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