OMAP PM constraint to disable OPP50
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
Quoted 6 lines · Tomi Valkeinen
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.
I agree with you.
We need to address the L3 bandwidth requirement for DSS as needed by high resolution panels.
Quoted 20 lines
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_CLKon 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.
Quoted 7 lines
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?
I have been thinking to determine the L3 bandwidth requirement based on the number of overlays/pipes enabled, width, height and color format and use the PM API omap_pm_set_min_bus_tput() to request the required L3 bandwidth. This bandwidth request and release has to be done for each frame.
I have been looking for right entry and exit functions in DSS drivers to add this L3 bandwidth request/release.
Regards,
Ragha
Quoted 11 lines · Raghu
Quoted 6 lines · Tomi Valkeinen
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.
I agree with you.
We need to address the L3 bandwidth requirement for DSS as needed by high resolution panels.
That is a different problem. There are to PM constraints from DSS:
- L3 bandwidth, depending on the pixel clock, resolution, color format, etc.
- Maximum DSS clock frequencies
The first one is not trivial, but it should be possible to implement it inside omapdss driver. The second one is the problem case my email was about.
Tomi