[PATCH 0/7] drm/i915: Move load time stolen memory init earlier

[PATCH 0/7] drm/i915: Move load time stolen memory init earlier

[Imre Deak]

For Sagar's BXT RC6 setup sanitization patch [1], we'll need the details
about the GTT/stolen memory reservation early during driver loading, so
this patchset moves the required init calls earlier accordingly. It also
sanitizes a few MMIO/GEM init/clean-up steps on the way.

[1]
http://lists.freedesktop.org/archives/intel-gfx/2016-January/085440.html

Imre Deak (7):
  drm/i915: Sanitize up DMC/CSR ucode cleanup code
  drm/i915: Sanitize i915_get_bridge_dev() error path
  drm/i915: Sanitize GEM shrinker init and clean-up
  drm/i915: Sanitize i915_gem_load() init and clean-up
  drm/i915: Move allocation of various workqueues earlier during init
  drm/i915: Move MCHBAR setup earlier during init
  drm/i915: Move stolen memory initialization earlier during loading

 drivers/gpu/drm/i915/i915_dma.c          | 218 ++++++++++++++++---------------
 drivers/gpu/drm/i915/i915_drv.h          |   4 +-
 drivers/gpu/drm/i915/i915_gem.c          |  13 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c      |  15 +++
 drivers/gpu/drm/i915/i915_gem_shrinker.c |  16 ++-
 5 files changed, 158 insertions(+), 108 deletions(-)

-- 
2.5.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 1/7] drm/i915: Sanitize up DMC/CSR ucode cleanup code

[Imre Deak]

commit ebae38d061df3deffa7c17b030ea14a5216ee55f
Author: Animesh Manna <animesh.manna@intel.com>
Date:   Wed Oct 28 23:58:55 2015 +0200

    drm/i915/gen9: csr_init after runtime pm enable

moved the DMC/CSR initialization later during driver loading, but didn't
move the cleanup earlier correspondingly during unloading. Fix this up.

Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a0f5659..7dd8ec5 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -404,7 +404,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
 	ret = intel_irq_install(dev_priv);
 	if (ret)
-		goto cleanup_gem_stolen;
+		goto cleanup_csr;
 
 	intel_setup_gmbus(dev);
 
@@ -458,7 +458,8 @@ cleanup_irq:
 	intel_guc_ucode_fini(dev);
 	drm_irq_uninstall(dev);
 	intel_teardown_gmbus(dev);
-cleanup_gem_stolen:
+cleanup_csr:
+	intel_csr_ucode_fini(dev_priv);
 	i915_gem_cleanup_stolen(dev);
 cleanup_vga_switcheroo:
 	vga_switcheroo_unregister_client(dev->pdev);
@@ -946,7 +947,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 
 	ret = i915_gem_gtt_init(dev);
 	if (ret)
-		goto out_freecsr;
+		goto out_uncore_fini;
 
 	/* WARNING: Apparently we must kick fbdev drivers before vgacon,
 	 * otherwise the vga fbdev driver falls over. */
@@ -1116,8 +1117,7 @@ out_mtrrfree:
 	io_mapping_free(dev_priv->gtt.mappable);
 out_gtt:
 	i915_global_gtt_cleanup(dev);
-out_freecsr:
-	intel_csr_ucode_fini(dev_priv);
+out_uncore_fini:
 	intel_uncore_fini(dev);
 	pci_iounmap(dev->pdev, dev_priv->regs);
 put_bridge:
@@ -1183,6 +1183,8 @@ int i915_driver_unload(struct drm_device *dev)
 	vga_switcheroo_unregister_client(dev->pdev);
 	vga_client_register(dev->pdev, NULL, NULL, NULL);
 
+	intel_csr_ucode_fini(dev_priv);
+
 	/* Free error state after interrupts are fully disabled. */
 	cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
 	i915_destroy_error_state(dev);
@@ -1203,8 +1205,6 @@ int i915_driver_unload(struct drm_device *dev)
 	intel_fbc_cleanup_cfb(dev_priv);
 	i915_gem_cleanup_stolen(dev);
 
-	intel_csr_ucode_fini(dev_priv);
-
 	intel_teardown_mchbar(dev);
 
 	destroy_workqueue(dev_priv->hotplug.dp_wq);
-- 
2.5.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/7] drm/i915: Sanitize i915_get_bridge_dev() error path

[Imre Deak]

Clarify the name of the label on the error path, making it clear what's
being cleaned up. The kmem_cache_destroy() calls are NOPs on the
corresponding error path.

Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 7dd8ec5..48ce972 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -917,7 +917,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 
 	if (i915_get_bridge_dev(dev)) {
 		ret = -EIO;
-		goto free_priv;
+		goto out_runtime_pm_put;
 	}
 
 	mmio_bar = IS_GEN2(dev) ? 1 : 0;
@@ -1122,11 +1122,10 @@ out_uncore_fini:
 	pci_iounmap(dev->pdev, dev_priv->regs);
 put_bridge:
 	pci_dev_put(dev_priv->bridge_dev);
-free_priv:
 	kmem_cache_destroy(dev_priv->requests);
 	kmem_cache_destroy(dev_priv->vmas);
 	kmem_cache_destroy(dev_priv->objects);
-
+out_runtime_pm_put:
 	intel_runtime_pm_put(dev_priv);
 
 	kfree(dev_priv);
-- 
2.5.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 3/7] drm/i915: Sanitize GEM shrinker init and clean-up

