On Thu, Apr 28, 2011 at 4:06 PM, Colin Cross <ccross@xxxxxxxxxx> wrote:
> 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).
>
In the use cases of runtime clock setting by devfreq or other devices
mentioned above, we are controlling the device's performance with the
representative clock of the device, not a specific clock among the
clocks that the device has. For a device "A" with clock "a1" and "a2",
another device "B" would not control both "a1" and "a2" directly to
get the guaranteed performance from "A". Besides, "B" should not do so
if there are specific orders, delays, and other controls for "A" to
properly change performance.
Therefore, my answer is that it would be preferred to control through
some wrapper/interface/or anything that is connected to the device of
the controlled clocks (and let the device's callback or something
control its clocks), not to control through clock framework directly.
In this version of devfreq+OPP, these are handled by the "target"
callback.
Cheers!
- MyungJoo
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
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
