The Linux 2.6.36 Kernel Will Have Some Fun DRM

[Loris]

If your vbios doesn't define any reduced power states, the files are not added.

Yup, that.

And... you didn't post the output of "dmesg | grep -i drm" too. ;-)
But I think agd5f already nailed the issue.

[kraftman]

Yup, that.

And... you didn't post the output of "dmesg | grep -i drm" too. ;-)
But I think agd5f already nailed the issue.

Yeah. However, here's the output:

[ 7.850847] [drm] Initialized drm 1.1.0 20060810
[ 8.142419] [drm] radeon defaulting to kernel modesetting.
[ 8.142424] [drm] radeon kernel modesetting enabled.
[ 8.145819] [drm] initializing kernel modesetting (RV530 0x1002:0x71C0).
[ 8.145948] [drm] register mmio base: 0xFEAF0000
[ 8.145949] [drm] register mmio size: 65536
[ 8.146940] [drm] Generation 2 PCI interface, using max accessible memory
[ 8.147019] [drm] radeon: irq initialized.
[ 8.147281] [drm] Detected VRAM RAM=256M, BAR=256M
[ 8.147287] [drm] RAM width 128bits DDR
[ 8.677194] [drm] radeon: 256M of VRAM memory ready
[ 8.677196] [drm] radeon: 512M of GTT memory ready.
[ 8.677235] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 8.680221] [drm] radeon: 1 quad pipes, 2 z pipes initialized.
[ 8.681266] [drm] PCIE GART of 512M enabled (table at 0x00040000).
[ 8.681379] [drm] Loading R500 Microcode
[ 8.740110] [drm] radeon: ring at 0x0000000010000000
[ 8.740145] [drm] ring test succeeded in 6 usecs
[ 8.740295] [drm] radeon: ib pool ready.
[ 8.740795] [drm] ib test succeeded in 0 usecs
[ 8.740843] [drm] Default TV standard: PAL
[ 8.740846] [drm] Default TV standard: PAL
[ 8.740951] [drm] Default TV standard: PAL
[ 8.741036] [drm] Radeon Display Connectors
[ 8.741037] [drm] Connector 0:
[ 8.741038] [drm] VGA
[ 8.741041] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[ 8.741042] [drm] Encoders:
[ 8.741044] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 8.741045] [drm] Connector 1:
[ 8.741047] [drm] S-video
[ 8.741048] [drm] Encoders:
[ 8.741049] [drm] TV1: INTERNAL_KLDSCP_DAC2
[ 8.741050] [drm] Connector 2:
[ 8.741051] [drm] DVI-I
[ 8.741052] [drm] HPD1
[ 8.741054] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[ 8.741056] [drm] Encoders:
[ 8.741057] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[ 8.741059] [drm] DFP1: INTERNAL_KLDSCP_TMDS1
[ 8.925012] [drm] fb mappable at 0xD00C0000
[ 8.925017] [drm] vram apper at 0xD0000000
[ 8.925019] [drm] size 5242880
[ 8.925020] [drm] fb depth is 24
[ 8.925021] [drm] pitch is 5120
[ 8.967679] fb0: radeondrmfb frame buffer device
[ 8.967681] drm: registered panic notifier
[ 8.967800] [drm] Initialized radeon 2.5.0 20080528 for 0000:01:00.0 on minor 0

[Loris]

Yeah. However, here's the output:

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

agd5f: is there any interest (in a future far, far away) in researching external components like these and implementing each respective software logic? Where would such drivers belong, in the kernel tree? (i2c, blablabla, ...?)

Thank you. ;-)

[Loris]

(this would have been an edit, but we already know...)

edit: sorry, agd5f, one more thing: how do these chips control the card's power states? I'm easily induced in imagining solutions like these to be greatly limited by being exernal to the controlled hardware logic, not embedded or part of the very GPU/firmware. Do they only control the fan's speed? :P

Again, if you have the time to reply, thank you a thousand times.

[agd5f]

Drivers for most i2c thermal chips are already available via hwmon drivers already in the kernel (lmsensors). Once the hwmon driver is loaded you can read the temp and fan info via lmsensors or sysfs. The thermal sensor (whether internal or external) has nothing to do with the power states. Most pre-r6xx desktop asics did not offer low power states; they tended to offer overclock states which are not yet supported by the open driver.

[Loris]

Thank you agd5f, I actually thought the r5xx ASICs (desktop variants included) offered some sort of advanced power management (operating frequency, voltage, suspending parts of the ASIC, ...), especially thinking of them as power hungry and shrieking monsters (but I never even put my eyes on one... so my assumptions are based on the most trustworthy sources, like thin air, and Internet readings).

...while they only offered the options:
- make the fan scream
- make the fan scream and sweat
- make the fan explode

Ok, thank you.
And, sorry to all for shipwrecking the thread...

[whizse]

If your vbios doesn't define any reduced power states, the files are not added.

Oh, that's good to know, as always thanks for the explanation!

[agd5f]

Thank you agd5f, I actually thought the r5xx ASICs (desktop variants included) offered some sort of advanced power management (operating frequency, voltage, suspending parts of the ASIC, ...), especially thinking of them as power hungry and shrieking monsters (but I never even put my eyes on one... so my assumptions are based on the most trustworthy sources, like thin air, and Internet readings).

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.

[Loris]

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.

Thanks, I didn't rehash it in my post, but I imagined it was like that for mobile radeons, and desktop parts. I was just laughing on my own, thinking at an overheating r5xx, upping its frequencies to its explosion, just to play half life 2. Sorry, I'm being silly.

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?

Merci beaucoup.

Now, isn't it time I shut my trap? :P

[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.