Subject: CPU frequency scaling on MIPS (au1000/common/power.c)

From: Dominik Brodowski <[email-masked]>
Date: Thu, 23 Sep 2004 21:48:29 +0200

Hi,

While grepping for CPU_FREQ in the kernel sources I found some CPU frequency
scaling code in
arch/mips/au1000/common/power.c

As a common cross-architecture CPU frequency scaling infrastructure exists
in 2.6. kernels, and it offers a few interesting tidbits:

- support for dynamic frequency scaling if the hardware allows for it (low
	latencies caused by switching, and many switchings in a second are
	possible)
- handling of loops_per_jiffy updates, i.e. no need to do a lengthy
	calibrate_delay() 
- unified user interface, i.e. developers/users switching from ARM to MIPS
	will find the CPU frequency interface at the same place in sysfs
- informs "notifiers" of frequency switches. While the baud rate update
	in au1000/common/power.c seems to be a good candidate for such a
	notifier, it might be necessary to update the baud rate so fast
	that it needs to be done inside the are locked by pm_lock, and
	without a few function calls' overhead in between. Or isn't this
	a problem?

Therefore, I'd suggest that we update arch/mips/au1000/common/power.c to
use the cpufreq infrastructure. It is located at drivers/cpufreq/, besides
cpufreq.c one or more governors (currently [2.6.9-rc2] four exist,
powersave, performance, userspace and ondemand) are needed. Keeping the
old ctl_table interface around as a wrapper for the cpufreq interfaces looks
to be possible[*]; I'd like to #ifdef CONFIG_... and deprecate it, though.

As I don't have MIPS hardware [well, I do, inside a WRT54G router, but
that's besides the point], don't have and don't want to have a
cross-compiling infrastructure here, I can neither compile-test nor
real-life-test any patches I submit. Nonetheless I'd be willing to write
a "suggestion" on how to update arch/mips/au1000/common/power.c, and
somebody with compiler and hardware could test it then.

Are there other MIPS CPUs which support CPU frequency scaling? If so, it'd
be great if the maintainers for these specific platforms are aware of the
CPUfreq infrastructure, evaluate whether it's good enough for their needs,
and possibly add cpufreq drivers for these CPUs. 

For any questions, comments or patches regarding the cpufreq core or cpufreq 
drivers, there's a mailing list at cpufreq AT www DOT linux DOT org DOT uk, 
which is also CC'ed on this message. Maintainer of cpufreq is Dave Jones.

Thanks for listening,
	Dominik

[*] we already keep a few such old interfaces around, but they'll be removed
soon after 2005 begins. They'll not become available on MIPS in the
meantime, of course.

---

From: Pete Popov <[email-masked]>
Date: Thu, 23 Sep 2004 13:19:16 -0700 (PDT)

<snip>

> use the cpufreq infrastructure. 

The current interface was written a few years ago for
2.4, when I couldn't find a general PM interface to
start with.

> Nonetheless I'd be willing to write

That would help, though I'm not sure when I would get
to it personally. I'm working on 2.6 updates at the
moment with some other developers, but PM is not on
our list for now. If you're dying to work on it and
hardware is the only issue, I might be able to help :)

> Are there other MIPS CPUs which support CPU
> frequency scaling? 

Not that I know of, and not the way the Au1x supports
it.

Pete

---

From: Bruno Randolf <[email-masked]>
Date: Fri, 24 Sep 2004 10:15:57 +0200

> somebody with compiler and hardware could test it then.

i would be happy to cross-compile & test them on a meshcube (mtx-1), but i'm 
afraid i cant help too much with coding.

bruno

---

From: Pete Popov <[email-masked]>
Date: Fri, 24 Sep 2004 11:33:52 -0700 (PDT)

AMD notified me that the frequency scaling will not be
supported moving forward and will not be guaranteed to
work. Therefore, I'll have to remove that code from
the kernel so that it's not misleading.

Pete

---

From: Dominik Brodowski <[email-masked]>
Date: Fri, 24 Sep 2004 22:05:46 +0200

On Fri, Sep 24, 2004 at 11:33:52AM -0700, Pete Popov wrote:
> work.

... bad for them. Would have been a great feature. But they do have
excellent implementations in other chips...

	Dominik