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

Hi Paul,


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

quoted

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

quoted

I will be waiting for your comment and conformation on, which family
AM33xx
device should fall in? Please refer to the mail-chain -

http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67275.html

This decision turns out to be pretty important; it certainly affects the
AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at.

Here is my suggestion, based on our previous practice. ?I am not so
sure that it is the best way, but it seems pretty reasonable"

Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as
far as I can tell. ?The main area of similarity between the other
CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. ?And even that MPU
subsystem is quite different between, say, the 3430/3630 and the AM33xx.
Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM
interface, OMAP4-style interconnect, etc. ?Plus, most of the
CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like
the PM code.

This would seem to suggest that we should use CONFIG_ARCH_OMAP4. ?But that
option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9,
PL310, etc. ?None of that is true for AM335x.

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.

Regards
Santosh