Romit Dasgupta <[email protected]> writes:
> Introduces enum for identifying OPP types. This helps in querying the OPP
> layer by passing the type of OPP (enum types) and gets away from maintaining
> the pointer to the OPP data list outside the OPP layer.
>
> Signed-off-by: Romit Dasgupta <[email protected]>
I like this idea... but I have some questions about how we should
cleanly handle SMP and future SoCs.
> diff --git a/arch/arm/plat-omap/include/plat/opp.h
> b/arch/arm/plat-omap/include/plat/opp.h
> index 9f91ad3..c4d5bf9 100644
> --- a/arch/arm/plat-omap/include/plat/opp.h
> +++ b/arch/arm/plat-omap/include/plat/opp.h
> @@ -13,9 +13,18 @@
> #ifndef __ASM_ARM_OMAP_OPP_H
> #define __ASM_ARM_OMAP_OPP_H
>
> -extern struct omap_opp *mpu_opps;
> -extern struct omap_opp *dsp_opps;
> -extern struct omap_opp *l3_opps;
> +#ifdef CONFIG_ARCH_OMAP3
> +#define OPP_TYPES 3
> +#else
> +#error "You need to put the number of OPP types for OMAP chip type."
> +#endif
Rather than the #ifdef...
> +enum opp_t {
> + OPP_NONE,
> + OPP_MPU,
> + OPP_L3,
> + OPP_DSP
add OPP_MAX_TYPES here
> +};
And with that, how do you suggest handling SMP. Do we assume that the
OPP_MPU OPPs are common across all CPUs? Do we possibly need other
types for other busses on future SoCs?
We don't need the answeres to all these questions today, but I'd like
to know your thoughts on how this would be extended or made SoC
specific.
Thanks,
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
