Bug 70651

Sorry, there was obviously an error in the echo commands reported in the previous comment.

Actual relevant result is:

root@darkstar:~# echo "high"> /sys/class/drm/card0/device/power_dpm_force_performance_level
-bash: echo: write error: Invalid argument

root@darkstar:~# echo "low"> /sys/class/drm/card0/device/power_dpm_force_performance_level
-bash: echo: write error: Invalid argument

root@darkstar:~# echo "auto"> /sys/class/drm/card0/device/power_dpm_force_performance_level
-bash: echo: write error: Invalid argument

hi, any advice on this, please?

Does it work properly if you disable runtime pm?  Boot with radeon.runpm=0 on the kernel command line in grub.

Created attachment 126951 [details]
possible fix for SI

Starting with 3.13, the driver automatically powers down the dGPU on hybrid laptops when it's not in use.  Accessing the sysfs and debufgs information when it's powered down is invalid since the gpu is powered down.  This patch returns sensible values when you try to get/set this information when the GPU is powered off.

hi, I'm sorry but the patch doesn't seem to work to me.
I've applied it to 3.13.3:


root@darkstar:/usr/src/linux# patch -p1 < patch.txt 
patching file drivers/gpu/drm/radeon/radeon_pm.c
Hunk #7 succeeded at 1580 (offset -20 lines).


This is what I get:

root@darkstar:~# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:DIS: :DynOff:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0

root@darkstar:~# cat /sys/class/drm/card0/device/power_dpm_state 
balanced

root@darkstar:~# cat /sys/class/drm/card0/device/power_dpm_force_performance_level 
auto

root@darkstar:~# echo 'high' > /sys/class/drm/card0/device/power_dpm_force_performance_level 
-bash: echo: write error: Invalid argument
root@darkstar:~# echo 'low' > /sys/class/drm/card0/device/power_dpm_force_performance_level 
-bash: echo: write error: Invalid argument
root@darkstar:~# echo 'auto' > /sys/class/drm/card0/device/power_dpm_force_performance_level 
-bash: echo: write error: Invalid argument

root@darkstar:~# cat /sys/kernel/debug/dri/0/radeon_pm_info 
default engine clock: 575000 kHz
current engine clock: 210280 kHz
default memory clock: 900000 kHz
current memory clock: 00 kHz
voltage: 825 mV
PCIE lanes: 16


Plus, I've noticed this (unsure if it's missing some sort of parsing):
root@darkstar:~# echo 'batteryxxxx' > /sys/class/drm/card0/device/power_dpm_state 
root@darkstar:~# cat /sys/class/drm/card0/device/power_dpm_state
battery

(Same result with 'performancexxxx' and 'balancedxxxx')

It's ok with random letters as prefix:
root@darkstar:~# echo 'xxxxbattery' > /sys/class/drm/card0/device/power_dpm_state
-bash: echo: write error: Invalid argument

Please let me know if I can help somehow.

Thanks!

Should I maybe apply the patch to a more recent version of the kernel, considering the offset of hunk #7?

That patch is against 3.14rc; it should apply there.  The issue is that on hybrid laptops, the dGPU is powered down when not in use so you can't make adjustments to the dGPU when it's powered down.  It doesn't make sense to power it up to make the adjustments since it will just be powered down again right after.  As such the values you are reading back are garbage since the hw is powered down.  The patch just attempts to do something sensible when you try and access the hw via sysfs or debugfs and the dGPU is powered down.  You can disable the automatic dGPU power down by setting radeon.runpm=0 on the kernel command line in grub.

Hi, thanks for the update.
In comment 5 I reported results with the patch applied to 3.13.3. Long story short: it behaves the same as with plain stock 3.13.3.
I'll try to apply the patch to the latest 3.14rc and report the results again.

Thanks!

Created attachment 127471 [details]
patched_radeon_pm.c

Hi, I tried with 3.14-rc4, I still don't get the new sensible values upon accessing sysfs/debugfs when the asic is turned off.

With:

root@darkstar:~# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:DIS: :DynOff:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0

I still get:

root@darkstar:~# cat /sys/kernel/debug/dri/64/radeon_pm_info 
default engine clock: 575000 kHz
current engine clock: 210280 kHz
default memory clock: 900000 kHz
current memory clock: 00 kHz
voltage: 825 mV
PCIE lanes: 16

Looking at the patch, I think I should get 'Chip powered off'.

Source of my drivers/gpu/drm/radeon/radeon_pm.c attached.

Hi,

sorry, any news about this?
Is there something I can do to help?

radeon_pm_info still gives clocks and voltages to me, even if the dGPU is powered off (DynOff in vgaswitcheroo). I don't get 'Chip powered off'.

Am I missing something and everything is ok, or something's wrong with the patch? I'm willing to make tests on my hardware if it sounds useful, just let me know.

As stated in my previous comments, I tested 3.14rc4 + patch so far.
I attached the radeon_pm.c source file as it was when I compiled the kernel.

Thanks

I haven't had time to look into why that patch is not working for you, but as I said previously, accessing the board via sysfs or debugfs while it's powered off produces invalid results so even when I fix the patch, the only change will be feedback from debugfs.  You can't actually change the power state of a powered off card.  I'll post an updated patch as soon as I figure out why it's not working.

hi, thank you Alex.
To be clear, I absolutely didn't mean to rush you, just making myself available for testing and helping out as much as I can.

I understand the fact that it's not possible to access asic's parameters while it's turned off.

Thanks again for your work.

Hi,
thanks for your comment on this. I'm running into simmilar issue:

root@lisabook2:~# echo "low"> /sys/class/drm/card0/device/power_dpm_force_performance_level
-bash: echo: write error: Invalid argument

I'm also on a hybrid platform: MBP 8,2 with linux-3.14.0
I recently noticed this, that I can't set this value when I use the machine *without* an external Monitor which I usually don't.
Does it mean that the kernel now switches automatically to the non dGPU, when the dGPU is not in use? Would be great news.

Everything is working fine as of 3.16.3, I think it's fine to close this bug.
Thanks!