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? 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). 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
