Bugzilla – Bug 26329
[radeon KMS] new PM/clocks code only detects 1 powerstate
Last modified: 2010-02-11 08:25:39 UTC
Created attachment 32917 [details]
dmesg excerpt showing DRM infos
I just fetched latest drm-radeon-testing git from airlied's tree to test out the new powermanagement / dynamic clocks bits.
Well, to make a long story short: it doesn't work like expected - I don't see any downclocking of the chip even though I have only a terminal open in XFCE.
Looking at the dmesg output (attached) it looks like that the kernel driver only detects ONE single power state for my card - this should be clearly wrong since the Windows driver knows at least three predefined states (250MHz, 500MHz and 750MHz GPU clock).
Any idea why the other states are not detected?
Can you attach your bios, please?
You mean the VGA BIOS? If yes, then how do I do this?
Anyway, good work bringing this into the kernel Rafał! :)
Created attachment 32918 [details]
I'm not sure if that's what you want?
Extracted 64K from 0xc0000 like explained in the coreboot wiki about VGA support. Sadly /proc/iomem doesn't list any 'Video ROM' so have to assume the default.
At least the dump contains some strings that indicate that it's really (only parts?) of the VGA BIOS.
Bringing PM to KMS was done with big help from many ppl, so that's not only my share :)
> Can you attach a copy of your video bios? (as root):
> cd /sys/bus/pci/devices/<pci bus id>
> echo 1 > rom
> cat rom > /tmp/vbios.rom
> echo 0 > rom
Created attachment 32928 [details]
correct VGA BIOS
The driver probably needs loosen the power mode checking a bit. The modes are skipped since they are interpreted as overclock modes since the power mode mclk is 800 Mhz vs the default mclk of 799 Mhz.
Created attachment 32933 [details] [review]
drm/radeon/kms: PM: use some margin when validating power modes
I have yet to try that patch, but wouldn't it be better to base the margin on percentage rather than on a fixed offset?
What I mean is: as long as the clock deviation is no bigger than (for example) 1% accept the clocks
(In reply to comment #8)
> What I mean is: as long as the clock deviation is no bigger than (for example)
> 1% accept the clocks
Maybe. I (just personal) don't like mul/div operations on low-level :)
Alex: can we use hardcoded 5MHz? Or should we make it relative?
Than differences in AtomBIOS tables should always be non-relative I guess (like that 1MHz), I *do not* except situations where:
1) GPU with 100MHz default engine has differences about 1MHz
2) GPU with 800MHz default engine has differences about 10MHz
I think it's always the same low difference if any.
Created attachment 32944 [details]
new dmesg output
I think we're moving in the right direction. At least the driver now detects some different power states.
But it looks like it select a power state with only one clock mode.
I'm not really sure if I have understood this whole PM stuff correctly, but am I right that the three power states are actually PM profiles?
If that's the case then they're obviously incorrectly labeled:
State 2 provides maximum clocks all the time, but is named Default - how can this be right?
Anyway, as you can guess I'm not seeing any reduction in clocks with this state selected. Hmmmm...
I'm resolving this bug to FIXED, since the initial issue is no longer and now all power states are at least detected.
Thanks again to Rafał and Alex for fixing this!