Calling intel_runtime_pm_put() is illegal from a soft-irq context, so
revert the crude hack

commit aa0b3b5b
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Apr 1 14:55:07 2014 -0300

    drm/i915: don't schedule force_wake_timer at gen6_read

and apply the single line corrective instead.

v2: assert forcewake is off after the forcewake_reset (Paulo)

References: https://bugs.freedesktop.org/show_bug.cgi?id=80913
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will be needed by later patches, so factor it out.

No functional change.

v2:
- s/dev_to_i915_priv/dev_to_i915/ (Jani)
- don't use the helper in i915_pm_suspend (Chris)
- simplify the helper (Chris)
v3:
- remove redundant upcasting in the helper (Daniel)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 355a7018.

This had some bad side effects under normal operation, and should
have been dropped earlier.
Signed-off-by: NDave Airlie <airlied@redhat.com>

With cherryview onwards, Gunit hardware itself save and restore all the
Gunit registers. Skipping the "vlv_save_gunit_s0ix_state" &
"vlv_restore_gunit_s0ix_state" for cherryview in S3/S0ix sequence.
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm, we don't disable RPS interrupts and related work items before
resetting the GPU. This may interfere with the following GPU
initialization and cause RPS interrupts to show up in PM_IIR too early
before calling gen6_enable_rps_interrupts() (triggering a WARN there).

Solve this by disabling RPS interrupts and flushing any related work
items before resetting the GPU.

v2:
- split out the common parts of the gt suspend and the new gt reset
  functions (Paulo)
v3:
- remove the check for UMS, it's a NOP nowadays (Daniel)
Reported-by: NHe, Shuang <shuang.he@intel.com>
Testcase: igt/gem_reset_stats/ban-render
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86644Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Otherwise the MST resume paths can hit DPMS paths
which hit state checker paths, which hit WARN_ON,
because the state checker is inconsistent with the
hw.

This fixes a bunch of WARN_ON's on resume after
undocking.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Clear the video overlay state on GPU reset. Any pending overlay request
in the ring has been nuked, and the display itself gets reset. So we
pretty much lose all state here. Adjust the software state to match so
that the next "putimage" will restore things to working order.

v2: Ass a locking check into intel_overlay_release_old_vid() (Daniel)

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/0/NULL/ to appease sparse, reported by 0-day tester.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On gen4 and earlier the GPU reset also resets the display, so we should
protect against concurrent modeset operations. Grab all the modeset locks
around the entire GPU reset dance, remebering first ti dislogde any
pending page flip to make sure we don't deadlock. Any pageflip coming
in between these two steps should fail anyway due to reset_in_progress,
so this should be safe.

This fixes a lot of failed asserts in the modeset code when there's a
modeset racing with the reset. Naturally the asserts aren't happy when
the expected state has disappeared.

v2: Drop UMS checks, complete pending flips after the reset (Daniel)

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

g33 seems to sit somewhere between the 915/945/965 style and the
g4x style. The bits look like g4x, but we still need to do a full
reset including display.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

915/945 have the same reset registers as 965, so share the code.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On pre-ctg GPU reset also resets the display hardware. Force a mode
restore after the GPU reset, and also re-init clock gating.

v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating()
    in case more relevant stuff gets added there at some point
    Restore interrupts after the reset as well
Tested-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.

This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.

v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Again just complicates gem init functions and makes a general mess out
of everything.

Good riddance!

v2: In my enthusiasm to start removing dri1/ums crud I went overboard a
bit and killed parts of hangcheck. Resurrect it.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

With the deprecation of UMS, and by association DRI1, we have a tough
choice when updating the ring access routines. We either rewrite the
DRI1 routines blindly without testing (so likely to be broken) or take
the liberty of declaring them no longer supported and remove them
entirely. This takes the latter approach.

v2: Also remove the DRI1 sarea updates
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Fix rebase conflicts.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

After the previous patch RPS disabling doesn't depend any more on the
first level interrupts being disabled, so we can move it everywhere
earlier. Doing so let's us think about the uninitialization steps
afterwards independently of any asynchronous RPS events that can happen
atm. It also makes the system/runtime suspend time RPS disabling more
uniform. Finally this gets rid of the WARN in
intel_suspend_gt_powersave(), which we can hit if a final RPS work runs
after we disabled the first level interrupts.

