Hi Paul,
On 5/2/2012 11:09 AM, Paul Walmsley wrote:
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@xxxxxxxxxxxxxxx/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.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
