From 5c19e5ee394c36652c59c247855a3c7e5a83a015 Mon Sep 17 00:00:00 2001

From: Jani Nikula <jani.nikula@intel.com>

Date: Thu, 7 Jan 2016 10:29:10 +0200

Subject: [PATCH 01/26] drm/i915: shut up gen8+ SDE irq dmesg noise, again

We still keep getting

[    4.249930] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)!

This reverts

commit 820da7ae46332fa709b171eb7ba57cbd023fa6df

Author: Jani Nikula <jani.nikula@intel.com>

Date:   Wed Nov 25 16:47:23 2015 +0200

    Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"

which in itself is a revert, so this is just doing

commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab

Author: Daniel Vetter <daniel.vetter@ffwll.ch>

Date:   Fri Oct 23 10:56:12 2015 +0200

    drm/i915: shut up gen8+ SDE irq dmesg noise

all over again. I'll stop pretending I understand what's going on like I

did when I thought I'd fixed this for good in

commit 6a39d7c986be4fd18eb019e9cdbf774ec36c9f77

Author: Jani Nikula <jani.nikula@intel.com>

Date:   Wed Nov 25 16:47:22 2015 +0200

    drm/i915: fix the SDE irq dmesg warnings properly

Reported-by: Chris Wilson <chris@chris-wilson.co.uk>

Reference: http://mid.gmane.org/20151213124945.GA5715@nuc-i3427.alporthouse.com

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084

Cc: drm-intel-fixes@lists.freedesktop.org

Fixes: 820da7ae4633 ("Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"")

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

[Backported to 4.3.y by Josh Boyer <jwboyer@fedoraproject.org>]

---

 drivers/gpu/drm/i915/i915_irq.c | 9 +++++++--

 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c

index 39d73dbc1c47..fa7f82d54762 100644

--- a/drivers/gpu/drm/i915/i915_irq.c

+++ b/drivers/gpu/drm/i915/i915_irq.c

@@ -2168,8 +2168,13 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)

 			I915_WRITE(SDEIIR, pch_iir);

 			ret = IRQ_HANDLED;

 			cpt_irq_handler(dev, pch_iir);

-		} else

-			DRM_ERROR("The master control interrupt lied (SDE)!\n");

+		} else {

+			/*

+			 * Like on previous PCH there seems to be something

+			 * fishy going on with forwarding PCH interrupts.

+			 */

+			DRM_DEBUG_DRIVER("The master control interrupt lied (SDE)!\n");

+		}

 	}

-- 

2.5.0

From 65dcf0f52e9705d0094e76a9225bbe770329c96d Mon Sep 17 00:00:00 2001

From: Chris Wilson <chris@chris-wilson.co.uk>

Date: Thu, 1 Oct 2015 12:34:46 +0100

Subject: [PATCH 02/26] drm/i915: Fix userptr deadlock with aliased GTT

 mmappings

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Upstream commit e4b946bfe1e36680e27a5f39163980979fa61a5d

Michał Winiarski found a really evil way to trigger a struct_mutex

deadlock with userptr. He found that if he allocated a userptr bo and

then GTT mmaped another bo, or even itself, at the same address as the

userptr using MAP_FIXED, he could then cause a deadlock any time we then

had to invalidate the GTT mmappings (so at will). Tvrtko then found by

repeatedly allocating GTT mmappings he could alias with an old userptr

mmap and also trigger the deadlock.

To counter act the deadlock, we make the observation that we only need

to take the struct_mutex if the object has any pages to revoke, and that

before userspace can alias with the userptr address space, it must have

invalidated the userptr->pages. Thus if we can check for those pages

outside of the struct_mutex, we can avoid the deadlock. To do so we

introduce a separate flag for userptr objects that we can inspect from

the mmu-notifier underneath its spinlock.

The patch makes one eye-catching change. That is the removal serial=0

after detecting a to-be-freed object inside the invalidate walker. I

felt setting serial=0 was a questionable pessimisation: it denies us the

chance to reuse the current iterator for the next loop (before it is

freed) and being explicit makes the reader question the validity of the

locking (since the object-free race could occur elsewhere). The

serialisation of the iterator is through the spinlock, if the object is

freed before the next loop then the notifier.serial will be incremented

