[pull] radeon drm-next-3.11

[Alex Deucher]

On Wed, Jul 3, 2013 at 2:39 AM, Ruslan N. Marchenko <rufferson at gmail.com> wrote:
> Am 01.07.2013 23:01, schrieb alexdeucher at gmail.com:
>>
>> From: Alex Deucher<alexander.deucher at amd.com>
>>
>> Hi Dave,
>>
>> A few more patches for 3.11:
>> - add debugfs interface to check current DPM state
>> - Fix a bug that caused problems with DPM on BTC+ asics.
>>
>> The following changes since commit
>> f7d452f4fd5d86f764807a1234a407deb5b105ef:
>>
>>    Merge branch 'drm-nouveau-next' of
>> git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
>> (2013-07-01 14:10:20 +1000)
>>
>> are available in the git repository at:
>>
>>    git://people.freedesktop.org/~agd5f/linux drm-next-3.11
>>
>> Alex Deucher (12):
>>        drm/radeon: remove sumo dpm/uvd bringup leftovers
>>        drm/radeon/atom: fix endian bug in radeon_atom_init_mc_reg_table()
>>        drm/radeon: fix typo in radeon_atom_init_mc_reg_table()
>>        drm/radeon/dpm: re-enable state transitions for BTC
>>        drm/radeon/dpm: re-enable state transitions for Cayman
>>        drm/radeon/dpm: add infrastructure to support debugfs info
>>        drm/radeon/dpm: add debugfs support for rv6xx
>>        drm/radeon/dpm: add debugfs support for 7xx/evergreen/btc
>>        drm/radeon/dpm: add debugfs support for ON/LN
>>        drm/radeon/dpm: add debugfs support for TN
>>        drm/radeon/dpm: add debugfs support for cayman
>>        drm/radeon/dpm: add debugfs support for SI
>>
>>   drivers/gpu/drm/radeon/btc_dpm.c         |    3 --
>>   drivers/gpu/drm/radeon/ni_dpm.c          |   25 +++++++++++++---
>>   drivers/gpu/drm/radeon/nid.h             |    4 ++
>>   drivers/gpu/drm/radeon/radeon.h          |    2 +
>>   drivers/gpu/drm/radeon/radeon_asic.c     |    8 +++++
>>   drivers/gpu/drm/radeon/radeon_asic.h     |   12 ++++++++
>>   drivers/gpu/drm/radeon/radeon_atombios.c |    3 +-
>>   drivers/gpu/drm/radeon/radeon_pm.c       |   40
>> ++++++++++++++++++--------
>>   drivers/gpu/drm/radeon/rv6xx_dpm.c       |   25 ++++++++++++++++
>>   drivers/gpu/drm/radeon/rv770_dpm.c       |   30 ++++++++++++++++++++
>>   drivers/gpu/drm/radeon/rv770d.h          |    4 ++
>>   drivers/gpu/drm/radeon/si_dpm.c          |   19 ++++++++++++
>>   drivers/gpu/drm/radeon/sid.h             |    4 ++
>>   drivers/gpu/drm/radeon/sumo_dpm.c        |   45
>> ++++++++++++++++++-----------
>>   drivers/gpu/drm/radeon/trinity_dpm.c     |   21 ++++++++++++++
>>   15 files changed, 206 insertions(+), 39 deletions(-)
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> This is really excellent and very wanted addition to the radeon, a huge
> thanks Alex for giving a second life to my old TimelineX with hybrid
> AMD/Intel graphics. Intel ironlake became a bit outdated already but with
> ATi HD 5650 I was able to drink tee all day long since it never came lower
> than 90 degrees Celsius.   Now it comfortably sits at 55-60 so I can use it
> back again.
>
> As I noticed it supports now either dynpm or profile method of clocking,
> however profiles themselves also have several (3) power states. Also during
> init phase it writes that it switching from boot to performance profile - so
> what exactly is the difference between dpm and profile method? Will dynpm
> react to ACPI events like lid closed or AC offline or I better to add calls
> to acpid event handlers to tweak the profiles/methods?

With with the old profile/dynpm methods, the driver was responsible
for changing the power states.  With dpm, there is dedicated hardware
on the GPU that automatically changes the power levels based on GPU
load.  E.g., when you have an idle desktop, the hw will put the gpu
into the lowest power level, when you start to use the 3D engine,
etc., it will automatically switch the GPU into higher power levels.
With dpm you can also manually switch between performance and battery
states.  Both states will automatically switch between power levels,
but the battery state generally has a narrower range of power levels.
The driver could automatically transition based on acpi events (there
was an option do to that with the old profile method), but that's not
currently hooked up and that's more of a policy choice, so it seems
like something that would be better handled in userspace (e.g., you
may want to use the performance state even when ac is offline or you
may want to use the battery state when AC is connected, etc.).

Alex