There doesn't appear to be any power states in your vbios.  You can enable clock gating by adding radeon.dynclks=1 to the kernel command line in grub.  Please attach a copy of your vbios as well.  To get a copy of your vbios:
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

Created attachment 50141 [details]
copy of my vbios

Thanks Alex,

I have attached my vbios. So, with dynclks=1, will I still be able to reduce the heat?

Roberto

(In reply to comment #3)
> I have attached my vbios. So, with dynclks=1, will I still be able to reduce
> the heat?

It should help unless the vbios as already enabled clock gating.

Probably bad advice, but what if user  executes rovclock [1] on top of KMS ?

 [1] - http://www.thinkwiki.org/wiki/Rovclock - has some info about min. clocks .... Also, not looked into modern KMS code yet, but people on #nouveau reported their cards need proper memtimings, are we (radeon) setting them (on combios and atombios cards ....)

There was another thread on Phoronix, with dynpm discussion, basically down to "it will work if we start to re-clock memory early, before vblank period, so at most few lines will be corrupted" but i can't find patches on dri-devel :(

http://phoronix.com/forums/showthread.php?57084-Gallium3D-Pipe-Video-To-Be-Merged-To-Mesa-Master&p=218105#post218105

ahlaht 

Date 07/12/2011
-----------------

"2. The engine clock and voltage can be changed freely without syncing to vblank and so it should work fine with multiple monitors too. (This is very cool.) There is no flickering provided CRTCs are kept ON while doing the reclocking. (But there is probably some good reason why the code turns them OFF by default.)
 
 3. The memory reclocking is much harder to do without flickering. Even if synced perfectly to vblank the time runs out in the end and visible display corruption occurs. The solution is to start the reclocking just few lines BEFORE vblank. This way if there is any flickering it's limited to the last few lines only.
 
 4. When idle and working properly dynpm doesn't use any more power than the "low" profile, but it still responds immediately to any gpu load.
 
 I'm currently testing if these hacks are stable. I had some crashes when writing them, but I think the problems should be fixed now..."

-----

I'm sure i saw patches ... but where?! kernel bugzilla?

for memtimings on radeon 7500 (changed via rovclock, while running proprietary driver) see forum post  here and down :

http://forums.gentoo.org/viewtopic-p-3687568.html#3687568

-----------copy--------------

#rovclock -i
Radeon overclock 0.6e by Hasw (hasw@hasw.net)

Found ATI card on 01:00, device id: 0x4c57
I/O base address: 0x3000
Video BIOS shadow found @ 0xc0000
Reference clock from BIOS: 27.0 MHz
Memory size: 32768 kB
Memory channels: 2, CD,CH only: 0
tRcdRD:   9
tRcdWR:   4
tRP:      8
tRAS:     18
tRRD:     3
tR2W-CL:  3
tWR:      4
tW2R:     2
tW2Rsb:   1
tR2R:     2
tRFC:     20
tWL(0.5): 2
tCAS:     3
tCMD:     0
tSTR:     1
XTAL: 27.0 MHz, RefDiv: 6

Core: 258.75 MHz, Mem: 364.50 MHz

------------copy-end-------------

And after over-clocking, note, some timings were lowered

------------copy2--------

UberPinguin ubrpngn # rovclock -i
Radeon overclock 0.6e by Hasw (hasw@hasw.net)

Found ATI card on 01:00, device id: 0x4c57
I/O base address: 0x3000
Video BIOS shadow found @ 0xc0000
Reference clock from BIOS: 27.0 MHz
Memory size: 32768 kB
Memory channels: 2, CD,CH only: 0
tRcdRD:   5
tRcdWR:   2
tRP:      4
tRAS:     14
tRRD:     3
tR2W-CL:  2
tWR:      3
tW2R:     0
tW2Rsb:   1
tR2R:     1
tRFC:     14
tWL(0.5): 2
tCAS:     3
tCMD:     0
tSTR:     1
XTAL: 27.0 MHz, RefDiv: 6

Core: 290.25 MHz, Mem: 380.25 MHz
----------copy2 ends----


reported speed boost: 

from ~647fps to ~1018 in glxgears

guess 260 ->290 engine and 364 -> 380 mem  can't explain such big boost alone?

from #nouveau channel:

http://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&show_html=true&highlight_names=&date=2011-08-19


--------
15:53 #nouveau: < MaximLevitsky> mupuf: one thing though, that memtimings don't seem to affect much, is that normal?
15:54 #nouveau: < MaximLevitsky> they are used, that for sure:
15:54 #nouveau: < MaximLevitsky> 4.864469] [drm] nouveau 0000:01:00.0: Using memory type: GGDR2
15:57 #nouveau: < mupuf> MaximLevitsky: the lowest perflvl should be faster
15:57 #nouveau: < mupuf> up to 4 times faster 

--------

Yes, nvidia is not amd/ati. But memory always important, it seems

Adding myself as a 'me too'

(In reply to comment #5)
> Probably bad advice, but what if user  executes rovclock [1] on top of KMS ?
> 
This seems to work, but I don't know if there is any (possibility for) harm. Your wording seems to suggest there is? 

Also, I am not sure if just down-clocking the core and memory is the same as the driver-provided power saving features?

And finally, I don't really know what settings are 'safe' and/or used by the driver? Some quick tries showed that is really easy to lock-up the computer with this :O
The lowest setting that I've tried that worked for me is 150/150 core/mem (but I did not really try anymore after it locked up)

Roberto Grassi, Xubuntu 11.04 reached EOL on October 28, 2012. For more on this, please see https://wiki.ubuntu.com/Releases.

If this is reproducible with a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal:
ubuntu-bug xorg

Also, please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.