and we start the walk from the beginning as we detect the invalid cache.

To try and tame the error paths and interactions with the userptr->active

flag, we have to do a fair amount of rearranging of get_pages_userptr().

v2: Grammar fixes

v3: Reorder set-active so that it is only set when obj->pages is set

(and so needs cancellation). Only the order of setting obj->pages and

the active-flag is crucial. Calling gup after invalidate-range begin

means the userptr sees the new set of backing storage (and so will not

need to invalidate its new pages), but we have to be careful not to set

the active-flag prior to successfully establishing obj->pages.

v4: Take the active->flag early so we know in the mmu-notifier when we

have to cancel a pending gup-worker.

v5: Rearrange the error path so that is not so convoluted

v6: Set pinned to 0 when negative before calling release_pages()

Reported-by: Michał Winiarski <michal.winiarski@intel.com>

Testcase: igt/gem_userptr_blits/map-fixed*

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Cc: Michał Winiarski <michal.winiarski@intel.com>

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Cc: stable@vger.kernel.org

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

---

 drivers/gpu/drm/i915/i915_gem_userptr.c | 176 ++++++++++++++++++++------------

 1 file changed, 110 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c

index a96b9006a51e..ba321f0c41c5 100644

--- a/drivers/gpu/drm/i915/i915_gem_userptr.c

+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c

@@ -59,6 +59,7 @@ struct i915_mmu_object {

 	struct interval_tree_node it;

 	struct list_head link;

 	struct drm_i915_gem_object *obj;

+	bool active;

 	bool is_linear;

 };

@@ -114,7 +115,8 @@ restart:

 		obj = mo->obj;

-		if (!kref_get_unless_zero(&obj->base.refcount))

+		if (!mo->active ||

+		    !kref_get_unless_zero(&obj->base.refcount))

 			continue;

 		spin_unlock(&mn->lock);

@@ -151,7 +153,8 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,

 		else

 			it = interval_tree_iter_first(&mn->objects, start, end);

 		if (it != NULL) {

-			obj = container_of(it, struct i915_mmu_object, it)->obj;

+			struct i915_mmu_object *mo =

+				container_of(it, struct i915_mmu_object, it);

 			/* The mmu_object is released late when destroying the

 			 * GEM object so it is entirely possible to gain a

@@ -160,11 +163,9 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,

 			 * the struct_mutex - and consequently use it after it

 			 * is freed and then double free it.

 			 */

-			if (!kref_get_unless_zero(&obj->base.refcount)) {

-				spin_unlock(&mn->lock);

-				serial = 0;

-				continue;

-			}

+			if (mo->active &&

+			    kref_get_unless_zero(&mo->obj->base.refcount))

+				obj = mo->obj;

 			serial = mn->serial;

 		}

@@ -566,6 +567,30 @@ __i915_gem_userptr_set_pages(struct drm_i915_gem_object *obj,

 }

 static void

+__i915_gem_userptr_set_active(struct drm_i915_gem_object *obj,

+			      bool value)

+{

+	/* During mm_invalidate_range we need to cancel any userptr that

+	 * overlaps the range being invalidated. Doing so requires the

+	 * struct_mutex, and that risks recursion. In order to cause

+	 * recursion, the user must alias the userptr address space with

+	 * a GTT mmapping (possible with a MAP_FIXED) - then when we have

+	 * to invalidate that mmaping, mm_invalidate_range is called with

+	 * the userptr address *and* the struct_mutex held.  To prevent that

+	 * we set a flag under the i915_mmu_notifier spinlock to indicate

+	 * whether this object is valid.

+	 */

+#if defined(CONFIG_MMU_NOTIFIER)

+	if (obj->userptr.mmu_object == NULL)

+		return;

+

+	spin_lock(&obj->userptr.mmu_object->mn->lock);

+	obj->userptr.mmu_object->active = value;

+	spin_unlock(&obj->userptr.mmu_object->mn->lock);

+#endif

+}

+

+static void

 __i915_gem_userptr_get_pages_worker(struct work_struct *_work)

 {

 	struct get_pages_work *work = container_of(_work, typeof(*work), work);

@@ -612,6 +637,9 @@ __i915_gem_userptr_get_pages_worker(struct work_struct *_work)

 			pinned = 0;

 		}

