Linus commit 05c63c2f modified the
runtime suspend/resume paths to skip over display-related tasks to
avoid locking issues on resume.

Unfortunately, this resulted in the display hardware being left in
a partially initialised state, preventing subsequent modesets from
completing.

This commit unifies the (many) suspend/resume paths, bringing back
display (and fbcon) handling in the runtime paths.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Preparation for some runtime pm fixes.  Currently we skip over fbcon
suspend/resume in the runtime path, which causes issues on resume if
fbcon tries to write to the framebuffer before the BAR subdev has
been resumed to restore the BAR1 VM setup.

As we might be woken up via a sysfs connector, we are unable to call
fb_set_suspend() in the resume path as it could make its way down to
a modeset and cause all sorts of locking hilarity.

To solve this, we'll just delay the fbcon resume to a workqueue.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Xorg (and any non-DRM client really) doesn't have permission to directly
touch VRAM on nv50 and up, which the fence code prior to g84 depends on.

It's less invasive to temporarily grant it premission to do so, as it
previously did, than it is to rework fencenv50 to use the VM.  That
will come later on.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported in fdo#82527 comment #2.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some of the Thinkpads' firmware will issue a backlight change request
through i915 operation region unconditionally on AC plug/unplug, the
backlight level used is arbitrary and thus should be ignored. This is
handled by commit 0b9f7d93 (ACPI / i915: ignore firmware requests
for backlight change). Then there is a Dell laptop whose vendor backlight
interface also makes use of operation region to change backlight level
and with the above commit, that interface no long works. The condition
used to ignore the backlight change request from firmware is thus
changed to: if the vendor backlight interface is not in use and the ACPI
backlight interface is broken, we ignore the requests; oterwise, we keep
processing them.

Fixes: 0b9f7d93 (ACPI / i915: ignore firmware requests for backlight change)
Link: https://lkml.org/lkml/2014/9/23/854Reported-and-tested-by: NPali Rohár <pali.rohar@gmail.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS tries to read our GTT).

Fixes a regression from

commit 828c7908
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Wed Oct 16 09:21:30 2013 -0700

    drm/i915: Disable GGTT PTEs on GEN6+ suspend

that survived and continue to cause harm even after

commit e568af1c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 26 20:08:20 2014 +0100

    drm/i915: Undo gtt scratch pte unmapping again

v2: Trivial rebase.
v3: Fixes requires pointer dances.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340
Tested-by: ming.yao@intel.com
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Todd Previte <tprevite@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Otherwise we may fail to init the second compute ring.
Noticed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Check the correct bit for audio. Seems like a copy-paste error from the
start:

commit 9ed109a7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Apr 24 23:54:52 2014 +0200

    drm/i915: Track has_audio in the pipe config
Reported-by: NMartin Andersen <martin.x.andersen@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82756
Cc: stable@vger.kernel.org # 3.16+
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Ring init and cleanup are not balanced because we re-init the rings on
resume without having cleaned them up on suspend. This leads to the
driver leaking the parser's hash tables with a kmemleak signature such
as this:

