Convert drivers/gpu/drm class to use dev_pm_ops for power management and
remove Legacy PM ops hooks. With this change, drm class registers
suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy
class->suspend/resume. When __device_suspend() runs call-backs, it will
find class->pm ops for the drm class.

drm_class_suspend() hook calls driver legacy ops with the state information.
e.g: drm_class_suspend() calls into driver suspend routines
via drm_dev->driver->suspend(drm_dev, state).

Once drm_class_suspend() is converted to dev_pm_ops, it will no longer
have access to pm_transition which it has to pass into driver legacy
suspend calls. A new freeze and suspend hooks are added to address the not
having access to the state information. The new freeze and suspend hooks
simply call __drm_class_suspend() with the appropriate pm state information.
__drm_class_suspend() is the original suspend hook with a new name.
Signed-off-by: NShuah Khan <shuah.kh@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Merge tag 'drm-intel-fixes-2013-07-03' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Pile of fixes for 3.11. A bit large in patch count, but that's simply due
to two fixes being split up into really small parts. Also I've included a
few more vlv patches than I'd have included for other platforms. But since
vlv is officially supported for the first time only in 3.11 that shouldn't
result in unbearable risks.

Highlights:
- ghost eDP fixes for hsw from Paulo
- fix PCH detection in virtualized enviroments (Rui Guo)
- duct-tape dma sg construction when swiotlb is in use (Konrad), dupe with
  a patch in your drm-fixes branch
- fix sdvo hotplug on i965g
- tune down a bunch of dmesg ERRORs which can be hit under normal
  conditions
- detect invalid pitches for tiled scanout buffers (Chris)
- a pile of vlv fixes from Ville: rps improvements, fixes for the dpll
  LPF, fixup the sprite mmio offsets
- fix context size on hsw (Ben)
- locking fixes for the hotplug code, specifically the storm handling
- fix get_config on CPT (Xiong Zhang)
- Fix the domain tracking when an unlocked seqno wait was interrupt
  (Chris), this seems to explain tons of little corruption bugs in the
  ddx. Chris also added a nice igt to exercise this.
- work around stack-corrupting vnsprintf in our error state dumper

* tag 'drm-intel-fixes-2013-07-03' of git://people.freedesktop.org/~danvet/drm-intel: (39 commits)
  drm/i915: Don't try to tear down the stolen drm_mm if it's not there
  drm/i915: Break up the large vsnprintf() in print_error_buffers()
  drm/i915: Refactor the wait_rendering completion into a common routine
  drm/i915: Only clear write-domains after a successful wait-seqno
  drm/i915: correct intel_dp_get_config() function for DevCPT
  drm/i915: fix hpd interrupt register locking
  drm/i915: fold the no-irq check into intel_hpd_irq_handler
  drm/i915: fold the queue_work into intel_hpd_irq_handler
  drm/i915: fold the hpd_irq_setup call into intel_hpd_irq_handler
  drm/i915: s/hotplug_irq_storm_detect/intel_hpd_irq_handler/
  drm/i915: close tiny race in the ilk pcu even interrupt setup
  drm/i915: fix locking around ironlake_enable|disable_display_irq
  drm/i915: Fix context sizes on HSW
  drm/i915: Fix VLV sprite register offsets
  Revert "drm/i915: Don't use the HDMI port color range bit on Valleyview"
  drm/i915: s/LFP/LPF in DPIO PLL register names
  drm/i915: Fix VLV PLL LPF coefficients for DAC
  drm/i915: Jump to at least RPe on VLV when increasing the GPU frequency
  drm/i915: Don't increase the GPU frequency from the delayed VLV rps timer
  drm/i915: GEN6_RP_INTERRUPT_LIMITS doesn't seem to exist on VLV
  ...

A few more DPM fixes.

* 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon/sumo: implement support for disable_gfx_power_gating_in_uvd flag
  drm/radeon/tn: disable PG when changing UVD clocks
  drm/radeon/sumo: disable PG when changing UVD clocks
  drm/radeon/aruba: disable additional rlc features
  drm/radeon: fix endian bug in radeon_atom_get_mclk_range_table()
  drm/radeon/dpm: fix compilation with certain versions of gcc
  drm/radeon/dpm: clarify debugfs warning

The usual drm driver has tons of different drm_mm memory managers so the drm
error message in dmesg is pretty useless. WARN instead so that we have the full
backtrace.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In

commit 3a359f0b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Apr 20 12:08:11 2013 +0200

    drm/mm: fix dump table BUG

I've failed to fix both instances of the regression introduced in

