More ATI Radeon KMS Power Management Fun

[phoronix]

Phoronix: More ATI Radeon KMS Power Management Fun

Power management support within the Linux kernel for the ATI Radeon DRM driver has been in development for months and gone through several revisions, but with the forthcoming Linux 2.6.34 kernel there is initial ATI KMS power management support. For making the power management situation even better, over the weekend Alex Deucher of AMD has been working on another set of patches...

http://www.phoronix.com/vr.php?view=ODA2Mw

[sylware]

How does it hook on Linux power management? Again, a super huge kernel abstraction kludge?

I thought that from R700, power/fan management is done throught the ATOM bios tables/byte cdoe???

[agd5f]

To enable the power management code, just pass dynpm=1 as a module parameter when you load radeon. The ATOM tables are used for changing the clocks and eventually the voltage, but the algorithms for when to change power modes has to be implemented in the driver. Also, fan control and temperature monitoring is not available via ATOM, the bios just sets up the initial state. For driver control, you need to actually write the code and wire it up to some interface like hwmon.

Right now the power management is all internal to the driver. there are no knobs exposed to userspace.

[sylware]

To enable the power management code, just pass dynpm=1 as a module parameter when you load radeon. The ATOM tables are used for changing the clocks and eventually the voltage, but the algorithms for when to change power modes has to be implemented in the driver.

You means that is not coupled properly with Linux power management internals? If you are still going the DRM kernel abstraction kludge, I bet power management abstraction code will be... well.. you guessed... (something like perl5's code... )

Also, fan control and temperature monitoring is not available via ATOM, the bios just sets up the initial state. For driver control, you need to actually write the code and wire it up to some interface like hwmon.

Hu? Need to backlog on radeon IRC channel. I remember bridgman telling me that from R7xx fan control and temperature monitoring is available through ATOM bios methods.

[RealNC]

How would one go and use this with kernel 2.6.33?

[agd5f]

You means that is not coupled properly with Linux power management internals? If you are still going the DRM kernel abstraction kludge, I bet power management abstraction code will be... well.. you guessed... (something like perl5's code... )

What Linux power management internals are you referring to? CPU governors are not a good fit for GPUs. The thermal monitoring and fan control chips could be hooked into the hwmon interface, but support for that isn't written yet. Plus, the hwmon stuff really only exposes knobs to userspace. Last I checked, it didn't really provide an interface for other kernel internals (like the drm) to use the data.

What are you referring to as the drm "kludge"? Currently the driver changes the power state on the fly based on the GPU load and display conditions which only the driver is capable of knowing. How is this a kludge?

Hu? Need to backlog on radeon IRC channel. I remember bridgman telling me that from R7xx fan control and temperature monitoring is available through ATOM bios methods.

Nope. There are not any atom command tables to do this. There are command tables for changing the clocks and setting up the initial thermal profile, perhaps that is what you were thinking of.

[bridgman]

Hu? Need to backlog on radeon IRC channel. I remember bridgman telling me that from R7xx fan control and temperature monitoring is available through ATOM bios methods.

Are you sure ? I remember saying that the information was in AtomBIOS (data tables describing the hardware and how it is connected/accessed) but don't remember saying it was accessed through methods aka command tables.

[sylware]

What Linux power management internals are you referring to?

In pm.h:

struct dev_pm_ops {
  int (*prepare)(struct device *dev);
  void (*complete)(struct device *dev);
  int (*suspend)(struct device *dev);
  int (*resume)(struct device *dev);
  int (*freeze)(struct device *dev);
  int (*thaw)(struct device *dev);
  int (*poweroff)(struct device *dev);
  int (*restore)(struct device *dev);
  int (*suspend_noirq)(struct device *dev);
  int (*resume_noirq)(struct device *dev);
  int (*freeze_noirq)(struct device *dev);
  int (*thaw_noirq)(struct device *dev);
  int (*poweroff_noirq)(struct device *dev);
  int (*restore_noirq)(struct device *dev);
  int (*runtime_suspend)(struct device *dev);
  int (*runtime_resume)(struct device *dev);
  int (*runtime_idle)(struct device *dev);
};

And of course the /sys user space nobs.

Abstracting all that for:
- Windows
- MacOSX
- *BSD
- Linux
will very probably end up as a kludge (common sense).

...and setting up the initial thermal profile...

In my mind, settings up thermal profile means ATOM is able to setup power states and fan speed, doesn't it?

Are you sure ? I remember saying that the information was in AtomBIOS (data tables describing the hardware and how it is connected/accessed) but don't remember saying it was accessed through methods aka command tables.

Well, as far as I can remember, I think I understood it that way.

[agd5f]

In pm.h:

struct dev_pm_ops {
  int (*prepare)(struct device *dev);
  void (*complete)(struct device *dev);
  int (*suspend)(struct device *dev);
  int (*resume)(struct device *dev);
  int (*freeze)(struct device *dev);
  int (*thaw)(struct device *dev);
  int (*poweroff)(struct device *dev);
  int (*restore)(struct device *dev);
  int (*suspend_noirq)(struct device *dev);
  int (*resume_noirq)(struct device *dev);
  int (*freeze_noirq)(struct device *dev);
  int (*thaw_noirq)(struct device *dev);
  int (*poweroff_noirq)(struct device *dev);
  int (*restore_noirq)(struct device *dev);
  int (*runtime_suspend)(struct device *dev);
  int (*runtime_resume)(struct device *dev);
  int (*runtime_idle)(struct device *dev);
};

And of course the /sys user space nobs.

Abstracting all that for:
- Windows
- MacOSX
- *BSD
- Linux
will very probably end up as a kludge (common sense).

The drm already hooks in suspend and resume functions which are mainly what those are for. There aren't any common dynamic power management interfaces as far as I know because it tends to be device, or at least subsystem specific (i.e., USB power saving stuff). Perhaps we could implement some common drm dynamic pm functionality once some other drm drivers add similar features.

In my mind, settings up thermal profile means ATOM is able to setup power states and fan speed, doesn't it?

It loads the profile as part of asic init, however, there are no tables to query the temp or fan speed. Those need to be implemented by the driver.

Well, as far as I can remember, I think I understood it that way.

Well, for the record, there are no command tables to query that information. You can view the full list of command and data tables in atombios.h

[sylware]

The drm already hooks in suspend and resume functions which are mainly what those are for. There aren't any common dynamic power management interfaces as far as I know because it tends to be device, or at least subsystem specific (i.e., USB power saving stuff). Perhaps we could implement some common drm dynamic pm functionality once some other drm drivers add similar features.

Well, you mean having a non-sysfs power management interface like all the other sub-systems. So you would have a generalized DRM interface which generates proper sysfs entries on Linux and whatever are the proper interfaces on other kernels (window,MacOS,*BSD...).
I don't know, but does the DRM power management driver interface allow proper use of pm.h? Personnally, I doubt it. And imagining code that will cleanly fit all the other kernels power management interface at the same time... sorry I don't buy it: it will be kludgy naughty code. I don't even think it will fit the "quality requiered" to get into *BSD kernels.

For me it's masochistic and a dangerous path.

Let me add a layer on top of it: a generalized instrumentation framework for performance measurements that will fit the native instrumentation interfaces of all kernels?

All that kernel abstraction stuff seems quite unreasonable, but I think you got my point.

It loads the profile as part of asic init, however, there are no tables to query the temp or fan speed. Those need to be implemented by the driver.
Well, for the record, there are no command tables to query that information. You can view the full list of command and data tables in atombios.h

Well that one is for me... "one day" I might have brain time to dive for good into AMD GPU driver code... to avoid such questions.