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

[Paul Walmsley]

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

> 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@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.

If we take the former option, then we should add a new 
CONFIG_ARCH_OMAPAM33XX Kconfig option to arch/arm/Makefile, at the same 
level as CONFIG_ARCH_OMAP1/2/3/4.  Similarly, we should add a 
CONFIG_ARCH_OMAPTI81XX Kconfig option.

However, if we take the second option, then we can probably shoehorn the 
AM33XX and the TI81xx chips into CONFIG_ARCH_OMAP4.

Either way, it would be good to get AM33xx and TI81xx out of 
CONFIG_ARCH_OMAP3, since keeping them there will require lots of 
changes across the codebase to stop using CONFIG_ARCH_OMAP3 and use the 
CONFIG_SOC_* Kconfig options instead.


- Paul