Vaibhav Hiremath <[email protected]> writes: > AM33XX PRM module (L4_WK domain) will be treated as another seperate > partition in _prm_bases[] table. > > Also, since cpu_is_omap34xx check is true for am33xx family of > devices, we must check cpu_is_am33xx fisrt, in order to follow > omap4 execution path.
Can you remind me why cpu_is_omap34xx() is true for AM33xx family? These AM3xxx devices make my brain hurt. > Signed-off-by: Vaibhav Hiremath <[email protected]> > Cc: Kevin Hilman <[email protected]> > Cc: Rajendra Nayak <[email protected]> [...] > diff --git a/arch/arm/mach-omap2/prminst44xx.c > b/arch/arm/mach-omap2/prminst44xx.c > index 3d9894f..fcc4123 100644 > --- a/arch/arm/mach-omap2/prminst44xx.c > +++ b/arch/arm/mach-omap2/prminst44xx.c > @@ -19,6 +19,7 @@ > #include "common.h" > > #include "prm44xx.h" > +#include "prm33xx.h" > #include "prminst44xx.h" > #include "prm-regbits-44xx.h" > #include "prcm44xx.h" > @@ -31,6 +32,7 @@ static u32 _prm_bases[OMAP4_MAX_PRCM_PARTITIONS] = { > [OMAP4430_CM2_PARTITION] = 0, > [OMAP4430_SCRM_PARTITION] = 0, > [OMAP4430_PRCM_MPU_PARTITION] = > OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE), > + [AM33XX_PRM_PARTITION] = > AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE), > }; I'm not crazy about just extending the "normal" OMAP4 table. That would imply that with each OMAP4 derivatve we keep extending this table. Instead, how about rename this to one to omap44xx_prm_bases[], then create a new one called am33xx_prm_bases[]. Then, at init time, assing _prm_bases to the right one based on cpu_is_. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
