Hi, This is an old issue, and I've mentioned earlier, but I think we should finally do something about this. Or perhaps this can already be done, but I don't know the solution. The problem is that various DSS clocks have max frequencies that depend on whether we are at OPP100 or OPP50 (e.g. table 10-4. DSS Clock Frequencies in OMAP4 TRM). Some of these clocks come from the PRCM (like DSS_CLK on OMAP4), but some are generated internally by DSS (like pixel clocks). While the clocks coming from PRCM could perhaps be handled automatically (from DSS's point of view) by the PM/clock framework so that OPP50 would be disabled if the clocks are over the OPP50-limit, I guess that's not quite correct. The max freq limitation is inside DSS HW, not in the PRCM side (well, I'm guessing so). And as we anyway need to handle some of the clock limits inside DSS, I guess it's simpler to handle them all in DSS. But the main question is, how should it be done? Afaik the dss driver cannot say "stay in OPP100" to the PM framework. I guess the closest thing is to set a constraint to memory throughput with an arbitrarily high value, thus forcing OPP100. But even if it's quite easy to come up with an arbitrary value that should be high enough for years to come, this approach feels rather hacky. Can it have side effects? May it cause overclocking, as the PM framework thinks we need as much bandwidth as possible? Does it cause higher power consumption because something in L3/Core/somewhere is kept in a high perf mode for the high mem throughput, even if we don't actually need high throughput? Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