Testcase: igt/pm_rpm
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The block was added for spin_lock_irqsave flags, but since the locking
was converted to spin_lock_irq variant, the block is no longer needed.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With this patch, the RPS sequence for runtime suspend/resume is
exactly like the sequence for S3 suspend/resume:
 - flush_delayed_work(&dev_priv->rps.delayed_resume_work)
 - intel_runtime_pm_disable_interrupts()
 - intel_suspend_gt_powersave()
   (suspended)
 - intel_runtime_pm_enable_interrupts()
 - intel_enable_gt_powersave()

With this, we get rid of WARNs that are currently intermittently
triggered by the system-suspend-execbuf subtest of runtime PM. Notice
that these WARNs could also be triggered in other ways that involved
doing lots of RPM suspend/resume cycles just after a system S3 resume.

Testcase: igt/pm_rpm/system-suspend-execbuf
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During S4 freeze we don't call intel_suspend_complete(), which would
save the gunit HW state, but during S4 thaw/restore events we call
intel_resume_prepare() which restores it, thus ending up in a corrupted
HW state.

Fix this by calling intel_suspend_complete() from the corresponding
freeze_late event handler.

The issue was introduced in
commit 016970be
Author: Sagar Kamble <sagar.a.kamble@intel.com>
Date:   Wed Aug 13 23:07:06 2014 +0530

CC: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We want to run intel_uncore_early_sanitize() before we touch any
registers, because on BDW, when we resume, the FPGA_DBG_RM_NOCLAIM bit
is set, so we need to clear it - through intel_uncore_early_sanitize()
- before we do anything else. With the current code, we don't clear
the bit before our first register access, so we print a WARN
complaining about an unclaimed register error.

v1: Was called "drm/i915: run intel_uncore_early_sanitize earlier on
resume"
v2: Was called "drm/i915: run intel_uncore_early_sanitize earlier on
resume on non-VLV"
v3: This one, on top of the intel_resume_prepare() rework.
v4: Rebase.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because, really, the abstraction is not working for us. It is nice for
VLV, but doesn't add anything useful on SNB/HSW/BDW. We want to change
this code due to a recently-discovered bug, but we can't seem to find
a nice solution that repects the current abstraction. So let's kill
intel_resume_prepare() and its friends, and add an equivalent
implementation to both its callers.

Also, look at the diffstat!

v2: - Rebase.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will hopefully make it easier to navigate the code without the need
to consult the full PM documentation.

v2:
- add a comment that the freeze handler is also called after rebooting
- add a comment that the thaw handler is also called to recover from
  errors (Ville)