commit 9e8944ab
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 15 11:32:17 2012 +0000

   drm: Introduce an iterator over holes in the drm_mm range manager

Patch this up in the same way by extracting the hole debug logic
into it's own function, since that'll also clarify the logic a bit.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In

commit da34242e
Author: YoungJun Cho <yj44.cho@samsung.com>
Date:   Wed Jun 26 10:21:42 2013 +0900

    drm/prime: add return check for dma_buf_fd

the failure case handling was fixed up. But in the case when we
already had the buffer exported it changed the return value:
Previously we've return 0 on success, now we return the fd.

This ABI change has been caught by i-g-t/prime_self_import/with_one_bo.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
Cc: YoungJun Cho <yj44.cho@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Nlu hua <huax.lu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NYoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some asic revisions need to disable PG when UVD is active.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Causes hangs for some people.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Causes hangs for some people.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

They cause problems with dynamic clocking.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add #include <linux/seq_file.h> to *_dpm.c files
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For chips without debugfs dpm support say that it's not
implemented rather than not supported to avoid confusion
about DPM support in general.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Every other place properly checks whether we've managed to set
up the stolen allocator at boot-up properly, with the exception
of the cleanup code. Which results in an ugly

*ERROR* Memory manager not clean. Delaying takedown

at module unload time since the drm_mm isn't initialized at all.

v2: While at it check whether the stolen drm_mm is initialized instead
of the more obscure stolen_base == 0 check.

v3: Fix up the logic. Also we need to keep the stolen_base check in
i915_gem_object_create_stolen_for_preallocated since that can be
called before stolen memory is fully set up. Spotted by Chris Wilson.

v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
allocatot must already be initialized when calling that function (if
we indeed have stolen memory).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: lu hua <huax.lu@intel.com> (v3)
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is no reason to return "int" as this function never fails.
Furthermore, several drivers (ast, sis) already depend on this.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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.

* 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon/dpm: add debugfs support for SI
  drm/radeon/dpm: add debugfs support for cayman
  drm/radeon/dpm: add debugfs support for TN
  drm/radeon/dpm: add debugfs support for ON/LN
  drm/radeon/dpm: add debugfs support for 7xx/evergreen/btc
  drm/radeon/dpm: add debugfs support for rv6xx
  drm/radeon/dpm: add infrastructure to support debugfs info
  drm/radeon/dpm: re-enable state transitions for Cayman
  drm/radeon/dpm: re-enable state transitions for BTC
  drm/radeon: fix typo in radeon_atom_init_mc_reg_table()
  drm/radeon/atom: fix endian bug in radeon_atom_init_mc_reg_table()
  drm/radeon: remove sumo dpm/uvd bringup leftovers

This allows you to look at the current DPM state via
debugfs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This allows you to look at the current DPM state via
debugfs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This allows you to look at the current DPM state via
debugfs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This allows you to look at the current DPM state via
debugfs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This allows you to look at the current DPM state via
debugfs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This allows you to look at the current DPM state via
debugfs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This lays the frameworks to report realtime power level
feedback.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Was disabled due to stability issues on certain boards
caused by the a bug in the parsing of the atom mc reg tables.
That's fixed now so re-enable.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Was disabled due to stability issues on certain boards
caused by the a bug in the parsing of the atom mc reg tables.
That's fixed now so re-enable.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Bad pointer math.  Fixes hangs in state transitions with
BTC+ asics.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Function doesn't do anything useful.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

So it appears that I have encountered some bogosity when trying to call
i915_error_printf() with many arguments from print_error_buffers(). The
symptom is that the vsnprintf parser tries to interpret an integer arg
as a character string, the resulting OOPS indicating stack corruption.
Replacing the single call with its 13 format specifiers and arguments
with multiple calls to i915_error_printf() worked fine. This patch goes
one step further and introduced i915_error_puts() to pass the strings
simply.

It may not fix the root cause, but it does prevent my box from dying and
I think helps make print_error_buffers() more friendly.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66077
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Harmonise the completion logic between the non-blocking and normal
wait_rendering paths, and move that logic into a common function.

In the process, we note that the last_write_seqno is by definition the
earlier of the two read/write seqnos and so all successful waits will
have passed the last_write_seqno. Therefore we can unconditionally clear
the write seqno and its domains in the completion logic.

v2: Add the missing ring parameter, because sometimes it is good to have
things compile.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the introduction of the non-blocking wait, I cut'n'pasted the wait
completion code from normal locked path. Unfortunately, this neglected
that the normal path returned early if the wait returned early. The
result is that read-only waits may return whilst the GPU is still
writing to the bo.

