No subject

need for my codec to run.  Since DSP speed is tied to ARM speed
through the operating points I was hoping to use upower to place a
minimum frequency requirement.  cpufreq governors like ondemand will
not do this since it knows nothing of the DSP's needs.

There are lots of ways to solve this:
- write a cpufreq governor that takes the DSPs load into account
(assuming that the load information is exported by the DSP software)
- use userspace governor to select an ARM frequency that maps to the
needs of DSP (horrible idea)
- use a nice piece of plumbing to place a frequency constraint on the CPU

To give even more detail, the kernel driver that handles communication
with the DSP is not intelligent.  It does not know that the codec just
loaded is for MPEG4 video and needs X MHz.  So this constraint cannot
easily be made in the kernel.  The userspace daemon responsible for
loading the codec binary blobs knows this info, so the best place to
understand the MHz requirements for different codecs (mp3 vs aac vs
h.264) comes from userspace.

I understand if everyone vomits at the thought of such wicked and
despicable embedded stuff, but I would really like to discuss how to
handle such cases.  With the increasing number of coprocessors in all
manner of computers these days, this is a problem that others will
face.

Mike

> Cpufreq is the correct solution here. While you might think you know your
> frequency requirements today, they will invariably change over time and b=
etween
> machines. UPower doesn't implement frequency-based QoS management because=
 it's
> fundamentally the wrong approach. This is what cpufreq is for.
>
> You might want to take a look at Matthew Garrett's excellent blog[1] on C=
PU power
> management. I think it will help dispel a bunch of misconceptions you hav=
e
> formed.
>
> - Ben
>
> [1] http://mjg59.livejournal.com/88608.html
>