On Wed, Apr 18, 2012 at 10:06 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On Wed, 2012-04-18 at 10:26 -0700, Turquette, Mike wrote: >> On Wed, Apr 18, 2012 at 10:03 AM, Kevin Hilman <khilman@xxxxxx> wrote: >> > Tomi Valkeinen <tomi.valkeinen@xxxxxx> writes: >> >> On Tue, 2012-03-13 at 11:37 -0700, Kevin Hilman wrote: >> >>> It sounds to me like it acutally is a throughput constraint on CORE. If >> >>> so, wouldn't it be clearer to set a throughput constraint that is >> >>> calculated based on the pixel clock and resulting bitrate that would >> >>> have the same effect? >> >> >> >> I don't see that these limits would have anything to do with CORE. I'm >> >> guessing that the DSS HW just can't function properly with high clocks >> >> and low voltage. >> > >> > OK, this gets back to something we've talked about a few times that is >> > needed in the clock framework. Basically, we need a way for clocks to >> > prevent changes so these kinds of dependencies can be tracked. We've >> > talked about new APIs like clk_allow_changes(), clk_block_changes() or >> > something like that. >> > >> > Basically, something that allows clocks to know that their will not be >> > changed under them. >> >> Are the DSS clocks changing frequency behind your back? Or are the >> clock rates staying the same while the voltage is dropped? > > The latter. The clocks do not change behind my back. It's the DSS driver > making the clock rate changes. Right. The DVFS RFC that I'm working on right now should at least take care of the voltage scaling down when it shouldn't. >> For the former issue Kevin is right that we need better clock >> semantics. For the latter issue hopefully the future dvfs >> architecture will do the right thing (at least it does on paper). > > Note that many of the DSS clocks are generated inside DSS HW, and > managed by the DSS driver, and thus the clock framework doesn't know > anything about them. Will the future dvfs offer some way for the drivers > to limit the OPP? It must! In fact the common clk framework today (merged in 3.4-rc1) allows you to model your DSS clocks in a common way that jives with the rest of the SoC/PMIC/whatever. Regards, Mike -- 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