+		obj->userptr.work = ERR_PTR(ret);

+		if (ret)

+			__i915_gem_userptr_set_active(obj, false);

 	}

 	obj->userptr.work = ERR_PTR(ret);

@@ -627,11 +655,60 @@ __i915_gem_userptr_get_pages_worker(struct work_struct *_work)

 }

 static int

+__i915_gem_userptr_get_pages_schedule(struct drm_i915_gem_object *obj,

+				      bool *active)

+{

+	struct get_pages_work *work;

+

+	/* Spawn a worker so that we can acquire the

+	 * user pages without holding our mutex. Access

+	 * to the user pages requires mmap_sem, and we have

+	 * a strict lock ordering of mmap_sem, struct_mutex -

+	 * we already hold struct_mutex here and so cannot

+	 * call gup without encountering a lock inversion.

+	 *

+	 * Userspace will keep on repeating the operation

+	 * (thanks to EAGAIN) until either we hit the fast

+	 * path or the worker completes. If the worker is

+	 * cancelled or superseded, the task is still run

+	 * but the results ignored. (This leads to

+	 * complications that we may have a stray object

+	 * refcount that we need to be wary of when

+	 * checking for existing objects during creation.)

+	 * If the worker encounters an error, it reports

+	 * that error back to this function through

+	 * obj->userptr.work = ERR_PTR.

+	 */

+	if (obj->userptr.workers >= I915_GEM_USERPTR_MAX_WORKERS)

+		return -EAGAIN;

+

+	work = kmalloc(sizeof(*work), GFP_KERNEL);

+	if (work == NULL)

+		return -ENOMEM;

+

+	obj->userptr.work = &work->work;

+	obj->userptr.workers++;

+

+	work->obj = obj;

+	drm_gem_object_reference(&obj->base);

+

+	work->task = current;

+	get_task_struct(work->task);

+

+	INIT_WORK(&work->work, __i915_gem_userptr_get_pages_worker);

+	schedule_work(&work->work);

+

+	*active = true;

+	return -EAGAIN;

+}

+

+static int

 i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)

 {

 	const int num_pages = obj->base.size >> PAGE_SHIFT;

 	struct page **pvec;

 	int pinned, ret;

+	bool active;

 	/* If userspace should engineer that these pages are replaced in

 	 * the vma between us binding this page into the GTT and completion

@@ -649,6 +726,18 @@ i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)

 	 * to the vma (discard or cloning) which should prevent the more

 	 * egregious cases from causing harm.

 	 */

+	if (IS_ERR(obj->userptr.work)) {

+		/* active flag will have been dropped already by the worker */

+		ret = PTR_ERR(obj->userptr.work);

+		obj->userptr.work = NULL;

+		return ret;

+	}

+	if (obj->userptr.work)

+		/* active flag should still be held for the pending work */

+		return -EAGAIN;

+

+	/* Let the mmu-notifier know that we have begun and need cancellation */

+	__i915_gem_userptr_set_active(obj, true);

 	pvec = NULL;

 	pinned = 0;

@@ -657,73 +746,27 @@ i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)

 			       GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);

 		if (pvec == NULL) {

 			pvec = drm_malloc_ab(num_pages, sizeof(struct page *));

-			if (pvec == NULL)

+			if (pvec == NULL) {

+				__i915_gem_userptr_set_active(obj, false);

 				return -ENOMEM;

+			}

 		}

 		pinned = __get_user_pages_fast(obj->userptr.ptr, num_pages,

 					       !obj->userptr.read_only, pvec);

 	}