[Imre Deak]

Factor out the common GEM shrinker clean-up code and call the shrinker
init function from the same function from where the corresponding
shrinker clean-up function is called. Also add sanity checking to the
shrinker and OOM registration calls.

Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c          |  7 +++----
 drivers/gpu/drm/i915/i915_drv.h          |  1 +
 drivers/gpu/drm/i915/i915_gem.c          |  2 --
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 16 ++++++++++++++--
 4 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 48ce972..6f9988f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1036,6 +1036,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 	intel_opregion_setup(dev);
 
 	i915_gem_load(dev);
+	i915_gem_shrinker_init(dev_priv);
 
 	/* On the 945G/GM, the chipset reports the MSI capability on the
 	 * integrated graphics even though the support isn't actually there
@@ -1099,8 +1100,7 @@ out_power_well:
 	intel_power_domains_fini(dev_priv);
 	drm_vblank_cleanup(dev);
 out_gem_unload:
-	WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
-	unregister_shrinker(&dev_priv->mm.shrinker);
+	i915_gem_shrinker_cleanup(dev_priv);
 
 	if (dev->pdev->msi_enabled)
 		pci_disable_msi(dev->pdev);
@@ -1153,8 +1153,7 @@ int i915_driver_unload(struct drm_device *dev)
 
 	i915_teardown_sysfs(dev);
 
-	WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
-	unregister_shrinker(&dev_priv->mm.shrinker);
+	i915_gem_shrinker_cleanup(dev_priv);
 
 	io_mapping_free(dev_priv->gtt.mappable);
 	arch_phys_wc_del(dev_priv->gtt.mtrr);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index af30148..21ea132 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3263,6 +3263,7 @@ unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
 #define I915_SHRINK_ACTIVE 0x8
 unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
 void i915_gem_shrinker_init(struct drm_i915_private *dev_priv);
+void i915_gem_shrinker_cleanup(struct drm_i915_private *dev_priv);
 
 
 /* i915_gem_tiling.c */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6b0102d..bf7f741 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5063,8 +5063,6 @@ i915_gem_load(struct drm_device *dev)
 
 	dev_priv->mm.interruptible = true;
 
-	i915_gem_shrinker_init(dev_priv);
-
 	mutex_init(&dev_priv->fb_tracking.lock);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 16da9c1..58c1e59 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -367,8 +367,20 @@ void i915_gem_shrinker_init(struct drm_i915_private *dev_priv)
 	dev_priv->mm.shrinker.scan_objects = i915_gem_shrinker_scan;
 	dev_priv->mm.shrinker.count_objects = i915_gem_shrinker_count;
 	dev_priv->mm.shrinker.seeks = DEFAULT_SEEKS;
-	register_shrinker(&dev_priv->mm.shrinker);
+	WARN_ON(register_shrinker(&dev_priv->mm.shrinker));
 
 	dev_priv->mm.oom_notifier.notifier_call = i915_gem_shrinker_oom;
-	register_oom_notifier(&dev_priv->mm.oom_notifier);
+	WARN_ON(register_oom_notifier(&dev_priv->mm.oom_notifier));
+}
+
+/**
+ * i915_gem_shrinker_cleanup - Clean up i915 shrinker
+ * @dev_priv: i915 device
+ *
+ * This function unregisters the i915 shrinker and OOM handler.
+ */
+void i915_gem_shrinker_cleanup(struct drm_i915_private *dev_priv)
+{
+	WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
+	unregister_shrinker(&dev_priv->mm.shrinker);
 }
-- 
2.5.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 4/7] drm/i915: Sanitize i915_gem_load() init and clean-up

[Imre Deak]

Factor out common clean-up code for the GEM load time init function.
Also rename i915_gem_load() to i915_gem_load_init() to have a better
match with its new clean-up function.

No functional change.

Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 10 +++-------
 drivers/gpu/drm/i915/i915_drv.h |  3 ++-
 drivers/gpu/drm/i915/i915_gem.c | 11 ++++++++++-
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 6f9988f..b931dad 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1035,7 +1035,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 	intel_setup_mchbar(dev);
 	intel_opregion_setup(dev);
 
