Re: [PM-WIP-OPP][PATCH 4/4] omap3: srf: remove hardcoded opp dependency

Nishanth Menon
2010-03-19T15:36:51Z

Felipe Balbi had written, on 03/19/2010 09:47 AM, the following:
> On Thu, Mar 18, 2010 at 07:44:51PM +0100, ext Nishanth Menon wrote:
>> @@ -131,5 +133,16 @@ void __init omap3_pm_init_opp_table(void)
>> r |= opp_init_list(OPP_L3, omap3_opp_def_list[1]);
>> r |= opp_init_list(OPP_DSP, omap3_opp_def_list[2]);
>> BUG_ON(r);
>> +
>> + /* First get the l3 thresh from highest l3 opp */
>> + freq = ULONG_MAX;
>> + opp = opp_find_freq_floor(OPP_L3, &freq);
>> + l3_thresh = freq * 4 / 1000;
>> + /* Now setup the L3 bandwidth restrictions for right mpu freqs */
>> + freq = cpu_is_omap3630() ? 500000000 : 600000000;
>
> I also don't like this. Don't you have somewhere else you could pick ?

yeah..:) I was hoping someone would comment on it. for multiple reasons
why i dont like this, but did put it in as a seperate api call - but I
did not like adding an API call when there is no reason to do that.

a) Essentially the opp bandwidth limit is specific to each cpu - but the
bandwidth itself is more of a resourceframework implementation - this
is the cause of my dislike.
b) if someone were to do an opp_add to l3, the logic I added is crappy!
ok, I think the code that adds l3 should also ensure to re-store new
bandwidth data.. (but anyways opp layer's next limitation comes here ->
lack of a callback mechanism to trigger re-computation etc..).. but that
is another topic..

I am not entirely sure where to put this registration if not here.. in a
module independent manner.

>
>> + while (!IS_ERR(opp = opp_find_freq_ceil(OPP_MPU, &freq))) {
>> + opp_store_data(opp, "l3thresh", (void *) l3_thresh);
>> + freq++;
>> + }
>
> this is a good example of what I mean. Instead of saving l3_thresh, why
> don't you group all those data in a structure (which could even be
> defined per-cpu really, you already have cpufreq34xx, so you could have
> cpufreq24xx 36xx 44xx, etc) and just store that in a void * ??
>
exactly the reason as pointed out in my reply to your email - it is not
flexible enough to do it as SR and similar modules would be common
drivers for all silicon - so u'd restrict their implementation by having
a common structure :).

--
Regards,
Nishanth Menon