linux/drivers/gpu/drm, branch v3.17

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

2014-10-03T15:31:14Z

Pull drm fixes from Dave Airlie: "Nothing too major or scary. One i915 regression fix, nouveau has a tmds regression fix, along with a regression fix for the runtime pm code for optimus laptops not restoring the display hw correctly" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau: make sure display hardware is reinitialised on runtime resume drm/nouveau: punt fbcon resume out to a workqueue drm/nouveau: fix regression on original nv50 board drm/nv50/disp: fix dpms regression on certain boards drm/i915: Flush the PTEs after updating them before suspend

Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes

2014-10-03T01:38:16Z

final regression fix for 3.17. * tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel: drm/i915: Flush the PTEs after updating them before suspend

drm/nouveau: make sure display hardware is reinitialised on runtime resume

2014-10-02T03:32:24Z

Linus commit 05c63c2ff23a80b654d6c088ac3ba21628db0173 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: Ben Skeggs

drm/nouveau: punt fbcon resume out to a workqueue

2014-10-02T03:32:24Z

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: Ben Skeggs

drm/nouveau: fix regression on original nv50 board

2014-10-02T03:32:24Z

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: Ben Skeggs

drm/nv50/disp: fix dpms regression on certain boards

2014-10-02T03:32:23Z

Reported in fdo#82527 comment #2. Signed-off-by: Ben Skeggs

ACPI / i915: Update the condition to ignore firmware backlight change request

2014-09-29T23:11:18Z

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 0b9f7d93ca61 (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: 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change) Link: https://lkml.org/lkml/2014/9/23/854 Reported-and-tested-by: Pali Rohár Cc: 3.16+ # 3.16+ Signed-off-by: Aaron Lu Acked-by: Daniel Vetter Signed-off-by: Rafael J. Wysocki

drm/i915: Flush the PTEs after updating them before suspend

2014-09-29T13:41:17Z

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 828c79087cec61eaf4c76bb32c222fbe35ac3930 Author: Ben Widawsky 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 e568af1c626031925465a5caaab7cca1303d55c7 Author: Daniel Vetter 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: Chris Wilson Cc: stable@vger.kernel.org Cc: Takashi Iwai Cc: Paulo Zanoni Cc: Todd Previte Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula

Merge branch 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2014-09-24T20:49:26Z

- fix a backlight regression resulting in dark screen - add a PX quirk to avoid a hang with runtime pm - fix an init issue on the CIK compute rings - fix IH ring buffer overflows gracefully * 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux: drm/radeon/cik: use a separate counter for CP init timeout drm/radeon: add PX quirk for asus K53TK drm/radeon: add a backlight quirk for Amilo Xi 2550 drm/radeon: add a module parameter for backlight control (v2) drm/radeon: Update IH_RB_RPTR register after each processed interrupt drm/radeon: Make IH ring overflow debugging output more useful drm/radeon: Clear RB_OVERFLOW bit earlier

drm/radeon/cik: use a separate counter for CP init timeout

2014-09-23T14:20:13Z

Otherwise we may fail to init the second compute ring. Noticed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org