unreferenced object 0xffff880405960980 (size 32):
  comm "systemd-udevd", pid 516, jiffies 4294896961 (age 10202.044s)
  hex dump (first 32 bytes):
    d0 85 46 c0 ff ff ff ff 00 00 00 00 00 00 00 00  ..F.............
    98 60 28 04 04 88 ff ff 00 00 00 00 00 00 00 00  .`(.............
  backtrace:
    [<ffffffff81816f9e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff811fa678>] kmem_cache_alloc_trace+0x168/0x2f0
    [<ffffffffc03e20a5>] i915_cmd_parser_init_ring+0x2a5/0x3e0 [i915]
    [<ffffffffc04088a2>] intel_init_ring_buffer+0x202/0x470 [i915]
    [<ffffffffc040c998>] intel_init_vebox_ring_buffer+0x1e8/0x2b0 [i915]
    [<ffffffffc03eff59>] i915_gem_init_hw+0x2f9/0x3a0 [i915]
    [<ffffffffc03f0057>] i915_gem_init+0x57/0x1d0 [i915]
    [<ffffffffc045e26a>] i915_driver_load+0xc0a/0x10e0 [i915]
    [<ffffffffc02e0d5d>] drm_dev_register+0xad/0x100 [drm]
    [<ffffffffc02e3b9f>] drm_get_pci_dev+0x8f/0x200 [drm]
    [<ffffffffc03c934b>] i915_pci_probe+0x3b/0x60 [i915]
    [<ffffffff81436725>] local_pci_probe+0x45/0xa0
    [<ffffffff81437a69>] pci_device_probe+0xd9/0x130
    [<ffffffff81524f4d>] driver_probe_device+0x12d/0x3e0
    [<ffffffff815252d3>] __driver_attach+0x93/0xa0
    [<ffffffff81522e1b>] bus_for_each_dev+0x6b/0xb0

This patch extends the current convention of checking whether a
resource is already allocated before allocating it during ring init.
Longer term it might make sense to only init the rings once.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83794Tested-by: NKari Suvanto <kari.tj.suvanto@gmail.com>
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Seems to have problems turning the dGPU on/off.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=51381Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Only the acpi backlight seems to work.  Using the
radeon backlight controller causes the backlight to
go off.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=81382Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add a module parameter to disable the radeon GPU backlight
controller to override the automatic detection.  Some
laptops seems to indicate that they use the integrated
controller, but appear to actually use an external
controller.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=81382

v2: fix module parameter description
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This might decrease the chance of IH ring buffer overflows.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use the same format for all ring indices, and fix the calculation of the
post-overflow RPTR.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Otherwise the bit remains set in rdev->ih.rptr, so the wptr can never
match that and we still have an infinite loop.

This fix allows me to successfully recover from an IH ring buffer
overflow.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

A mismatch between FB and LTC's idea of how big a large page is causes
issues such as black "holes" in rendering to occur on some boards
(those where LTC is configured for 64KiB large pages) when compression
is used.

Confirmed to fix at least the GK107 MBP.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83996Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use the new vga_switcheroo_fini_domain_pm_ops function
to unregister the pm ops.

Based on a patch from:
Pali Rohár <pali.rohar@gmail.com>

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=84431Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: Ben Skeggs <bskeggs@redhat.com>

Use the new vga_switcheroo_fini_domain_pm_ops function
to unregister the pm ops.

Based on a patch from:
Pali Rohár <pali.rohar@gmail.com>

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=84431Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>

Drivers should call this on unload to unregister pmops.

Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=84431Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>

Otherwise we may lose the DMA golden settings which can
lead to hangs, etc.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Otherwise we may lose the DMA golden settings which can
lead to hangs, etc.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Otherwise we may lose the DMA golden settings which can
lead to hangs, etc.

bug:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to properly disable nb dpm on dpm disable.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

It was causing display corruption with R300 generation GPUs at least.
Reported-and-Tested-by: NMikael Pettersson <mikpelinux@gmail.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

They don't appear to be used anywhere... elsewhere uses R*_PTE_*.

master@linux:U:.% git grep PTE_ -- drivers/gpu/drm/radeon | grep -v _PTE_
master@linux:U:.%	(kyle@redacted:~/linux)

./arch/arm64/include/asm/pgtable.h:27:0: note: this is the location of the previous definition
 #define PTE_VALID  (_AT(pteval_t, 1) << 0)
 ^
In file included from drivers/gpu/drm/radeon/r600_cs.c:31:0:
drivers/gpu/drm/radeon/r600d.h:48:0: warning: "PTE_VALID" redefined [enabled by default]
 #define PTE_VALID    (1 << 0)
 ^
In file included from ./arch/arm64/include/asm/io.h:29:0,
                 from include/linux/clocksource.h:19,
                 from include/clocksource/arm_arch_timer.h:19,
                 from ./arch/arm64/include/asm/arch_timer.h:27,
                 from ./arch/arm64/include/asm/timex.h:19,
                 from include/linux/timex.h:65,
<snip>
                 from include/drm/drmP.h:51,
                 from drivers/gpu/drm/radeon/r600_cs.c:29:
./arch/arm64/include/asm/pgtable.h:27:0: note: this is the location of the previous definition
 #define PTE_VALID  (_AT(pteval_t, 1) << 0)
 ^
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The limited color range knob is in the port registers on
g4x and vlv/chv for HDMI, and on g4x for DP. Add the relevant code
to read out the hardware state into pipe config. On vlv/chv the
DP port limited color range knob is in PIPECONF for which we
already have readout code.

Cc: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NChris Clayton <chris2553@googlemail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

avi infoframe is a 13 bytes array, do not read after this limite.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 20cde694 ("x86, ia64: Move EFI_FB vga_default_device()
initialization to pci_vga_fixup()") moved boot video device detection from
efifb to x86 and ia64 pci/fixup.c.

Remove the left-over #ifndef check that will always match since the
corresponding arch-specific define is gone with above patch.
Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Matthew Garrett <matthew.garrett@nebula.com>

Commit 20cde694 ("x86, ia64: Move EFI_FB vga_default_device()
initialization to pci_vga_fixup()") moved boot video device detection from
efifb to x86 and ia64 pci/fixup.c.

For dual-GPU Apple computers above change represents a regression as code
in efifb did forcefully override vga_default_device while the merge did not
(vgaarb happens prior to PCI fixup).

To improve on initial device selection by vgaarb (it cannot know if PCI
device not behind bridges see/decode legacy VGA I/O or not), move the
screen_info based check from pci_video_fixup() to vgaarb's init function and
use it to refine/override decision taken while adding the individual PCI
VGA devices.  This way PCI fixup has no reason to adjust vga_default_device
anymore but can depend on its value for flagging shadowed VBIOS.

This has the nice benefit of removing duplicated code but does introduce a
#if defined() block in vgaarb.  Not all architectures have screen_info and
would cause compile to fail without it.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461Reported-and-Tested-By: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Matthew Garrett <matthew.garrett@nebula.com>
CC: stable@vger.kernel.org # v3.5+

Revert parts of f244d8b6 ("ACPIPHP / radeon / nouveau: Fix VGA
switcheroo problem related to hotplug").

A previous commit 5493b31f0b55 ("PCI: Add pci_ignore_hotplug() to ignore
hotplug events for a device") added equivalent functionality implemented in
a different way for both acpiphp and pciehp.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NRajat Jain <rajatxjain@gmail.com>

One small change I forgot to make in

commit c4d69da1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Sep 8 14:25:41 2014 +0100

    drm/i915: Evict CS TLBs between batches

was to update the copy width for the compact BLT copy instruction.
Reported-by: NThomas Richter <thor@math.tu-berlin.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Richter <thor@math.tu-berlin.de>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Tested-by: NThomas Richter <thor@math.tu-berlin.de>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Type error and cause AST2000 cannot be detected correctly
Signed-off-by: NY.C. Chen <yc_chen@aspeedtech.com>
Reviewed-by: NEgbert Eich <eich@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some config settings like 3rd TX chips will not get correctly
if the extended reg is protected
Signed-off-by: NY.C. Chen <yc_chen@aspeedtech.com>
Reviewed-by: NEgbert Eich <eich@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

If VRAM carveout is used, due to no IOMMU, we should have a default
value for msm.vram so that we don't simply crash.
Reported-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Reported-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NRob Clark <robdclark@gmail.com>

There is currently a nested function in Russel King's tree
for the msm HDMI driver.

The last nested function was removed from the Linux kernel
when the Thinkpad driver was fixed.

I believe nested functions are not desired upstream, and it
also breaks compilation with clang so here is a patch to
change the nested function into static function. The patch
works with both clang and gcc.
Signed-off-by: NMark Charlebois <charlebm@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold),
normally generates a hot-remove event that unbinds the driver.

Some drivers expect to remain bound to a device even while they power it
off and back on again.  This can be dangerous, because if the device is
removed or replaced while it is powered off, the driver doesn't know that
anything changed.  But some drivers accept that risk.

Add pci_ignore_hotplug() for use by drivers that know their device cannot
be removed.  Using pci_ignore_hotplug() tells the PCI core that hot-plug
events for the device should be ignored.

The radeon and nouveau drivers use this to switch between a low-power,
integrated GPU and a higher-power, higher-performance discrete GPU.  They
power off the unused GPU, but they want to remain bound to it.

This is a reimplementation of f244d8b6 ("ACPIPHP / radeon / nouveau:
Fix VGA switcheroo problem related to hotplug") but extends it to work with
both acpiphp and pciehp.

This fixes a problem where systems with dual GPUs using the radeon drivers
become unusable, freezing every few seconds (see bugzillas below).  The
resume of the radeon device may also fail, e.g.,

This fixes problems on dual GPU systems where the radeon driver becomes
unusable because of problems while suspending the device, as in bug 79701:

    [drm] radeon: finishing device.
    radeon 0000:01:00.0: Userspace still has active objects !
    radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free
    ...
    WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]()
    trying to unbind memory from uninitialized GART !

or while resuming it, as in bug 77261:

    radeon 0000:01:00.0: ring 0 stalled for more than 10158msec
    radeon 0000:01:00.0: GPU lockup ...
    radeon 0000:01:00.0: GPU pci config reset
    pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1)
    radeon 0000:01:00.0: GPU reset succeeded, trying to resume
    *ERROR* radeon: dpm resume failed
    radeon 0000:01:00.0: Wait for MC idle timedout !

Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701Reported-by: NShawn Starr <shawn.starr@rogers.com>
Reported-by: NJose P. <lbdkmjdf@sharklasers.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NRajat Jain <rajatxjain@gmail.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NDave Airlie <airlied@redhat.com>
CC: stable@vger.kernel.org	# v3.15+