Re: [PATCH 2/2] OMAPDSS: Ensure OPP100 when DSS is operational

Turquette, Mike
2012-04-18T17:26:26Z

On Wed, Apr 18, 2012 at 10:03 AM, Kevin Hilman <khilman@ti.com> wrote:
> Tomi Valkeinen <tomi.valkeinen@ti.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html