Here is a very informative e-mail from Alex Deucher that clarifies the situation:

Deucher, Alexander wrote:
>   The problem with power management is that it's involved with just
> about every aspect of the driver, as such it's not a simple
> implementation.  To do it properly, it really has to be done in the new
> kernel modesetting enabled (kms) drm since that would know the state of
> not only the command stream but also the displays.
> 
> The current driver architecture it not well suited to power management
> and most of what we do now would be a hack and would have to be re-done
> properly once the kms drm is ready.  example, if you want to scale the
> memory clocks, you need to make sure you still provide enough bandwidth
> for the displays (single vs. multi-head, etc.) and enough bandwidth for
> the drawing engine (texture fetches, vertex buffers, command buffers,
> etc.).  Or if you are playing back a video, you'll want to scale the
> memory clock and pcie lanes enough to provide enough bandwidth for the
> video playback, but also reduce power usage if possible; same for engine
> clock.  You'll want to reduce that to save power, but still leave it
> high enough to render the frame without raising the latency too much.
> Adjusting the voltage has similar requirements.  The problem with the
> current driver setup is that that X driver is only aware of the displays
> and 2D (EXA, XV), but not 3D.  To be done right, the driver would need
> insight into the incoming command stream and the displays which is
> currently only possible in the kms enabled drm.
> 
> In addition to the above requirement, X lacks a generic driver attribute
> system that can be changed dynamically.  There are interfaces like
> xrandr and Xv attributes, but they for displays and Xv respectively, not
> general driver attributes.  In order to change the power profile on the
> fly you'd need some sort of dynamic interface.  The drm could expose it
> via sysfs for example.  Then applications like gnome-power-manager could
> dynamically change the power profile (AC/DC transition, user selected
> power profile, etc.).
> 
> The information to implement most power management features is already
> available.  The radeon driver in git has code to change the engine and
> memory clocks of both atombios-based (r4xx-r7xx) and pre-atom-based
> cards (r1xx-r3xx) as well as adjusting the number of pcie lanes
> (r3xx-r7xx).
> 
> Things like fan control and temperature readings (if available) are
> implemented via third party chips controlled via i2c at least for
> pre-r6xx chips.  The power mode data table information in atombios.h in
> the radeon/radeonhd drivers have everything you'd need to implement
> support for these chips (other than documentation on the third party
> chips themselves which in most cases is available from the third party).
> The data table will tell you what chips are present and the gpio info
> needed to access the chips via i2c.  In many cases there may already be
> i2c chip drivers for some of the third party chips in the kernel as part
> of lmsensors, etc.  Integrating properly with lmsensors is another
> reason this should be done in the drm rather than in the radeon xorg
> driver.  For some r6xx and newer chips, some of the functionality has
> moved on chip, but we are still sorting out information on that
> interface.
> 
> In the next major release of the radeon driver, the basic power
> management features you mentioned below will be available as driver
> options and we will probably see some other improvements as well.
> However, full-blown power management will probably only be available in
> the kms enabled drm.  There is enough information available already to
> implement decent power management, but we are currently limited by
> driver infrastructure and developer man power.