Fixes regression from
commit 3236f57a [v3.7]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 24 09:35:09 2012 +0100

    drm/i915: Use a non-blocking wait for set-to-domain ioctl
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On DevCPT, the control register for Transcoder DP Sync Polarity is
TRANS_DP_CTL, not DP_CTL.
Without this patch, Many call trace occur on CPT machine with DP monitor.
The call trace is like: *ERROR* mismatch in adjusted_mode.flags(expected X,found X)

v2: use intel-crtc to simple patch, suggested by Daniel.
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
[danvet: Extend the encoder->get_config comment to specify that we now
also depend upon intel_encoder->base.crtc being correct. Also bikeshed
s/intel_crtc/crtc/.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65287Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Our interrupt handler (in hardirq context) could race with the timer
(in softirq context), hence we need to hold the spinlock around the
call to ->hdp_irq_setup in intel_hpd_irq_handler, too.

But as an optimization (and more so to clarify things) we don't need
to do the irqsave/restore dance in the hardirq context.

Note also that on ilk+ the race isn't just against the hotplug
reenable timer, but also against the fifo underrun reporting. That one
also modifies the SDEIMR register (again protected by the same
dev_priv->irq_lock).

To lock things down again sprinkle a assert_spin_locked. But exclude
the functions touching SDEIMR for now, I want to extract them all into
a new helper function (like we do already for pipestate, display
interrupts and all the various gt interrupts).

v2: Add the missing 't' Egbert spotted in a comment.

v3: Actually fix the right misspelled comment (Paulo).

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The usual pattern for our sub-function irq_handlers is that they check
for the no-irq case themselves. This results in more streamlined code
in the upper irq handlers.

v2: Rebase on top of the i965g/gm sdvo hpd fix.

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Everywhere the same.

Note that this patch leaves unnecessary braces behind, but the next
patch will kill those all anyway (including the if itself) so I've
figured I can keep the diff a bit smaller.

v2: Rebase on top of the i965g/gm sdvo hpd fix.

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already have a vfunc for this (and other parts of the hpd storm
handling code already use it).

v2: Rebase on top of the i965g/gm sdvo hpd fix.

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The combination of Paulo's fifo underrun detection code and Egbert's
hpd storm handling code unfortunately made the hpd storm handling code
racy.

To avoid duplicating tricky interrupt locking code over all platforms
start with a bit of refactoring. This patch is the very first step
since in the end the irq storm handling code will handle all hotplug
logic (and so also encapsulate the locking nicely).

v2: Rebase on top of the i965g/gm sdvo hpd fix.

Cc: Egbert Eich <eich@suse.de>
Reviewed-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By the time we write DEIER in the postinstall hook the interrupt
handler could run any time. And it does modify DEIER to handle
interrupts.

Hence the DEIER read-modify-write cycle for enabling the PCU event
source is racy. Close this races the same way we handle vblank
interrupts: Unconditionally enable the interrupt in the IER register,
but conditionally mask it in IMR. The later poses no such race since
the interrupt handler does not touch DEIMR.

Also update the comment, the clearing has already happened
unconditionally above.

v2: Actually shove the updated comment into the right train^W commit,
as spotted by Paulo.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The haswell unclaimed register handling code forgot to take the
spinlock. Since this is in the context of the non-rentrant interupt
handler and we only have one interrupt handler it is sufficient to
just grab the spinlock - we do not need to exclude any other
interrupts from running on the same cpu.

To prevent such gaffles in the future sprinkle assert_spin_locked over
these functions. Unfornately this requires us to hold the spinlock in
the ironlake postinstall hook where it is not strictly required:
Currently that is run in single-threaded context and with userspace
exlcuded from running concurrent ioctls. Add a comment explaining
this.

v2: ivb_can_enable_err_int also needs to be protected by the spinlock.
To ensure this won't happen in the future again also sprinkle a
spinlock assert in there.

v3: Kill the 2nd call to ivb_can_enable_err_int I've accidentally left
behind, spotted by Paulo.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: NPaulo Zanoni <przanoni@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With updates to the spec, we can actually see the context layout, and
how many dwords are allocated. That table suggests we need 70720 bytes
per HW context. Rounded up, this is 18 pages. Looking at what lives
after the current 4 pages we use, I can't see too much important (mostly
it's d3d related), but there are a couple of things which look scary. I
am hopeful this can explain some of our odd HSW failures.

v2: Make the context only 17 pages. The power context space isn't used
ever, and execlists aren't used in our driver, making the actual total
66944 bytes.

v3: Add a comment to the code. (Jesse & Paulo)
Reported-by: N"Azad, Vinit" <vinit.azad@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>