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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
