Vaibhav Hiremath <hvaibhav@xxxxxx> 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 <hvaibhav@xxxxxx>
> Cc: Kevin Hilman <khilman@xxxxxx>
> Cc: Rajendra Nayak <rnayak@xxxxxx>
[...]
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
