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. > 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? Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