- add the PM event names (PMSG_THAW etc.) for reference (Ville)
- add comments that s0ix can be handled both via system and runtime
  suspend (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By now we handle switcheroo and legacy suspend/resume the same way, so
no need to keep separate functions for them.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The suspend_late handler saves some registers and powers off the device,
so it doesn't have a big overhead. Calling it at S4 poweroff_late time
makes the power off handling identical to the S3 suspend and S4 freeze
handling, so do this for consistency.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By now the S4 freeze/thaw and S3 suspend/resume events are handled the
same way, so we can rename the freeze/thaw internal helpers to
suspend/resume accordingly to make clearer what the helpers do. Also
rename i915_resume_early to i915_drm_resume_early aligning it with the
rest of the helper names.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The S3 and S4 events are now handled the same way internally, there is no
need to keep separate wrapper functions around them. Simply reuse the
suspend/resume versions everywhere.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already disable everything during S4 freeze, except the PCI device
itself. There is no reason why we couldn't disable that too and doing
so allows us to unify these handlers in the next patch with the
corresponding S3 suspend/resume handlers.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To avoid processing hotplug events we disable connector polling for the
duration of S3 suspend. We also disable it for S4 freeze, and keep it
disabled after S4 thaw. This won't prevent though hotplug processing,
since we re-enable interrupts anyway. There is also no need to prevent
it at that time, since we reinitialize everything during thaw, so the
device is in a consistent state. So to simplify things enable polling
during thaw, which will allow us to handle S4 thaw the same way as S3
resume in an upcoming patch.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Checking for GT faults is not specific in any way to S4 thaw, so do it
also during S3 resume, S4 restore and driver load time. This allows us to
unify the Sx handlers in an upcoming patch.

v2:
- move the check to intel_uncore_early_sanitize(), so we check at driver
  load time too (Chris)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The logic to skip restoring GTT mappings was added to speed up
suspend/resume, but not on old GENs where not restoring them caused
problems. The check for old GENs is based on the existence of OpRegion,
but this doesn't work since opregion is initialized only after
the check. So we end up always restoring the mappings.

On my BYT - which has OpRegion - skipping restoring the mappings during
suspend doesn't work, I get a GPU hang after resume. Also the logic of
when to allow the optimization during S4 is reversed: we should allow it
during S4 thaw but not during S4 restore, but atm we have it the other
way around in the code.

Since correctness wins over optimal code and since the optimization
wasn't used anyway I decided not to try to fix it at this point, but
just remove it. This allows us to unify the S3 and S4 handlers in the
following patches.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the device is suspended already through the switcheroo interface we
shouldn't suspend it again or resume it after suspend. We have the
corresponding check for S3 suspend already, add it for all the other
S3 and S4 handlers. Also move the check from i915_resume_early() to
i915_resume_legacy(), so that it's done in the high level handler for
all PM events.

v2:
- fix the resume path too, we don't need to special case there
  DRM_SWITCH_POWER_OFF with the device being enabled (in which case we'd
  have to disable the device), since that never happens (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During switcheroo/legacy suspend we don't call the suspend_late handler
but when resuming afterwards we call resume_early. This happened to work
so far, since suspend_late only disabled the PCI device. This changed in

commit 016970be
Author: Sagar Kamble <sagar.a.kamble@intel.com>
Date:   Wed Aug 13 23:07:06 2014 +0530

    drm/i915: Sharing platform specific sequence between runtime and system susp

after which we also saved/restored the VLV Gunit HW state in
suspend_late/resume_early. So now since we don't save the state during
suspend a following resume will restore a corrupted state.

Fix this by calling the suspend_late handler during both switcheroo and
legacy suspend.

CC: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSagar Kamble <sagar.a.kamble@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

i915_suspend() is called from the DRM legacy S3 suspend/S4 freeze paths
and the switcheroo suspend path. For switcheroo we only ever need to
perform a full suspend (PM_EVENT_SUSPEND) and for the DRM legacy path
we can handle the S4 freeze (PM_EVENT_FREEZE) the same way as S3
suspend. The only difference atm between suspend and freeze is that
during freeze we don't disable the PCI device, but there is no reason
why we can't do so. So unify the two cases to reduce complexity.

Note that for the DRM legacy case the thaw event is not handled, so
we disable the display before creating the hibernation image and it
won't get re-enabled until reboot. We could fix this leaving the
display enabled for the image creation/writing (if we care enough
about UMS), but this can be done as a follow-up.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is needed by an upcoming patch fixing the switcheroo/legacy suspend
paths.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During S4 freeze we don't call intel_suspend_complete(), which would
save the gunit HW state, but during S4 thaw/restore events we call
intel_resume_prepare() which restores it, thus ending up in a corrupted
HW state.

Fix this by calling intel_suspend_complete() from the corresponding
freeze_late event handler.

The issue was introduced in
commit 016970be
Author: Sagar Kamble <sagar.a.kamble@intel.com>
Date:   Wed Aug 13 23:07:06 2014 +0530

CC: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw
events so we don't need to care about it either. Only S3 suspend and S4
freeze events are handled. Leave an assert behind to be sure.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

IS_ULT() wasn't taking into account SKL so we had a warn with SPT-LP.

We don't realy need those checks here, and as we don't need to introduce
IS_SKL_ULT/ULX() at the moment, let's just drop them.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No need to add the BDW pci ULT/ULX checks inside a if (IS_HASWELL(dev))
code path.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's the new world order!

Not going full monty on these here and rolling this out throughout the
subsequent call chains since this is just for the kerneldoc. Later on
we can go more crazy, especially once we've embedded drm_device
correctly.

v2: Also frob the runtime_pm functions ...
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This seems to have been accidentally lost in

commit be62acb4
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Fri Aug 30 16:19:28 2013 +0300

    drm/i915: ban badly behaving contexts

Without this real gpu hangs only log output at info level, which gets
filtered away by piglit's testrunner.

v2: Tune down to notice level. Note that we need to add drm/i915 so
that at least the automatic igt dmesg filtering still picks it up.

v3: git add and lack of coffee don't mix well.

v4: Message is in between hw and sw reset, so switch verb to
continuous form.

v5: Use i915_stop_rings_allow_warn for consistency. For Chris' case of
injecting lots of hangs I guess we need to revamp this all anyway when
merging. For now this should plug the regression for piglit testing
mesa.

v6: Make it compile (Mika).

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reported-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>