-	i915_gem_load(dev);
+	i915_gem_load_init(dev);
 	i915_gem_shrinker_init(dev_priv);
 
 	/* On the 945G/GM, the chipset reports the MSI capability on the
@@ -1122,9 +1122,7 @@ out_uncore_fini:
 	pci_iounmap(dev->pdev, dev_priv->regs);
 put_bridge:
 	pci_dev_put(dev_priv->bridge_dev);
-	kmem_cache_destroy(dev_priv->requests);
-	kmem_cache_destroy(dev_priv->vmas);
-	kmem_cache_destroy(dev_priv->objects);
+	i915_gem_load_cleanup(dev);
 out_runtime_pm_put:
 	intel_runtime_pm_put(dev_priv);
 
@@ -1216,9 +1214,7 @@ int i915_driver_unload(struct drm_device *dev)
 	if (dev_priv->regs != NULL)
 		pci_iounmap(dev->pdev, dev_priv->regs);
 
-	kmem_cache_destroy(dev_priv->requests);
-	kmem_cache_destroy(dev_priv->vmas);
-	kmem_cache_destroy(dev_priv->objects);
+	i915_gem_load_cleanup(dev);
 	pci_dev_put(dev_priv->bridge_dev);
 	kfree(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 21ea132..e3dfc05 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2850,7 +2850,8 @@ int i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
 				struct drm_file *file_priv);
 int i915_gem_wait_ioctl(struct drm_device *dev, void *data,
 			struct drm_file *file_priv);
-void i915_gem_load(struct drm_device *dev);
+void i915_gem_load_init(struct drm_device *dev);
+void i915_gem_load_cleanup(struct drm_device *dev);
 void *i915_gem_object_alloc(struct drm_device *dev);
 void i915_gem_object_free(struct drm_i915_gem_object *obj);
 void i915_gem_object_init(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bf7f741..989ff22 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4997,7 +4997,7 @@ init_ring_lists(struct intel_engine_cs *ring)
 }
 
 void
-i915_gem_load(struct drm_device *dev)
+i915_gem_load_init(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	int i;
@@ -5066,6 +5066,15 @@ i915_gem_load(struct drm_device *dev)
 	mutex_init(&dev_priv->fb_tracking.lock);
 }
 
+void i915_gem_load_cleanup(struct drm_device *dev)
+{
+	struct drm_i915_private *dev_priv = to_i915(dev);
+
+	kmem_cache_destroy(dev_priv->requests);
+	kmem_cache_destroy(dev_priv->vmas);
+	kmem_cache_destroy(dev_priv->objects);
+}
+
 void i915_gem_release(struct drm_device *dev, struct drm_file *file)
 {
 	struct drm_i915_file_private *file_priv = file->driver_priv;
-- 
2.5.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 5/7] drm/i915: Move allocation of various workqueues earlier during init

[Imre Deak]

Workqueue initalization doesn't depend on any other device specific
resource, so move it close to the beginning, so we don't need to
consider them when thinking about dependencies for other resources.

Also factor out things to separate init/cleanup functions to make
i915_driver_load()/unload() clearer, atm it's somewhat difficult to
follow there in what order resources are inited/cleaned-up.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 101 ++++++++++++++++++++++------------------
 1 file changed, 56 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b931dad..7934611 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -856,6 +856,54 @@ static void intel_init_dpio(struct drm_i915_private *dev_priv)
 	}
 }
 
+static int i915_workqueues_init(struct drm_i915_private *dev_priv)
+{
+	/*
+	 * The i915 workqueue is primarily used for batched retirement of
+	 * requests (and thus managing bo) once the task has been completed
+	 * by the GPU. i915_gem_retire_requests() is called directly when we
+	 * need high-priority retirement, such as waiting for an explicit
+	 * bo.
+	 *
+	 * It is also used for periodic low-priority events, such as
+	 * idle-timers and recording error state.
+	 *
+	 * All tasks on the workqueue are expected to acquire the dev mutex
+	 * so there is no point in running more than one instance of the
+	 * workqueue at any time.  Use an ordered one.
+	 */
+	dev_priv->wq = alloc_ordered_workqueue("i915", 0);
+	if (dev_priv->wq == NULL)
+		goto out_err;
+
+	dev_priv->hotplug.dp_wq = alloc_ordered_workqueue("i915-dp", 0);
+	if (dev_priv->hotplug.dp_wq == NULL)
+		goto out_free_wq;
+
+	dev_priv->gpu_error.hangcheck_wq =
+		alloc_ordered_workqueue("i915-hangcheck", 0);
+	if (dev_priv->gpu_error.hangcheck_wq == NULL)
+		goto out_free_dp_wq;
+
+	return 0;
+
+out_free_dp_wq:
+	destroy_workqueue(dev_priv->hotplug.dp_wq);
+out_free_wq:
+	destroy_workqueue(dev_priv->wq);
+out_err:
+	DRM_ERROR("Failed to allocate workqueues.\n");
+
+	return -ENOMEM;
+}
+
+static void i915_workqueues_cleanup(struct drm_i915_private *dev_priv)
+{
+	destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
+	destroy_workqueue(dev_priv->hotplug.dp_wq);
+	destroy_workqueue(dev_priv->wq);
+}
+
 /**
  * i915_driver_load - setup chip and create an initial config
  * @dev: DRM device
@@ -899,6 +947,10 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 	mutex_init(&dev_priv->av_mutex);
 	mutex_init(&dev_priv->wm.wm_mutex);
 
+	ret = i915_workqueues_init(dev_priv);
+	if (ret < 0)
+		goto out_free_priv;
+
 	intel_pm_setup(dev);
 
 	intel_runtime_pm_get(dev_priv);
@@ -993,41 +1045,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 	dev_priv->gtt.mtrr = arch_phys_wc_add(dev_priv->gtt.mappable_base,
 					      aperture_size);
 
-	/* The i915 workqueue is primarily used for batched retirement of
-	 * requests (and thus managing bo) once the task has been completed
-	 * by the GPU. i915_gem_retire_requests() is called directly when we
-	 * need high-priority retirement, such as waiting for an explicit
-	 * bo.
-	 *
-	 * It is also used for periodic low-priority events, such as
-	 * idle-timers and recording error state.
-	 *
-	 * All tasks on the workqueue are expected to acquire the dev mutex
-	 * so there is no point in running more than one instance of the
-	 * workqueue at any time.  Use an ordered one.
-	 */
-	dev_priv->wq = alloc_ordered_workqueue("i915", 0);
-	if (dev_priv->wq == NULL) {
-		DRM_ERROR("Failed to create our workqueue.\n");
-		ret = -ENOMEM;
-		goto out_mtrrfree;
-	}
-
-	dev_priv->hotplug.dp_wq = alloc_ordered_workqueue("i915-dp", 0);
-	if (dev_priv->hotplug.dp_wq == NULL) {
-		DRM_ERROR("Failed to create our dp workqueue.\n");
-		ret = -ENOMEM;
-		goto out_freewq;
-	}
-
-	dev_priv->gpu_error.hangcheck_wq =
-		alloc_ordered_workqueue("i915-hangcheck", 0);
-	if (dev_priv->gpu_error.hangcheck_wq == NULL) {
-		DRM_ERROR("Failed to create our hangcheck workqueue.\n");
-		ret = -ENOMEM;
-		goto out_freedpwq;
-	}
-
 	intel_irq_init(dev_priv);
 	intel_uncore_sanitize(dev);
 
