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.
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 :).+ 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 * ??
-- Regards, Nishanth Menon -- 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
