On Mon, May 07, 2012 at 16:14:42, Shilimkar, Santosh wrote:

On Mon, May 7, 2012 at 4:02 PM, Cousson, Benoit [off-list ref] wrote:

quoted

Hi Paul,


On 5/2/2012 11:09 AM, Paul Walmsley wrote:

quoted

On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote:

<snip>

quoted

quoted

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