@@ -1107,12 +1124,6 @@ out_gem_unload:
 
 	intel_teardown_mchbar(dev);
 	pm_qos_remove_request(&dev_priv->pm_qos);
-	destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
-out_freedpwq:
-	destroy_workqueue(dev_priv->hotplug.dp_wq);
-out_freewq:
-	destroy_workqueue(dev_priv->wq);
-out_mtrrfree:
 	arch_phys_wc_del(dev_priv->gtt.mtrr);
 	io_mapping_free(dev_priv->gtt.mappable);
 out_gtt:
@@ -1125,8 +1136,10 @@ put_bridge:
 	i915_gem_load_cleanup(dev);
 out_runtime_pm_put:
 	intel_runtime_pm_put(dev_priv);
-
+	i915_workqueues_cleanup(dev_priv);
+out_free_priv:
 	kfree(dev_priv);
+
 	return ret;
 }
 
@@ -1203,9 +1216,6 @@ int i915_driver_unload(struct drm_device *dev)
 
 	intel_teardown_mchbar(dev);
 
-	destroy_workqueue(dev_priv->hotplug.dp_wq);
-	destroy_workqueue(dev_priv->wq);
-	destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
 	pm_qos_remove_request(&dev_priv->pm_qos);
 
 	i915_global_gtt_cleanup(dev);
@@ -1216,6 +1226,7 @@ int i915_driver_unload(struct drm_device *dev)
 
 	i915_gem_load_cleanup(dev);
 	pci_dev_put(dev_priv->bridge_dev);
+	i915_workqueues_cleanup(dev_priv);
 	kfree(dev_priv);
 
 	return 0;
-- 
2.5.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 6/7] drm/i915: Move MCHBAR setup earlier during init

[Imre Deak]

Move the MCHBAR setup right after the MMIO setup, since the two things
are logically related and the MCHBAR setup code doesn't depend on any
other device specific resource. We'll also need MCHBAR to be ready
earlier in an upcoming patch, so this is also a preparation for that.

Factor out the init/clean-up code to separate functions to make things
clearer in the i915_driver_load()/unload() functions.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 71 ++++++++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 7934611..a054169 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -904,6 +904,46 @@ static void i915_workqueues_cleanup(struct drm_i915_private *dev_priv)
 	destroy_workqueue(dev_priv->wq);
 }
 
+static int i915_mmio_setup(struct drm_device *dev)
+{
+	struct drm_i915_private *dev_priv = to_i915(dev);
+	int mmio_bar;
+	int mmio_size;
+
+	mmio_bar = IS_GEN2(dev) ? 1 : 0;
+	/*
+	 * Before gen4, the registers and the GTT are behind different BARs.
+	 * However, from gen4 onwards, the registers and the GTT are shared
+	 * in the same BAR, so we want to restrict this ioremap from
+	 * clobbering the GTT which we want ioremap_wc instead. Fortunately,
+	 * the register BAR remains the same size for all the earlier
+	 * generations up to Ironlake.
+	 */
+	if (INTEL_INFO(dev)->gen < 5)
+		mmio_size = 512 * 1024;
+	else
+		mmio_size = 2 * 1024 * 1024;
+	dev_priv->regs = pci_iomap(dev->pdev, mmio_bar, mmio_size);
+	if (dev_priv->regs == NULL) {
+		DRM_ERROR("failed to map registers\n");
+
+		return -EIO;
+	}
+
+	/* Try to make sure MCHBAR is enabled before poking at it */
+	intel_setup_mchbar(dev);
+
+	return 0;
+}
+
+static void i915_mmio_cleanup(struct drm_device *dev)
+{
+	struct drm_i915_private *dev_priv = to_i915(dev);
+
+	intel_teardown_mchbar(dev);
+	pci_iounmap(dev->pdev, dev_priv->regs);
+}
+
 /**
  * i915_driver_load - setup chip and create an initial config
  * @dev: DRM device
@@ -919,7 +959,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 {
 	struct drm_i915_private *dev_priv;
 	struct intel_device_info *info, *device_info;
-	int ret = 0, mmio_bar, mmio_size;
+	int ret = 0;
 	uint32_t aperture_size;
 
 	info = (struct intel_device_info *) flags;
@@ -972,25 +1012,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 		goto out_runtime_pm_put;
 	}
 
-	mmio_bar = IS_GEN2(dev) ? 1 : 0;
-	/* Before gen4, the registers and the GTT are behind different BARs.
-	 * However, from gen4 onwards, the registers and the GTT are shared
-	 * in the same BAR, so we want to restrict this ioremap from
-	 * clobbering the GTT which we want ioremap_wc instead. Fortunately,
-	 * the register BAR remains the same size for all the earlier
-	 * generations up to Ironlake.
-	 */
-	if (info->gen < 5)
-		mmio_size = 512*1024;
-	else
-		mmio_size = 2*1024*1024;
-
-	dev_priv->regs = pci_iomap(dev->pdev, mmio_bar, mmio_size);
-	if (!dev_priv->regs) {
-		DRM_ERROR("failed to map registers\n");
-		ret = -EIO;
+	ret = i915_mmio_setup(dev);
+	if (ret < 0)
 		goto put_bridge;
-	}
 
 	/* This must be called before any calls to HAS_PCH_* */
 	intel_detect_pch(dev);
