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

["Turquette, Mike" <mturquette@xxxxxx>]

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