The Linux 2.6.36 Kernel Will Have Some Fun DRM

[wirrbeltier]

As all the cool kids already knew (we all are, right?), your dmesg lacks the following DRM_INFO() line:

[drm] radeon: power management initialized

I think that's because, as agd5f already stated, your Radeon x1600XT vbios lacks any information about other power states, due to the management of the card's power states by means of other external components, like the two programmable PWM controllers you have on the back of the PCB.

source: http://www.xbitlabs.com/articles/vid...-x1000_12.html

Sorry for the off-topic, but i couldn't help: I also have an X1600, passively cooled, and the same symptoms (with kernel 2.6.35 and recent radeon drivers on arch). Is there any way at all to reduce the power uptake when there are no low power states defined (reducing PCIe speed, or something equally crazy)?

[benoitg]

Are you running KMS, and do you have 2.6.35 or higher kernel ?

See more info at end of page : http://www.x.org/wiki/RadeonFeature

Yes, off course:
benoitg@benoitg-laptop:~$ uname -a
Linux benoitg-laptop 2.6.36-999-generic #201009121120 SMP Sun Sep 12 11:22:56 UTC 2010 x86_64 GNU/Linux
benoitg@benoitg-laptop:~$ cat /var/log/kern.log|grep drm
See http://pastebin.com/9NN1nznh

[bridgman]

Are you running KMS, and do you have 2.6.35 or higher kernel ?

See more info at end of page : http://www.x.org/wiki/RadeonFeature

[benoitg]

The mobile parts do have have low power states defined. It's just older desktop parts that tend to only offer overclock states. The desktop parts can still enable clock gating (turning off parts of the chip dynamically) with the poorly named dynclks parameter. I should really move that to sysfs as well.

In my case, it is a mobile part (hardware is a laptop, a 2nd generation MacBook Pro Core2Duo, with: 01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600]

Yet, /sys/class/drm/card0/device/power_method is missing.

[psychok9]

Thank you for your answer.

[bridgman]

You need the X driver built from an Evergreen-specific branch in order to get 2D or 3D acceleration on Evergreen GPUs.

My guess is that there are no edgers builds for the Evergreen-specific branch yet.

[psychok9]

I'm using an Radeon 5850(R800/Evergreen) on Maverick Alpha 3+updates.
I've tried to get last drivers/DRM using http://kernel.ubuntu.com/~kernel-ppa/mainline/ 2.6.36-RC1 kernel and https://edge.launchpad.net/~xorg-edgers/+archive/ppa drivers... But seem works like before... very basic support, tearing, no 2D acceleration.
I need to modify something on xorg.conf?
This is an Ubuntu-test-box, no problem if go wrong :P

[kusi]

For the next generation GPUs I think the approach will be roughly :

- start with the assumption we are only going to support Gallium3D
- build a sufficiently detailed list of EG->next gen changes so we can have a good idea how long adding support will take
- go bug the internal PMs to make sure we know when new parts will launch
- make sure we/community can port Evergreen support to 600g quickly enough to keep a reasonable schedule
- make sure that distros will be able to ship the Gallium3D driver even if it's still a bit rough and they're still shipping classic for earlier HW
- if all of the above seem OK, go with the Gallium3D driver from day 1
- if any of the above seem like a problem, do initial support on the classic Mesa HW driver then jump across to Gallium3D after

Quite offtopic: Bridgman, I'd like to thank you very much for all your detailed and competent information you provide weekly or even daily! Even you're probably paid for your community work, I'm sure it takes alot of patience to answer the same questions again and again. For me, all the insights you provided to us was reason enough for me to buy an AMD equipped notebook. Keep going with you taking time to answer all our questions!

Thanks very much!

[kraftman]

As all the cool kids already knew (we all are, right?), your dmesg lacks the following DRM_INFO() line:

[drm] radeon: power management initialized

I think that's because, as agd5f already stated, your Radeon x1600XT vbios lacks any information about other power states, due to the management of the card's power states by means of other external components, like the two programmable PWM controllers you have on the back of the PCB.

source: http://www.xbitlabs.com/articles/vid...-x1000_12.html

Everything is clear now. Thank you both for explanations.

[agd5f]

I support your last sentence, wholeheartedly. I always thought its function belongs to a sysfs file, as it would permit a more manageable control of the asic power management (especially when this was the only PM controllable aspect). Why was it called like that, if its function is clock gating, not dynamically clocking the chip/chip's parts? Did it do different things with older (r100?) ASICs?

The name was a vestige from the ddx when the option was ported to the kernel. It was called DynamicClocks since the clock signal to different blocks are dynamically turned on/off. The option name was later changed to ClockGating in the ddx, but kms was never changed. The sysfs stuff for power management was only recently added, so the dynclks option pre-dates it.