[PATCH 0/9] drm/radeon/kms: update pm code

Alex Deucher alexdeucher at gmail.com
Fri May 7 14:16:11 PDT 2010


This set of patches applies on top of the code in drm-radeon-testing.

I've been testing this code pretty hard this week and it's been solid.
In addition to some fixes on top of what's in d-r-t, it also reworks
the pm code to support two basic methods:

1. "dynpm"
2. "profile"

You can select the methods via sysfs.  Echo "dynpm" or "profile" to
/sys/class/drm/card-0/device/power_method.

The "dynpm" method dynamically changes the clocks based on the number of pending
fences, so performance is ramped up when running GPU intensive apps, and
ramped down when the GPU is idle.  The reclocking is attemped during
vertical blanking periods, but due to the timing of the reclocking
functions, doesn't not always complete in the blanking period, which can
lead to flicker in the display.  Due to this, dynpm only works when a single
head is active.

The "profile" method exposes 4 profiles that can be selected from:
1. "default"
2. "auto"
3. "low"
4. "high"
Select the profile by echoing the selected profile to
/sys/class/drm/card-0/device/power_profile.

"default" uses the default clocks and does not change the power state.  This is
the default behavior.
"auto" selects between low and high power states based on the whether the system
is on battery power or not.  Even lower power states are selected when the monitors
are in the dpms off state.
"low" forces the gpu to be in the low power state all the time.  Even lower power
states are selected when the monitors are in the dpms off state.
"high" forces the gpu to be in the high power state all the time.  Even lower power
states are selected when the monitors are in the dpms off state.

The "profile" method is not as agressive as "dynpm," but is currently much more
stable and flicker free and works with multiple heads active.

The default power management method is "profile" using the "default" profile.
The default should eventaully be changed to "profile" "auto".

For upstream, we may want to squash some of these.  I'm open to suggestions.
Everthing that's been added since drm-linus?

Alex


More information about the dri-devel mailing list