-	if (pinned < num_pages) {

-		if (pinned < 0) {

-			ret = pinned;

-			pinned = 0;

-		} else {

-			/* Spawn a worker so that we can acquire the

-			 * user pages without holding our mutex. Access

-			 * to the user pages requires mmap_sem, and we have

-			 * a strict lock ordering of mmap_sem, struct_mutex -

-			 * we already hold struct_mutex here and so cannot

-			 * call gup without encountering a lock inversion.

-			 *

-			 * Userspace will keep on repeating the operation

-			 * (thanks to EAGAIN) until either we hit the fast

-			 * path or the worker completes. If the worker is

-			 * cancelled or superseded, the task is still run

-			 * but the results ignored. (This leads to

-			 * complications that we may have a stray object

-			 * refcount that we need to be wary of when

-			 * checking for existing objects during creation.)

-			 * If the worker encounters an error, it reports

-			 * that error back to this function through

-			 * obj->userptr.work = ERR_PTR.

-			 */

-			ret = -EAGAIN;

-			if (obj->userptr.work == NULL &&

-			    obj->userptr.workers < I915_GEM_USERPTR_MAX_WORKERS) {

-				struct get_pages_work *work;

-

-				work = kmalloc(sizeof(*work), GFP_KERNEL);

-				if (work != NULL) {

-					obj->userptr.work = &work->work;

-					obj->userptr.workers++;

-

-					work->obj = obj;

-					drm_gem_object_reference(&obj->base);

-

-					work->task = current;

-					get_task_struct(work->task);

-

-					INIT_WORK(&work->work, __i915_gem_userptr_get_pages_worker);

-					schedule_work(&work->work);

-				} else

-					ret = -ENOMEM;

-			} else {

-				if (IS_ERR(obj->userptr.work)) {

-					ret = PTR_ERR(obj->userptr.work);

-					obj->userptr.work = NULL;

-				}

-			}

-		}

-	} else {

+

+	active = false;

+	if (pinned < 0)

+		ret = pinned, pinned = 0;

+	else if (pinned < num_pages)

+		ret = __i915_gem_userptr_get_pages_schedule(obj, &active);

+	else

 		ret = __i915_gem_userptr_set_pages(obj, pvec, num_pages);

-		if (ret == 0) {

-			obj->userptr.work = NULL;

-			pinned = 0;

-		}

+	if (ret) {

+		__i915_gem_userptr_set_active(obj, active);

+		release_pages(pvec, pinned, 0);

 	}

-

-	release_pages(pvec, pinned, 0);

 	drm_free_large(pvec);

 	return ret;

 }

@@ -734,6 +777,7 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj)

 	struct sg_page_iter sg_iter;

 	BUG_ON(obj->userptr.work != NULL);

+	__i915_gem_userptr_set_active(obj, false);

 	if (obj->madv != I915_MADV_WILLNEED)

 		obj->dirty = 0;

-- 

2.5.0

From d9cc6dc69e3a5f7f68e22227baf0e0f7743e448c Mon Sep 17 00:00:00 2001

From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Date: Thu, 22 Oct 2015 13:56:34 +0200

Subject: [PATCH 03/26] drm/i915/skl: Prevent unclaimed register writes on

 skylake.

Upstream commit b10f1b20171945b49988b2b1fe68cb312cc36d32

I'm getting unclaimed register writes when checking the WM registers

after the crtc is disabled. So I would imagine those are guarded by

the crtc power well. Fix this by not reading out wm state when the

power well is off.

Cc: stable@vger.kernel.org # v4.3

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92181

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

 drivers/gpu/drm/i915/intel_pm.c | 5 +++++

 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c

index ddbb7ed0a193..5e91e795fd99 100644

--- a/drivers/gpu/drm/i915/intel_pm.c

+++ b/drivers/gpu/drm/i915/intel_pm.c

@@ -2899,7 +2899,12 @@ void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,

 	int plane;

 	u32 val;

+	memset(ddb, 0, sizeof(*ddb));

+

 	for_each_pipe(dev_priv, pipe) {

+		if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe)))

+			continue;

+

 		for_each_plane(dev_priv, pipe, plane) {

 			val = I915_READ(PLANE_BUF_CFG(pipe, plane));

 			skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane],

-- 

2.5.0

From 0ee1dd6b04a4e8eb34f948842fe4385c09695270 Mon Sep 17 00:00:00 2001

From: Jani Nikula <jani.nikula@intel.com>

Date: Fri, 30 Oct 2015 14:50:24 +0200

Subject: [PATCH 04/26] drm/i915: add quirk to enable backlight on Dell

 Chromebook 11 (2015)

Upstream commit 9be64eee3a87dc03218ca9a12834d1150a57b8a8

Reported-by: Keith Webb <khwebb@gmail.com>

Suggested-by: Keith Webb <khwebb@gmail.com>

Cc: stable@vger.kernel.org

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106671

Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Link: http://patchwork.freedesktop.org/patch/msgid/1446209424-28801-1-git-send-email-jani.nikula@intel.com

