Bug 21678

Summary: -radeon open source driver always run fans at full speed for modern cards
Product: xorg Reporter: martin <mnemo>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: 7.4 (2008.09)   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description martin 2009-05-11 07:13:53 UTC
I'm filing this bug upstream on behalf of another Ubuntu user.
The original downstream bug report is here:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/373669

It seems that several Ubuntu users are unable to use the -ati
driver because (even they accept not having 3D at the moment)
there is no power management for modern ATI cards and so basically
their GPU fans run all 100% speed all the time (very noisy).

One AMD/ATI card affected by this problem is for example:
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Mobility Radeon HD 3400 Series [1002:95c4]
...using the driver that the user had was 6.12.1 (shipped in ubuntu 9.04)
Comment 1 martin 2009-05-11 09:14:00 UTC
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.
Comment 2 madbiologist 2010-03-13 04:57:15 UTC
The Linux kernel 2.6.34-rc1 has recently been released.  It contains support for Radeon KMS (kernel mode-setting) power management.  More details on this kernel are available at http://www.phoronix.com/scan.php?page=news_item&px=ODA0OQ

An Ubuntu PPA of this kernel is available at http://kernel.ubuntu.com/~kernel-ppa/mainline/

For other distributions the kernel page is at http://www.kernel.org/
Comment 3 Alex Deucher 2010-10-19 17:21:37 UTC
See the bottom of this page for more info on KMS power management options:
http://wiki.x.org/wiki/RadeonFeature

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.