frequency requests in upower

[Mike Turquette]

On Wed, Apr 7, 2010 at 10:00 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> On Wed, 7 Apr 2010 13:25:30 -0500, Mike Turquette <mturquette at gmail.com> wrote:
>> Hi all,
>>
>> I was glancing over the QoS aspects of upower, and the control knobs
>> all appear to be related to latency.
>>
>> What if I had a codec for, say, video playback and I know it needs X
>> MHz to run properly.  How could upower help me to do this?  I'll
>> assume I have some cpufreq governor running in the background, but I
>> don't want to rely on that to get the job done when I already know my
>> frequency requirements.
>>
>> I guess my real question is, will frequency-based QoS knobs ever make
>> their way into upower?  I know the hot topics these days are
>> constraints (dma latency, cpu wake up latency, network throughput,
>> etc), but sometimes you just need the megahertz.
>>
> You seem to be assuming that the cpufreq governor somehow does an inferior
> job of keeping up with your computational requirements. If the ondemand
> governor (which should be used in pretty much all cases) isn't giving you
> the clockrate necessary to keep up with your workload, then that's a bug.

/me rolls up sleeves

I agree with the above.  Believe me that I understand *precisely* why
requesting MHz directly is wrong.  I was hoping to keep this
discussion conceptually generic, but I think I should explain my
concern further.

I am currently working on an OMAP board, which is an ARM-based SoC
with a DSP bolted on plus a bunch of other stuff.  For the purposes of
managing power and performance there are tuples commonly called
operating points that consist of ARM frequency, DSP frequency and
voltage across a common bus.

My codec runs on the DSP, and I'm exploring different methods to make
sure that the operating point selected by logic on the ARM (cpufreq,
pm constraints, whatever) does justice by the DSP's needs as well.