>
> I like this idea... but I have some questions about how we should
> cleanly handle SMP and future SoCs.
Actually for OMAP4 AFAICT MPU's share only one set of OPPs (their clocks are
tied). So it should not be a problem there. OTOH, the OPP layer itself is not
thread safe today(I tried to make it thread + SMP safe in the version of the
code I posted earlier). You can look into opp_add and it shows that it is not
thread safe.
If you are talking about future SOCs we need to define the OPP list for the new
SoCs. The exact mechanism can be clear once we have the SRF replacement.
>
>> 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
>
Yes you are right. I will change the code and re-post.
>> +};
>
Thanks,
-Romit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