@@ -1048,8 +1072,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 	intel_irq_init(dev_priv);
 	intel_uncore_sanitize(dev);
 
-	/* Try to make sure MCHBAR is enabled before poking at it */
-	intel_setup_mchbar(dev);
 	intel_opregion_setup(dev);
 
 	i915_gem_load_init(dev);
@@ -1130,7 +1152,7 @@ out_gtt:
 	i915_global_gtt_cleanup(dev);
 out_uncore_fini:
 	intel_uncore_fini(dev);
-	pci_iounmap(dev->pdev, dev_priv->regs);
+	i915_mmio_cleanup(dev);
 put_bridge:
 	pci_dev_put(dev_priv->bridge_dev);
 	i915_gem_load_cleanup(dev);
@@ -1214,15 +1236,12 @@ int i915_driver_unload(struct drm_device *dev)
 	intel_fbc_cleanup_cfb(dev_priv);
 	i915_gem_cleanup_stolen(dev);
 
-	intel_teardown_mchbar(dev);
-
 	pm_qos_remove_request(&dev_priv->pm_qos);
 
 	i915_global_gtt_cleanup(dev);
 
 	intel_uncore_fini(dev);
-	if (dev_priv->regs != NULL)
-		pci_iounmap(dev->pdev, dev_priv->regs);
+	i915_mmio_cleanup(dev);
 
 	i915_gem_load_cleanup(dev);
 	pci_dev_put(dev_priv->bridge_dev);
-- 
2.5.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 7/7] drm/i915: Move stolen memory initialization earlier during loading

[Imre Deak]

The only device specific dependency of the stolen memory setup is the
MMIO mapping and the stolen memory size. Both are already available in
i915_gtt_init(), so move the stolen initialization to there. The
clean-up code for i915_gtt_init() is in i915_global_gtt_cleanup(), so
move the stolen memory clean-up code there too.

This will be needed by an upcoming patch that needs the details of the
memory we reserve, but the change is also part of our generic goal to
move the initialization of resources with no or little dependencies on
other device specific resources towards the beginning of the init
sequence.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c     | 10 ----------
 drivers/gpu/drm/i915/i915_gem_gtt.c | 15 +++++++++++++++
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a054169..d23cf01 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -391,13 +391,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
 	if (ret)
 		goto cleanup_vga_client;
 
-	/* Initialise stolen first so that we may reserve preallocated
-	 * objects for the BIOS to KMS transition.
-	 */
-	ret = i915_gem_init_stolen(dev);
-	if (ret)
-		goto cleanup_vga_switcheroo;
-
 	intel_power_domains_init_hw(dev_priv, false);
 
 	intel_csr_ucode_init(dev_priv);
@@ -460,8 +453,6 @@ cleanup_irq:
 	intel_teardown_gmbus(dev);
 cleanup_csr:
 	intel_csr_ucode_fini(dev_priv);
-	i915_gem_cleanup_stolen(dev);
-cleanup_vga_switcheroo:
 	vga_switcheroo_unregister_client(dev->pdev);
 cleanup_vga_client:
 	vga_client_register(dev->pdev, NULL, NULL, NULL);
@@ -1234,7 +1225,6 @@ int i915_driver_unload(struct drm_device *dev)
 	i915_gem_context_fini(dev);
 	mutex_unlock(&dev->struct_mutex);
 	intel_fbc_cleanup_cfb(dev_priv);
-	i915_gem_cleanup_stolen(dev);
 
 	pm_qos_remove_request(&dev_priv->pm_qos);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7377b67..2ccb2b5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2809,6 +2809,8 @@ void i915_global_gtt_cleanup(struct drm_device *dev)
 		ppgtt->base.cleanup(&ppgtt->base);
 	}
 
+	i915_gem_cleanup_stolen(dev);
+
 	if (drm_mm_initialized(&vm->mm)) {
 		if (intel_vgpu_active(dev))
 			intel_vgt_deballoon();
@@ -3181,6 +3183,14 @@ int i915_gem_gtt_init(struct drm_device *dev)
 	if (ret)
 		return ret;
 
+	/*
+	 * Initialise stolen early so that we may reserve preallocated
+	 * objects for the BIOS to KMS transition.
+	 */
+	ret = i915_gem_init_stolen(dev);
+	if (ret)
+		goto out_gtt_cleanup;
+
 	/* GMADR is the PCI mmio aperture into the global GTT. */
 	DRM_INFO("Memory usable by graphics device = %lluM\n",
 		 gtt->base.total >> 20);
@@ -3200,6 +3210,11 @@ int i915_gem_gtt_init(struct drm_device *dev)
 	DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt);
 
 	return 0;