---

 drivers/gpu/drm/i915/intel_display.c | 3 +++

 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 1d2ff8e6fb4a..8f258092cada 100644

--- a/drivers/gpu/drm/i915/intel_display.c

+++ b/drivers/gpu/drm/i915/intel_display.c

@@ -14678,6 +14678,9 @@ static struct intel_quirk intel_quirks[] = {

 	/* Dell Chromebook 11 */

 	{ 0x0a06, 0x1028, 0x0a35, quirk_backlight_present },

+

+	/* Dell Chromebook 11 (2015 version) */

+	{ 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },

 };

 static void intel_init_quirks(struct drm_device *dev)

-- 

2.5.0

From 06d7e7fe18b63244ec4e6e633fc40dd5bea39099 Mon Sep 17 00:00:00 2001

From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Date: Tue, 3 Nov 2015 08:31:41 +0100

Subject: [PATCH 05/26] drm/i915: Extend DSL readout fix to BDW and SKL.

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Upstream commit b291681926a142958112eedde62823230d6afb84

Those platforms have the same bug as haswell, and the same fix applies

to them.

The original HSW fix that this extends is

commit 41b578fb0e8b930f2470d3f673b0fa279e77a7b8

Author: Jesse Barnes <jbarnes@virtuousgeek.org>

Date:   Tue Sep 22 12:15:54 2015 -0700

    drm/i915: workaround bad DSL readout v3

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Cc: stable@vger.kernel.org # v4.3

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91579

Link: http://patchwork.freedesktop.org/patch/msgid/1446535913-31970-3-git-send-email-maarten.lankhorst@linux.intel.com

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

 drivers/gpu/drm/i915/i915_irq.c | 2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c

index fa7f82d54762..d83d12eeb3fe 100644

--- a/drivers/gpu/drm/i915/i915_irq.c

+++ b/drivers/gpu/drm/i915/i915_irq.c

@@ -651,7 +651,7 @@ static int __intel_get_crtc_scanline(struct intel_crtc *crtc)

 	 * problem.  We may need to extend this to include other platforms,

 	 * but so far testing only shows the problem on HSW.

 	 */

