drm/radeon/dpm: resume fixes for some systems

Setting the power state prior to restoring the display
hardware leads to blank screens on some systems.  Drop
the power state set from dpm resume.  The power state
will get set as part of the mode set sequence.  Also
add an explicit power state set after mode set resume
to cover PX and headless systems.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=76761

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/crtc-helper: skip locking checks in panicking path

Skip locking checks in drm_helper_*_in_use() if they are called in panicking
path. See similar code in drm_warn_on_modeset_not_all_locked().

After panic information has been output, these WARN_ONs go off outputing a lot
of lines and scrolling the panic information out of the screen. Here is a
partial call trace showing how execution reaches them:

? drm_helper_crtc_in_use()
? __drm_helper_disable_unused_functions()
? several *_set_config functions
? drm_fb_helper_restore_fbdev_mode()

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/radeon: fix vm buffer size estimation

Only relevant if we got VM_BLOCK_SIZE>9, but better save than sorry.

Signed-off-by: Christian König <christian.koenig@amd.com>
drm/radeon: sync page table updates

Only necessary if we don't use the same engine for buffer moves and table updates.

Signed-off-by: Christian König <christian.koenig@amd.com>
drm/radeon: use the CP DMA on CIK

The SDMA sometimes doesn't seem to work reliable.

Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
intel_pstate: Remove C0 tracking

Commit fcb6a15c (intel_pstate: Take core C0 time into account for core
busy calculation) introduced a regression referenced below.  The issue
with "lockup" after suspend that this commit was addressing is now dealt
with in the suspend path.

Fixes: fcb6a15c2e7e (intel_pstate: Take core C0 time into account for core busy calculation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=66581
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75121
Reported-by: Doug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
intel_pstate: Correct rounding in busy calculation

Changing to fixed point math throughout the busy calculation in
commit e66c1768 (Change busy calculation to use fixed point
math.) Introduced some inaccuracies by rounding the busy value at two
points in the calculation.  This change removes roundings and moves
the rounding to the output of the PID where the calculations are
complete and the value returned as an integer.

Fixes: e66c17683746 (intel_pstate: Change busy calculation to use fixed point math.)
Reported-by: Doug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
intel_pstate: add sample time scaling

The PID assumes that samples are of equal time, which for a deferable
timers this is not true when the system goes idle.  This causes the
PID to take a long time to converge to the min P state and depending
on the pattern of the idle load can make the P state appear stuck.

The hold-off value of three sample times before using the scaling is
to give a grace period for applications that have high performance
requirements and spend a lot of time idle,  The poster child for this
behavior is the ffmpeg benchmark in the Phoronix test suite.

Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
intel_pstate: Improve initial busy calculation

This change makes the busy calculation using 64 bit math which prevents
overflow for large values of aperf/mperf.

Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes

The first one is a one liner fixing a stupid typo in the VM handling code and is only relevant if play with one of the VM defines.

The other two switches CIK to use the CPDMA instead of the SDMA for buffer moves, as it turned out the SDMA is still sometimes not 100% reliable.

* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
  drm/radeon: use the CP DMA on CIK
  drm/radeon: sync page table updates
  drm/radeon: fix vm buffer size estimation
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "All fairly small: radeon stability and a panic path fix.

  Mostly radeon fixes, suspend/resume fix, stability on the CIK
  chipsets, along with a locking check avoidance patch for panic times
  regression"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: use the CP DMA on CIK
  drm/radeon: sync page table updates
  drm/radeon: fix vm buffer size estimation
  drm/crtc-helper: skip locking checks in panicking path
  drm/radeon/dpm: resume fixes for some systems
Merge tag 'pm-3.15-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull intel pstate fixes from Rafael Wysocki:
 "Final power management fixes for 3.15

   - Taking non-idle time into account when calculating core busy time
     was a mistake and led to a performance regression.  Since the
     problem it was supposed to address is now taken care of in a
     different way, we don't need to do it any more, so drop the
     non-idle time tracking from intel_pstate.  Dirk Brandewie.

   - Changing to fixed point math throughout the busy calculation
     introduced rounding errors that adversely affect the accuracy of
     intel_pstate's computations.  Fix from Dirk Brandewie.

   - The PID controller algorithm used by intel_pstate assumes that the
     time interval between two adjacent samples will always be the same
     which is not the case for deferable timers (used by intel_pstate)
     when the system is idle.  This leads to inaccurate predictions and
     artificially increases convergence times for the minimum P-state.
     Fix from Dirk Brandewie.

   - intel_pstate carries out computations using 32-bit variables that
     may overflow for large enough values of APERF/MPERF.  Switch to
     using 64-bit variables for computations, from Doug Smythies"

* tag 'pm-3.15-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  intel_pstate: Improve initial busy calculation
  intel_pstate: add sample time scaling
  intel_pstate: Correct rounding in busy calculation
  intel_pstate: Remove C0 tracking