+
+out_gtt_cleanup:
+	gtt->base.cleanup(&dev_priv->gtt.base);
+
+	return ret;
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_device *dev)
-- 
2.5.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: failure for drm/i915: Move load time stolen memory init earlier

[Patchwork]

== Summary ==

Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly: 2016y-01m-18d-16h-50m-37s UTC integration manifest

Test gem_ctx_basic:
                pass       -> FAIL       (bdw-ultra)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (skl-i5k-2)
Test pm_rpm:
        Subgroup basic-rte:
                dmesg-warn -> PASS       (byt-nuc) UNSTABLE

bdw-nuci7        total:140  pass:131  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:140  pass:132  dwarn:0   dfail:1   fail:1   skip:6  
byt-nuc          total:143  pass:126  dwarn:2   dfail:0   fail:0   skip:15 
hsw-brixbox      total:143  pass:136  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:143  pass:139  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:143  pass:102  dwarn:3   dfail:0   fail:0   skip:38 
ivb-t430s        total:137  pass:124  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:143  pass:134  dwarn:1   dfail:0   fail:0   skip:8  
snb-dellxps      total:143  pass:124  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:143  pass:124  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1220/

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✗ Fi.CI.BAT: failure for drm/i915: Move load time stolen memory init earlier

[Imre Deak]

On ti, 2016-01-19 at 13:49 +0000, Patchwork wrote:
> == Summary ==
> 
> Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly:
> 2016y-01m-18d-16h-50m-37s UTC integration manifest
> 
> Test gem_ctx_basic:
>                 pass       -> FAIL       (bdw-ultra)

Couldn't reproduce it on the same machine. To me it looks unrelated as
it happened already several times for other patches, always on the same
machine. These BAT results are not shown on the test's "long term"
history btw. I filed a bug: 
https://bugs.freedesktop.org/show_bug.cgi?id=93776

> Test kms_flip:
>         Subgroup basic-flip-vs-dpms:
>                 dmesg-warn -> PASS       (skl-i5k-2)
> Test pm_rpm:
>         Subgroup basic-rte:
>                 dmesg-warn -> PASS       (byt-nuc) UNSTABLE
> 
> bdw-
> nuci7        total:140  pass:131  dwarn:0   dfail:0   fail:0   skip:9
>   
> bdw-
> ultra        total:140  pass:132  dwarn:0   dfail:1   fail:1   skip:6
>   
> byt-
> nuc          total:143  pass:126  dwarn:2   dfail:0   fail:0   skip:1
> 5 
> hsw-
> brixbox      total:143  pass:136  dwarn:0   dfail:0   fail:0   skip:7
>   
> hsw-
> gt2          total:143  pass:139  dwarn:0   dfail:0   fail:0   skip:4
>   
> ilk-
> hp8440p      total:143  pass:102  dwarn:3   dfail:0   fail:0   skip:3
> 8 
> ivb-
> t430s        total:137  pass:124  dwarn:3   dfail:4   fail:0   skip:6
>   
> skl-i5k-
> 2        total:143  pass:134  dwarn:1   dfail:0   fail:0   skip:8  
> snb-
> dellxps      total:143  pass:124  dwarn:5   dfail:0   fail:0   skip:1
> 4 
> snb-
> x220t        total:143  pass:124  dwarn:5   dfail:0   fail:1   skip:1
> 3 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1220/
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/7] drm/i915: Sanitize up DMC/CSR ucode cleanup code

[David Weinehall]

On Tue, Jan 19, 2016 at 03:26:26PM +0200, Imre Deak wrote:
> commit ebae38d061df3deffa7c17b030ea14a5216ee55f
> Author: Animesh Manna <animesh.manna@intel.com>
> Date:   Wed Oct 28 23:58:55 2015 +0200
> 
>     drm/i915/gen9: csr_init after runtime pm enable
> 
> moved the DMC/CSR initialization later during driver loading, but didn't
> move the cleanup earlier correspondingly during unloading. Fix this up.
> 
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: David Weinehall <david.weinehall@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/7] drm/i915: Sanitize i915_get_bridge_dev() error path

[David Weinehall]

On Tue, Jan 19, 2016 at 03:26:27PM +0200, Imre Deak wrote:
> Clarify the name of the label on the error path, making it clear what's
> being cleaned up. The kmem_cache_destroy() calls are NOPs on the
> corresponding error path.
> 
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: David Weinehall <david.weinehall@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/7] drm/i915: Sanitize GEM shrinker init and clean-up

[David Weinehall]

On Tue, Jan 19, 2016 at 03:26:28PM +0200, Imre Deak wrote:
> Factor out the common GEM shrinker clean-up code and call the shrinker
> init function from the same function from where the corresponding
> shrinker clean-up function is called. Also add sanity checking to the
> shrinker and OOM registration calls.
> 
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: David Weinehall <david.weinehall@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/7] drm/i915: Sanitize i915_gem_load() init and clean-up

[David Weinehall]

On Tue, Jan 19, 2016 at 03:26:29PM +0200, Imre Deak wrote:
> Factor out common clean-up code for the GEM load time init function.
> Also rename i915_gem_load() to i915_gem_load_init() to have a better
> match with its new clean-up function.
> 
> No functional change.
> 
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: David Weinehall <david.weinehall@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 5/7] drm/i915: Move allocation of various workqueues earlier during init

[David Weinehall]