-	if (IS_HASWELL(dev) && !position) {

+	if (HAS_DDI(dev) && !position) {

 		int i, temp;

 		for (i = 0; i < 100; i++) {

-- 

2.5.0

From f5268273f194155f0a5f3cbfa7bf271774a7a9d6 Mon Sep 17 00:00:00 2001

From: Jani Nikula <jani.nikula@intel.com>

Date: Thu, 5 Nov 2015 11:49:59 +0200

Subject: [PATCH 06/26] drm/i915: quirk backlight present on Macbook 4, 1

Upstream commit 1b9448b071caa7d10bb2569fabe3020a2c25ae59

Unsurprisingly macbooks have backlights, just the VBT doesn't seem to

know it in this case.

Reported-and-tested-by: Daniel Nicoletti <dantti12@gmail.com>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88325

Fixes: c675949ec58c ("drm/i915: do not setup backlight if not available according to VBT")

Cc: stable@vger.kernel.org # v3.15+

Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Link: http://patchwork.freedesktop.org/patch/msgid/1446716999-1796-1-git-send-email-jani.nikula@intel.com

---

 drivers/gpu/drm/i915/intel_display.c | 3 +++

 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 8f258092cada..2e348788ecaa 100644

--- a/drivers/gpu/drm/i915/intel_display.c

+++ b/drivers/gpu/drm/i915/intel_display.c

@@ -14670,6 +14670,9 @@ static struct intel_quirk intel_quirks[] = {

 	/* Apple Macbook 2,1 (Core 2 T7400) */

 	{ 0x27a2, 0x8086, 0x7270, quirk_backlight_present },

+	/* Apple Macbook 4,1 */

+	{ 0x2a02, 0x106b, 0x00a1, quirk_backlight_present },

+

 	/* Toshiba CB35 Chromebook (Celeron 2955U) */

 	{ 0x0a06, 0x1179, 0x0a88, quirk_backlight_present },

-- 

2.5.0

From dddd84b8b5f7f8c0b0037a1bb53f81f5bc70115b Mon Sep 17 00:00:00 2001

From: Imre Deak <imre.deak@intel.com>

Date: Wed, 4 Nov 2015 21:25:32 +0200

Subject: [PATCH 07/26] drm/i915: get runtime PM reference around GEM

 set_caching IOCTL

Upstream commit fd0fe6acf1dd88aabfbf383f7e4c16315387a7b7

After Damien's D3 fix I started to get runtime suspend residency for the

first time and that revealed a breakage on the set_caching IOCTL path

that accesses the HW but doesn't take an RPM ref. Fix this up.

Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

Cc: stable@vger.kernel.org

Link: http://patchwork.freedesktop.org/patch/msgid/1446665132-22491-1-git-send-email-imre.deak@intel.com

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

 drivers/gpu/drm/i915/i915_gem.c | 8 +++++++-

 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c

index 4d631a946481..dee065c2b6d8 100644

--- a/drivers/gpu/drm/i915/i915_gem.c

+++ b/drivers/gpu/drm/i915/i915_gem.c

@@ -3728,6 +3728,7 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev, void *data,

 int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,

 			       struct drm_file *file)

 {

+	struct drm_i915_private *dev_priv = dev->dev_private;

 	struct drm_i915_gem_caching *args = data;

 	struct drm_i915_gem_object *obj;

 	enum i915_cache_level level;

@@ -3747,9 +3748,11 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,

 		return -EINVAL;

 	}

+	intel_runtime_pm_get(dev_priv);

+

 	ret = i915_mutex_lock_interruptible(dev);

 	if (ret)

-		return ret;

+		goto rpm_put;

 	obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));

 	if (&obj->base == NULL) {

@@ -3762,6 +3765,9 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,

 	drm_gem_object_unreference(&obj->base);

 unlock:

 	mutex_unlock(&dev->struct_mutex);

+rpm_put:

+	intel_runtime_pm_put(dev_priv);

+

 	return ret;

 }

-- 

2.5.0

From df79b28d6a73835c70222506405bdb54774395c9 Mon Sep 17 00:00:00 2001

From: Maarten Lankhorst <maarten@mblankhorst.nl>

Date: Mon, 16 Nov 2015 12:49:14 +0100

Subject: [PATCH 08/26] drm/i915: Clear intel_crtc->atomic before updating it.

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Upstream commit ba8af3e592f7175b5f9a92d2cfcc00b82097d1be

If an atomic update fails intel_crtc->atomic may have have some values left

from the last atomic check. One example is atomic->wait_for_vblank,

which results in spurious errors in kms_flip.

[ 1551.892708] ------------[ cut here ]------------

[ 1551.892721] WARNING: CPU: 3 PID: 4179 at ../drivers/gpu/drm/drm_irq.c:1199 drm_wait_one_vblank+0x197/0x1a0 [drm]()

[ 1551.892722] vblank not available on crtc 2, ret=-22

[ 1551.892751] Modules linked in: snd_hda_intel i915 drm_kms_helper drm

intel_gtt i2c_algo_bit cfbfillrect syscopyarea cfbimgblt sysfillrect

sysimgblt fb_sys_fops cfbcopyarea agpgart cfg80211 binfmt_misc

snd_hda_codec_hdmi intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp

kvm_intel snd_hda_codec_realtek kvm snd_hda_codec_generic iTCO_wdt

aesni_intel aes_x86_64 glue_helper lrw snd_hda_codec gf128mul

ablk_helper cryptd snd_hwdep psmouse snd_hda_core pcspkr snd_pcm

snd_timer snd lpc_ich i2c_i801 mfd_core soundcore wmi evdev [last

unloaded: drm]

[ 1551.892753] CPU: 3 PID: 4179 Comm: kms_pipe_crc_ba Tainted: G     U  W       4.3.0-reg+ #6

[ 1551.892754] Hardware name:                  /DZ77BH-55K, BIOS BHZ7710H.86A.0100.2013.0517.0942 05/17/2013

[ 1551.892758]  ffffffffa03128d8 ffff8800cec73890 ffffffff812c0f3c ffff8800cec738d8

[ 1551.892760]  ffff8800cec738c8 ffffffff8104ff36 ffff880116ae2290 0000000000000002

[ 1551.892762]  ffff8800d39fcda0 ffff8800d038b4d0 ffff8800d42b5550 ffff8800cec73928

[ 1551.892763] Call Trace:

[ 1551.892768]  [<ffffffff812c0f3c>] dump_stack+0x4e/0x82

[ 1551.892771]  [<ffffffff8104ff36>] warn_slowpath_common+0x86/0xc0

[ 1551.892773]  [<ffffffff8104ffbc>] warn_slowpath_fmt+0x4c/0x50

[ 1551.892781]  [<ffffffffa02e6708>] ? drm_vblank_get+0x78/0xd0 [drm]

[ 1551.892787]  [<ffffffffa02e6d47>] drm_wait_one_vblank+0x197/0x1a0 [drm]

[ 1551.892813]  [<ffffffffa03d052f>] intel_post_plane_update+0xef/0x120 [i915]

[ 1551.892832]  [<ffffffffa03d11d2>] intel_atomic_commit+0x4c2/0x1600 [i915]

[ 1551.892862]  [<ffffffffa02ff0c7>] ? drm_atomic_check_only+0x147/0x5e0 [drm]

[ 1551.892872]  [<ffffffffa02feeb7>] ? drm_atomic_add_affected_connectors+0x27/0xf0 [drm]

[ 1551.892881]  [<ffffffffa02ff597>] drm_atomic_commit+0x37/0x60 [drm]

[ 1551.892887]  [<ffffffffa034301a>] restore_fbdev_mode+0x28a/0x2c0 [drm_kms_helper]

[ 1551.892895]  [<ffffffffa0345253>] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper]

