Created attachment 124464 [details] Information about the supported gpu states Linux 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016 x86_64 GNU/Linux I thought my problem was perhaps a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=70654 but I'm pretty sure that this isn't the same problem. The problem I'm having is that I can't set the highest frequency state from my gpu (AMD A8-4500M APU + HD 7640G), in a consistent and persistent way. And this is regardless of whether uvd is enabled or not (as I assume this is enabled automatically and I haven't been running any application that requires it) In other words I would like to be able to set the dpm level to 'high' so that it stays in the higher frequency state, but I can't set the power_dpm_force_performance variable to anything other than 'auto' and 'low'. I get the following output: λ echo high | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level high tee: /sys/class/drm/card0/device/power_dpm_force_performance_level: Invalid argument It turns out that after some testing, I have noticed that it's more stable to set 'performance' dpm state and force it to 'low', which leaves the GPU frequency at ~335MHz, than setting it to auto which makes the frequencies jump between modes [335/490/655]MHz depending on the load. I would obviously like to be able to set a single mode and have a constant frequency. If I can set 655MHz permanently that would be ideal. I've already tried using 'dynpm' and 'profile' modes, but they don't work. I tried a bunch of times, even enabled/disabled some radeon parameters to see if they were somehow conflicting but I wasn't able to succesfully change states a single time. It would permanently stay at 200MHz with either of these two profile modes set. That left me with the single choice of using 'dpm', as it was the only mode that was able to at least change the states. I was told in IRC that the reason I couldn't set the 'high' value permanently was due to a hardware limitation of Trinity chips. I don't see how this can possibly be true as I can get this same GPU to be consistently at its highest frequency state in Windows 8. So if anything this is a limitation of the driver? I've attached the kernel info about the available states, the list of radeon parameters and their values in my system, and the output of /proc/cpuinfo. As of now I don't know what else to add so feel free to ask for any additional information, I'll make it available as soon as I can.
Created attachment 124465 [details] radeon parameters in use
Created attachment 124466 [details] cat /proc/cpuinfo
Created attachment 124467 [details] relevant packages
Created attachment 124468 [details] radeon7640g_vbios.rom
Created attachment 124471 [details] PCI info for the gpu
The hardware automatically adjusts the clock speeds on demand based on GPU load when in auto mode. Trinity/richland chips do not support forcing to high. From the driver code in trinity_dpm.c: int trinity_dpm_force_performance_level(struct radeon_device *rdev, enum radeon_dpm_forced_level level) { struct trinity_power_info *pi = trinity_get_pi(rdev); struct radeon_ps *rps = &pi->current_rps; struct trinity_ps *ps = trinity_get_ps(rps); int i, ret; if (ps->num_levels <= 1) return 0; if (level == RADEON_DPM_FORCED_LEVEL_HIGH) { /* not supported by the hw */ return -EINVAL; } else if (level == RADEON_DPM_FORCED_LEVEL_LOW) { ret = trinity_dpm_n_levels_disabled(rdev, ps->num_levels - 1); if (ret) return ret; } else { for (i = 0; i < ps->num_levels; i++) { ret = trinity_dpm_n_levels_disabled(rdev, 0); if (ret) return ret; } } rdev->pm.dpm.forced_level = level; return 0; }
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/721.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.