On Tue, Jan 19, 2016 at 03:26:30PM +0200, Imre Deak wrote:
> Workqueue initalization doesn't depend on any other device specific
> resource, so move it close to the beginning, so we don't need to
> consider them when thinking about dependencies for other resources.
> 
> Also factor out things to separate init/cleanup functions to make
> i915_driver_load()/unload() clearer, atm it's somewhat difficult to
> follow there in what order resources are inited/cleaned-up.
> 
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: David Weinehall <david.weinehall@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 6/7] drm/i915: Move MCHBAR setup earlier during init

[David Weinehall]

On Tue, Jan 19, 2016 at 03:26:31PM +0200, Imre Deak wrote:
> Move the MCHBAR setup right after the MMIO setup, since the two things
> are logically related and the MCHBAR setup code doesn't depend on any
> other device specific resource. We'll also need MCHBAR to be ready
> earlier in an upcoming patch, so this is also a preparation for that.
> 
> Factor out the init/clean-up code to separate functions to make things
> clearer in the i915_driver_load()/unload() functions.
> 
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: David Weinehall <david.weinehall@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 7/7] drm/i915: Move stolen memory initialization earlier during loading

[David Weinehall]

On Tue, Jan 19, 2016 at 03:26:32PM +0200, Imre Deak wrote:
> The only device specific dependency of the stolen memory setup is the
> MMIO mapping and the stolen memory size. Both are already available in
> i915_gtt_init(), so move the stolen initialization to there. The
> clean-up code for i915_gtt_init() is in i915_global_gtt_cleanup(), so
> move the stolen memory clean-up code there too.
> 
> This will be needed by an upcoming patch that needs the details of the
> memory we reserve, but the change is also part of our generic goal to
> move the initialization of resources with no or little dependencies on
> other device specific resources towards the beginning of the init
> sequence.
> 
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: David Weinehall <david.weinehall@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✗ Fi.CI.BAT: failure for drm/i915: Move load time stolen memory init earlier

[Daniel Vetter]

On Tue, Jan 19, 2016 at 06:22:21PM +0200, Imre Deak wrote:
> On ti, 2016-01-19 at 13:49 +0000, Patchwork wrote:
> > == Summary ==
> > 
> > Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly:
> > 2016y-01m-18d-16h-50m-37s UTC integration manifest
> > 
> > Test gem_ctx_basic:
> >                 pass       -> FAIL       (bdw-ultra)
> 
> Couldn't reproduce it on the same machine. To me it looks unrelated as
> it happened already several times for other patches, always on the same
> machine. These BAT results are not shown on the test's "long term"
> history btw. I filed a bug: 

long term only shows changes, not all tests. Which means it didn't yet
fail in -nightly, which is somewhat suspicious ... But I agree that this
seems to have blown up a few times in other CI runs.
-Daniel

> https://bugs.freedesktop.org/show_bug.cgi?id=93776
> 
> > Test kms_flip:
> >         Subgroup basic-flip-vs-dpms:
> >                 dmesg-warn -> PASS       (skl-i5k-2)
> > Test pm_rpm:
> >         Subgroup basic-rte:
> >                 dmesg-warn -> PASS       (byt-nuc) UNSTABLE
> > 
> > bdw-
> > nuci7        total:140  pass:131  dwarn:0   dfail:0   fail:0   skip:9
> >   
> > bdw-
> > ultra        total:140  pass:132  dwarn:0   dfail:1   fail:1   skip:6
> >   
> > byt-
> > nuc          total:143  pass:126  dwarn:2   dfail:0   fail:0   skip:1
> > 5 
> > hsw-
> > brixbox      total:143  pass:136  dwarn:0   dfail:0   fail:0   skip:7
> >   
> > hsw-
> > gt2          total:143  pass:139  dwarn:0   dfail:0   fail:0   skip:4
> >   
> > ilk-
> > hp8440p      total:143  pass:102  dwarn:3   dfail:0   fail:0   skip:3
> > 8 
> > ivb-
> > t430s        total:137  pass:124  dwarn:3   dfail:4   fail:0   skip:6
> >   
> > skl-i5k-
> > 2        total:143  pass:134  dwarn:1   dfail:0   fail:0   skip:8  
> > snb-
> > dellxps      total:143  pass:124  dwarn:5   dfail:0   fail:0   skip:1
> > 4 
> > snb-
> > x220t        total:143  pass:124  dwarn:5   dfail:0   fail:1   skip:1
> > 3 
> > 
> > Results at /archive/results/CI_IGT_test/Patchwork_1220/
> > 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✗ Fi.CI.BAT: failure for drm/i915: Move load time stolen memory init earlier

[Imre Deak]

On ma, 2016-01-25 at 17:21 +0100, Daniel Vetter wrote:
> On Tue, Jan 19, 2016 at 06:22:21PM +0200, Imre Deak wrote:
> > On ti, 2016-01-19 at 13:49 +0000, Patchwork wrote:
> > > == Summary ==
> > > 
> > > Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-
> > > nightly:
> > > 2016y-01m-18d-16h-50m-37s UTC integration manifest
> > > 
> > > Test gem_ctx_basic:
> > >                 pass       -> FAIL       (bdw-ultra)
> > 
> > Couldn't reproduce it on the same machine. To me it looks unrelated
> > as
> > it happened already several times for other patches, always on the
> > same
> > machine. These BAT results are not shown on the test's "long term"
> > history btw. I filed a bug: 
> 
> long term only shows changes, not all tests.

Ok, so I take that's changes for CI runs, but not for patchwork
initiated tests.

