OMAP PM constraint to disable OPP50

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]