[ 1551.892900]  [<ffffffffa03452cd>] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]

[ 1551.892920]  [<ffffffffa03e7a9a>] intel_fbdev_set_par+0x1a/0x60 [i915]

[ 1551.892923]  [<ffffffff8131a5a7>] fb_set_var+0x1a7/0x3f0

[ 1551.892927]  [<ffffffff8109732f>] ? trace_hardirqs_on_caller+0x12f/0x1c0

[ 1551.892931]  [<ffffffff81314f32>] fbcon_blank+0x212/0x2f0

[ 1551.892935]  [<ffffffff81373f4a>] do_unblank_screen+0xba/0x1d0

[ 1551.892937]  [<ffffffff8136b725>] vt_ioctl+0x13d5/0x1450

[ 1551.892940]  [<ffffffff8107cdd1>] ? preempt_count_sub+0x41/0x50

[ 1551.892943]  [<ffffffff8135d8a3>] tty_ioctl+0x423/0xe30

[ 1551.892947]  [<ffffffff8119f721>] do_vfs_ioctl+0x301/0x560

[ 1551.892949]  [<ffffffff8119b1e3>] ? putname+0x53/0x60

[ 1551.892952]  [<ffffffff811ab376>] ? __fget_light+0x66/0x90

[ 1551.892955]  [<ffffffff8119f9f9>] SyS_ioctl+0x79/0x90

[ 1551.892958]  [<ffffffff81552e97>] entry_SYSCALL_64_fastpath+0x12/0x6f

[ 1551.892961] ---[ end trace 3e764d4b6628c91c ]---

Testcase: kms_flip

Reported-and-tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Cc: stable@vger.kernel.org #v4.3

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Reviewed-by: Daniel Stone <daniels@collabora.com>

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Link: http://patchwork.freedesktop.org/patch/msgid/5649C2BA.6080300@mblankhorst.nl

---

 drivers/gpu/drm/i915/intel_display.c | 3 +++

 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 2e348788ecaa..7e13bea3b4d5 100644

--- a/drivers/gpu/drm/i915/intel_display.c

+++ b/drivers/gpu/drm/i915/intel_display.c

@@ -13005,6 +13005,9 @@ static int intel_atomic_check(struct drm_device *dev,

 		struct intel_crtc_state *pipe_config =

 			to_intel_crtc_state(crtc_state);

+		memset(&to_intel_crtc(crtc)->atomic, 0,

+		       sizeof(struct intel_crtc_atomic_commit));

+

 		/* Catch I915_MODE_FLAG_INHERITED */

 		if (crtc_state->mode.private_flags != crtc->state->mode.private_flags)

 			crtc_state->mode_changed = true;

-- 

2.5.0