Hi Kevin,
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Kevin Hilman
>Sent: Tuesday, January 12, 2010 6:19 PM
>To: Dasgupta, Romit
>Cc: Menon, Nishanth; linux-omap@vger.kernel.org
>Subject: Re: [PM-WIP-OPP][PATCH] OPP: Introduces enum for addressing
>different OPP types
>
>Romit Dasgupta <ro...@ti.com> 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 <ro...@ti.com>
>
>I like this idea... but I have some questions about how we should
>cleanly handle SMP and future SoCs.
Well, it is better than what we have today, but maybe not super scalable for
next device. This information is completely device dependant and should not be
in a plat-omap file.
In that case, it will be tricky to have an enum per devices because it will
prevent multiple omap build.
That for that reason that I think we might use hwmod to identify the relevant
scalable IPs, instead of yet another identifier for something that is IP
related.
Regards,
Benoit
>> 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 majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
--
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
