On Wed, Apr 27, 2011 at 11:50 PM, MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> wrote:
> On Thu, Apr 28, 2011 at 3:44 PM, Colin Cross <ccross@xxxxxxxxxx> wrote:
>> On Wed, Apr 27, 2011 at 11:12 PM, MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> wrote:
>>> On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross <ccross@xxxxxxxxxx> wrote:
>>>> OPP currently has opp_enable and opp_disable functions. I don't
>>>> understand why these are needed, they are only used at init time to
>>>> determine available voltages, which could be handled by never passing
>>>> unavailable voltages to the dvfs implementation.
>>>
>>> We need them in runtime.
>>>
>>> A device "a" may want to guarantee that a device "b" to be at least
>>> "200MHz" or faster while it does some operations. Then, "a" will
>>> opp_disable("b", 100MHz and others); and opp_enable("b", them) later
>>> on. We have similar issues with multimedia blocks (MFC, Camera, FB,
>>> GPU) and CPU/Memory Bus. Ondemand governor of CPUFREQ has some delay
>>> on catching up a workload (1.5x the sampling rate in average, <2.0x
>>> the sampling rate in worst cases), which may incur flickering/tearing
>>> issues with multimedia streams. On the other hand, a general thermal
>>> monitor or battery manager might want to limit energy usage by
>>> disabling top performance clocks if it is too hot or the battery level
>>> is low.
>>
>> That sounds like a very strange api, when what you really mean is
>> clk_set_min_rate or clk_set_max_rate.
>
> Essentially, that's what needed.
> However, with clk_set_min/max_rate, don't we need to let another
> device to be consumer of other devices' clocks? Not just introducing a
> device to other devices?
Yes, but that's effectively what you're doing through a backwards api
anyways. The question is, for these complicated clock scenarios where
the final frequency of a clock depends on so many factors, should that
control go through the clock framework, or through some sort of global
clock governor (which is where OPP would reappear).
--
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