> Which means it didn't yet
> fail in -nightly, which is somewhat suspicious ... But I agree that
> this
> seems to have blown up a few times in other CI runs.

Ok, so based on that this patchset is good to go I guess.

Still not sure why the test fails. One thing I noticed is a bunch of
"gem_concurrent: drop caches" messages in dmesg before any test would
be even started. So I think something in gem_concurrent is not guarded
with igt_fixture{} and gets to run when piglit enumerates the subtests
(to get the BAT subtests). Not sure though if this has a negative
effect on anything.

--Imre

> -Daniel
> 
> > https://bugs.freedesktop.org/show_bug.cgi?id=93776
> > 
> > > Test kms_flip:
> > >         Subgroup basic-flip-vs-dpms:
> > >                 dmesg-warn -> PASS       (skl-i5k-2)
> > > Test pm_rpm:
> > >         Subgroup basic-rte:
> > >                 dmesg-warn -> PASS       (byt-nuc) UNSTABLE
> > > 
> > > bdw-
> > > nuci7        total:140  pass:131  dwarn:0   dfail:0   fail:0   sk
> > > ip:9
> > >   
> > > bdw-
> > > ultra        total:140  pass:132  dwarn:0   dfail:1   fail:1   sk
> > > ip:6
> > >   
> > > byt-
> > > nuc          total:143  pass:126  dwarn:2   dfail:0   fail:0   sk
> > > ip:1
> > > 5 
> > > hsw-
> > > brixbox      total:143  pass:136  dwarn:0   dfail:0   fail:0   sk
> > > ip:7
> > >   
> > > hsw-
> > > gt2          total:143  pass:139  dwarn:0   dfail:0   fail:0   sk
> > > ip:4
> > >   
> > > ilk-
> > > hp8440p      total:143  pass:102  dwarn:3   dfail:0   fail:0   sk
> > > ip:3
> > > 8 
> > > ivb-
> > > t430s        total:137  pass:124  dwarn:3   dfail:4   fail:0   sk
> > > ip:6
> > >   
> > > skl-i5k-
> > > 2        total:143  pass:134  dwarn:1   dfail:0   fail:0   skip:8
> > >   
> > > snb-
> > > dellxps      total:143  pass:124  dwarn:5   dfail:0   fail:0   sk
> > > ip:1
> > > 4 
> > > snb-
> > > x220t        total:143  pass:124  dwarn:5   dfail:0   fail:1   sk
> > > ip:1
> > > 3 
> > > 
> > > Results at /archive/results/CI_IGT_test/Patchwork_1220/
> > > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✗ Fi.CI.BAT: failure for drm/i915: Move load time stolen memory init earlier

[Daniel Vetter]

On Mon, Jan 25, 2016 at 07:34:08PM +0200, Imre Deak wrote:
> On ma, 2016-01-25 at 17:21 +0100, Daniel Vetter wrote:
> > On Tue, Jan 19, 2016 at 06:22:21PM +0200, Imre Deak wrote:
> > > On ti, 2016-01-19 at 13:49 +0000, Patchwork wrote:
> > > > == Summary ==
> > > > 
> > > > Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-
> > > > nightly:
> > > > 2016y-01m-18d-16h-50m-37s UTC integration manifest
> > > > 
> > > > Test gem_ctx_basic:
> > > >                 pass       -> FAIL       (bdw-ultra)
> > > 
> > > Couldn't reproduce it on the same machine. To me it looks unrelated
> > > as
> > > it happened already several times for other patches, always on the
> > > same
> > > machine. These BAT results are not shown on the test's "long term"
> > > history btw. I filed a bug: 
> > 
> > long term only shows changes, not all tests.
> 
> Ok, so I take that's changes for CI runs, but not for patchwork
> initiated tests.
> 
> > Which means it didn't yet
> > fail in -nightly, which is somewhat suspicious ... But I agree that
> > this
> > seems to have blown up a few times in other CI runs.
> 
> Ok, so based on that this patchset is good to go I guess.
> 
> Still not sure why the test fails. One thing I noticed is a bunch of
> "gem_concurrent: drop caches" messages in dmesg before any test would
> be even started. So I think something in gem_concurrent is not guarded
> with igt_fixture{} and gets to run when piglit enumerates the subtests
> (to get the BAT subtests). Not sure though if this has a negative
> effect on anything.

We iirc drop caches as part of gem_quiescent too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 7/7] drm/i915: Move stolen memory initialization earlier during loading

[Imre Deak]

On pe, 2016-01-22 at 14:23 +0200, David Weinehall wrote:
> On Tue, Jan 19, 2016 at 03:26:32PM +0200, Imre Deak wrote:
> > The only device specific dependency of the stolen memory setup is
> > the
> > MMIO mapping and the stolen memory size. Both are already available
> > in
> > i915_gtt_init(), so move the stolen initialization to there. The
> > clean-up code for i915_gtt_init() is in i915_global_gtt_cleanup(),
> > so
> > move the stolen memory clean-up code there too.
> > 
> > This will be needed by an upcoming patch that needs the details of
> > the
> > memory we reserve, but the change is also part of our generic goal
> > to
> > move the initialization of resources with no or little dependencies
> > on
> > other device specific resources towards the beginning of the init
> > sequence.
> > 
> > Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> 
> Reviewed-by: David Weinehall <david.weinehall@intel.com>

I pushed the series to dinq, thanks for the review.

--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx