[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [CI,1/4] drm/i915: Add distinct stubs for PM hibernation phases
== Series Details == Series: series starting with [CI,1/4] drm/i915: Add distinct stubs for PM hibernation phases URL : https://patchwork.freedesktop.org/series/7181/ State : warning == Summary == Series 7181v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/7181/revisions/1/mbox Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: fail -> PASS (ro-byt-n2820) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-c: pass -> DMESG-WARN (ro-ivb2-i7-3770) Test kms_sink_crc_basic: pass -> SKIP (ro-skl-i7-6700hq) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:175 dwarn:0 dfail:0 fail:2 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb2-i7-3770 total:219 pass:186 dwarn:1 dfail:0 fail:0 skip:32 ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 ro-ivb-i7-3770 failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_902/ 1a536db drm-intel-nightly: 2016y-05m-13d-21h-21m-06s UTC integration manifest 663bbb0 drm/i915: Skip clearing the GGTT on full-ppgtt systems 189c157 drm/i915: Lazily migrate the objects after hibernation 76aa440 drm/i915: Update domain tracking for GEM objects on hibernation 19042cc drm/i915: Add distinct stubs for PM hibernation phases ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/4] drm/i915: Add distinct stubs for PM hibernation phases
Currently for handling the extra hibernation phases we just call the
equivalent suspend/resume phases. In the next couple of patches, I wish
to specialise the hibernation phases to reduce the amount of work
required for handling GEM objects.
v2: There are more! Don't forget the freeze phases.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5ae79601335c..6a2e7f84276b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1115,6 +1115,39 @@ static int i915_pm_resume(struct device *dev)
return i915_drm_resume(drm_dev);
}
+/* freeze: before creating the hibernation_image */
+static int i915_pm_freeze(struct device *dev)
+{
+ return i915_pm_suspend(dev);
+}
+
+static int i915_pm_freeze_late(struct device *dev)
+{
+ return i915_pm_suspend_late(dev);
+}
+
+/* thaw: called after creating the hibernation image, but before turning off.
*/
+static int i915_pm_thaw_early(struct device *dev)
+{
+ return i915_pm_resume_early(dev);
+}
+
+static int i915_pm_thaw(struct device *dev)
+{
+ return i915_pm_resume(dev);
+}
+
+/* restore: called after loading the hibernation image. */
+static int i915_pm_restore_early(struct device *dev)
+{
+ return i915_pm_resume_early(dev);
+}
+
+static int i915_pm_restore(struct device *dev)
+{
+ return i915_pm_resume(dev);
+}
+
/*
* Save all Gunit registers that may be lost after a D3 and a subsequent
* S0i[R123] transition. The list of registers needing a save/restore is
@@ -1669,14 +1702,14 @@ static const struct dev_pm_ops i915_pm_ops = {
* @restore, @restore_early : called after rebooting and restoring the
*hibernation image [PMSG_RESTORE]
*/
- .freeze = i915_pm_suspend,
- .freeze_late = i915_pm_suspend_late,
- .thaw_early = i915_pm_resume_early,
- .thaw = i915_pm_resume,
+ .freeze = i915_pm_freeze,
+ .freeze_late = i915_pm_freeze_late,
+ .thaw_early = i915_pm_thaw_early,
+ .thaw = i915_pm_thaw,
.poweroff = i915_pm_suspend,
.poweroff_late = i915_pm_poweroff_late,
- .restore_early = i915_pm_resume_early,
- .restore = i915_pm_resume,
+ .restore_early = i915_pm_restore_early,
+ .restore = i915_pm_restore,
/* S0ix (via runtime suspend) event handlers */
.runtime_suspend = intel_runtime_suspend,
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/4] drm/i915: Lazily migrate the objects after hibernation
Now that we mark the object domains for having been restored from the
hibernation image, we not need to flush everything during resume and
can instead rely on the normal domain tracking to flush only when
required. The only caveat here are objects that are pinned for use by
the hardware, whose contents must be coherent for when the device
resumes reading from then (shortly afterwards with the driver assuming
the objects are in the correct domain).
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Tested-by: David Weinehall
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5fb14c835543..319f3b459b3e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3245,7 +3245,6 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
struct i915_ggtt *ggtt = &dev_priv->ggtt;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- bool flush;
i915_check_and_clear_faults(dev_priv);
@@ -3255,19 +3254,16 @@ void i915_gem_restore_gtt_mappings(struct drm_device
*dev)
/* Cache flush objects bound into GGTT and rebind them. */
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
- flush = false;
list_for_each_entry(vma, &obj->vma_list, obj_link) {
if (vma->vm != &ggtt->base)
continue;
WARN_ON(i915_vma_bind(vma, obj->cache_level,
PIN_UPDATE));
-
- flush = true;
}
- if (flush)
- i915_gem_clflush_object(obj, obj->pin_display);
+ if (obj->pin_display)
+ WARN_ON(i915_gem_object_set_to_gtt_domain(obj, false));
}
if (INTEL_INFO(dev)->gen >= 8) {
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] drm/i915: Skip clearing the GGTT on full-ppgtt systems
Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.
For aliasing-ppgtt, we could almost do the same except that we do allow
userspace access to the global-GTT via execbuf in order to workraound
some quirks of certain instructions. (This execbuf path is filtered out
with EINVAL on full-ppgtt.)
The most dramatic effect this will have will be during resume, as with
full-ppgtt the GGTT is only used sparingly.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Tested-by: David Weinehall
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 319f3b459b3e..7eab619a3eb2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2477,6 +2477,13 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
+static void nop_clear_range(struct i915_address_space *vm,
+ uint64_t start,
+ uint64_t length,
+ bool use_scratch)
+{
+}
+
static void gen8_ggtt_clear_range(struct i915_address_space *vm,
uint64_t start,
uint64_t length,
@@ -3072,14 +3079,17 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ret = ggtt_probe_common(dev, ggtt->size);
- ggtt->base.clear_range = gen8_ggtt_clear_range;
- if (IS_CHERRYVIEW(dev_priv))
- ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
- else
- ggtt->base.insert_entries = gen8_ggtt_insert_entries;
ggtt->base.bind_vma = ggtt_bind_vma;
ggtt->base.unbind_vma = ggtt_unbind_vma;
+ ggtt->base.clear_range = nop_clear_range;
+ if (!USES_FULL_PPGTT(dev_priv))
+ ggtt->base.clear_range = gen8_ggtt_clear_range;
+
+ ggtt->base.insert_entries = gen8_ggtt_insert_entries;
+ if (IS_CHERRYVIEW(dev_priv))
+ ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
+
return ret;
}
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/4] drm/i915: Update domain tracking for GEM objects on hibernation
When creating the hibernation image, the CPU will read the pages of all
objects and thus conflict with our domain tracking. We need to update
our domain tracking to accurately reflect the state on restoration.
v2: Perform the domain tracking inside freeze, before the image is
written, rather than upon restoration.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 12 +++-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 28
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6a2e7f84276b..dba03c026151 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1123,7 +1123,17 @@ static int i915_pm_freeze(struct device *dev)
static int i915_pm_freeze_late(struct device *dev)
{
- return i915_pm_suspend_late(dev);
+ int ret;
+
+ ret = i915_pm_suspend_late(dev);
+ if (ret)
+ return ret;
+
+ ret = i915_gem_freeze_late(dev_to_i915(dev));
+ if (ret)
+ return ret;
+
+ return 0;
}
/* thaw: called after creating the hibernation image, but before turning off.
*/
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ba614193cc9..72f0b02a8372 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2976,6 +2976,8 @@ int i915_gem_wait_ioctl(struct drm_device *dev, void
*data,
void i915_gem_load_init(struct drm_device *dev);
void i915_gem_load_cleanup(struct drm_device *dev);
void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
+int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
+
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 a3d826bb216b..aff386eea8ce 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5051,6 +5051,34 @@ void i915_gem_load_cleanup(struct drm_device *dev)
kmem_cache_destroy(dev_priv->objects);
}
+int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
+{
+ struct drm_i915_gem_object *obj;
+
+ /* Called just before we write the hibernation image.
+*
+* We need to update the domain tracking to reflect that the CPU
+* will be accessing all the pages to create and restore from the
+* hibernation, and so upon restoration those pages will be in the
+* CPU domain.
+*
+* To make sure the hibernation image contains the latest state,
+* we update that state just before writing out the image.
+*/
+
+ list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list) {
+ obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+ }
+
+ list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
+ obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+ }
+
+ return 0;
+}
+
void i915_gem_release(struct drm_device *dev, struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: SKL/KBL/BXT cdclk stuff
== Series Details == Series: drm/i915: SKL/KBL/BXT cdclk stuff URL : https://patchwork.freedesktop.org/series/7169/ State : failure == Summary == Series 7169v1 drm/i915: SKL/KBL/BXT cdclk stuff http://patchwork.freedesktop.org/api/1.0/series/7169/revisions/1/mbox Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: fail -> PASS (ro-byt-n2820) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ro-hsw-i3-4010u) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (ro-ivb2-i7-3770) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:175 dwarn:0 dfail:0 fail:2 skip:41 ro-hsw-i3-4010u total:218 pass:192 dwarn:0 dfail:0 fail:1 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb2-i7-3770 total:219 pass:186 dwarn:1 dfail:0 fail:0 skip:32 ro-skl-i7-6700hq total:214 pass:190 dwarn:0 dfail:0 fail:0 skip:24 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 ro-ivb-i7-3770 failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_900/ 1a536db drm-intel-nightly: 2016y-05m-13d-21h-21m-06s UTC integration manifest b974b6b drm/i915: Set BXT cdclk to minimum initially c75fe510 drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk check ef3fb6c drm/i915: Make bxt_set_cdclk() operate in terms of the current vs target DE PLL vco b8ee27d drm/i915: Rewrite broxton_get_display_clock_speed() in terms of the DE PLL vco/refclk 77095f2 drm/i915: Update cached cdclk state from broxton_init_cdclk() 7c27fe0 drm/i915: Store BXT DE PLL vco and ref clocks in dev_priv 351a2e3 drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk() dabb9dd drm/i915: Store cdclk PLL reference clock under dev_priv 995467c drm/i915: Rename skl_vco_freq to cdclk_pll.vco 19f5564 drm/i915: Make 308 and 671 MHz cdclks more accurate on SKL 3499324 drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit 75083d8 drm/i915: Unify SKL cdclk init paths 0b482fa drm/i915: Beef up skl_sanitize_cdclk() a bit 5fe223b drm/i915: Keep track of preferred cdclk vco frequency on SKL b878f36 drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL 8fbef2c drm/i915: Report the current DPLL0 vco on SKL/KBL 244d5cc drm/i915: Actually read out DPLL0 vco on skl from hardware 7d03efe drm/i915: Extract skl_calc_cdclk() e2cd537 drm/i915: Move the SKL DPLL0 VCO computation into intel_dp_compute_config() 732fab3 drm/i915/skl: SKL CDCLK change on modeset tracking VCO e53fa8e drm/i915: Fix BXT min_pixclk after state readout ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Refresh cached DP port register value on resume
== Series Details == Series: drm/i915: Refresh cached DP port register value on resume URL : https://patchwork.freedesktop.org/series/7163/ State : failure == Summary == Series 7163v1 drm/i915: Refresh cached DP port register value on resume http://patchwork.freedesktop.org/api/1.0/series/7163/revisions/1/mbox Test drv_hangman: Subgroup error-state-basic: pass -> FAIL (ro-ilk1-i5-650) Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: fail -> PASS (ro-byt-n2820) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ro-ivb2-i7-3770) pass -> FAIL (ro-byt-n2820) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:174 dwarn:0 dfail:0 fail:3 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:151 dwarn:0 dfail:0 fail:2 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:186 dwarn:0 dfail:0 fail:1 skip:32 ro-skl-i7-6700hq total:214 pass:190 dwarn:0 dfail:0 fail:0 skip:24 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_899/ 1a536db drm-intel-nightly: 2016y-05m-13d-21h-21m-06s UTC integration manifest 9b3616e drm/i915: Refresh cached DP port register value on resume ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix for resume regression in ilk-bdw due to watermarks (rev2)
On Fri, May 13, 2016 at 07:04:07PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks > (rev2) > URL : https://patchwork.freedesktop.org/series/7155/ > State : failure > > == Summary == > > Series 7155v2 drm/i915: Fix for resume regression in ilk-bdw due to watermarks > http://patchwork.freedesktop.org/api/1.0/series/7155/revisions/2/mbox > > Test drv_hangman: > Subgroup error-state-basic: > fail -> PASS (ro-ilk1-i5-650) > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-cmd: > pass -> FAIL (ro-byt-n2820) https://bugs.freedesktop.org/show_bug.cgi?id=95372 Pushed to dinq; thanks for the patches. Matt > > ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 > ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 > ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 > ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 > ro-byt-n2820 total:218 pass:174 dwarn:0 dfail:0 fail:3 skip:41 > ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 > ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 > ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 > ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 > ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 > ro-ivb2-i7-3770 total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 > ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 > ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 > > Results at /archive/results/CI_IGT_test/RO_Patchwork_897/ > > accd824 drm-intel-nightly: 2016y-05m-13d-14h-38m-15s UTC integration manifest > 4fc355d drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2) > 03bf66b drm/i915: Don't leave old junk in ilk active watermarks on readout > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/21] drm/i915: Make bxt_set_cdclk() operate in terms of the current vs target DE PLL vco
From: Ville Syrjälä
Make bxt_set_cdclk() more readable by looking at current vs. target
DE PLL vco to determine if the DE PLL needs disabling and/or enabling.
We can also calculate the CD2X divider simply as (vco/cdclk) instead of
depending on magic numbers.
The magic numbers are still needed though, but only to map the supported
cdclk frequencies to corresponding DE PLL frequencies.
Note that w'll now program CDCLK_CTL correctly even for the bypass case.
Actually the CD2X divider should not matter in that case since the
hardware will bypass it too, but the "decimal" part should matter (if we
want to do gmbus/aux with the bypass enabled).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 128 +--
1 file changed, 63 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4542c1f5012f..14bc14c7827b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5358,6 +5358,30 @@ static int skl_cdclk_decimal(int cdclk)
return DIV_ROUND_CLOSEST(cdclk - 1000, 500);
}
+static int bxt_de_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
+{
+ int ratio;
+
+ if (cdclk == dev_priv->cdclk_pll.ref)
+ return 0;
+
+ switch (cdclk) {
+ default:
+ MISSING_CASE(cdclk);
+ case 144000:
+ case 288000:
+ case 384000:
+ case 576000:
+ ratio = 60;
+ break;
+ case 624000:
+ ratio = 65;
+ break;
+ }
+
+ return dev_priv->cdclk_pll.ref * ratio;
+}
+
static void bxt_de_pll_disable(struct drm_i915_private *dev_priv)
{
I915_WRITE(BXT_DE_PLL_ENABLE, 0);
@@ -5369,13 +5393,14 @@ static void bxt_de_pll_disable(struct drm_i915_private
*dev_priv)
dev_priv->cdclk_pll.vco = 0;
}
-static void bxt_de_pll_enable(struct drm_i915_private *dev_priv, u32 ratio)
+static void bxt_de_pll_enable(struct drm_i915_private *dev_priv, int vco)
{
+ int ratio = DIV_ROUND_CLOSEST(vco, dev_priv->cdclk_pll.ref);
u32 val;
val = I915_READ(BXT_DE_PLL_CTL);
val &= ~BXT_DE_PLL_RATIO_MASK;
- val |= ratio;
+ val |= BXT_DE_PLL_RATIO(ratio);
I915_WRITE(BXT_DE_PLL_CTL, val);
I915_WRITE(BXT_DE_PLL_ENABLE, BXT_DE_PLL_PLL_ENABLE);
@@ -5384,54 +5409,42 @@ static void bxt_de_pll_enable(struct drm_i915_private
*dev_priv, u32 ratio)
if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) != 0, 1))
DRM_ERROR("timeout waiting for DE PLL lock\n");
- dev_priv->cdclk_pll.vco = ratio * dev_priv->cdclk_pll.ref;
+ dev_priv->cdclk_pll.vco = vco;
}
static void broxton_set_cdclk(struct drm_i915_private *dev_priv, int cdclk)
{
- uint32_t divider;
- uint32_t ratio;
- uint32_t current_cdclk;
- int ret;
+ u32 val, divider;
+ int vco, ret;
- /* frequency = 19.2MHz * ratio / 2 / div{1,1.5,2,4} */
- switch (cdclk) {
- case 144000:
+ vco = bxt_de_pll_vco(dev_priv, cdclk);
+
+ DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
+
+ /* cdclk = vco / 2 / div{1,1.5,2,4} */
+ switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
+ case 8:
divider = BXT_CDCLK_CD2X_DIV_SEL_4;
- ratio = BXT_DE_PLL_RATIO(60);
break;
- case 288000:
+ case 4:
divider = BXT_CDCLK_CD2X_DIV_SEL_2;
- ratio = BXT_DE_PLL_RATIO(60);
break;
- case 384000:
+ case 3:
divider = BXT_CDCLK_CD2X_DIV_SEL_1_5;
- ratio = BXT_DE_PLL_RATIO(60);
- break;
- case 576000:
- divider = BXT_CDCLK_CD2X_DIV_SEL_1;
- ratio = BXT_DE_PLL_RATIO(60);
break;
- case 624000:
+ case 2:
divider = BXT_CDCLK_CD2X_DIV_SEL_1;
- ratio = BXT_DE_PLL_RATIO(65);
- break;
- case 19200:
- /*
-* Bypass frequency with DE PLL disabled. Init ratio, divider
-* to suppress GCC warning.
-*/
- ratio = 0;
- divider = 0;
break;
default:
- DRM_ERROR("unsupported CDCLK freq %d", cdclk);
+ WARN_ON(cdclk != dev_priv->cdclk_pll.ref);
+ WARN_ON(vco != 0);
- return;
+ divider = BXT_CDCLK_CD2X_DIV_SEL_1;
+ break;
}
- mutex_lock(&dev_priv->rps.hw_lock);
/* Inform power controller of upcoming frequency change */
+ mutex_lock(&dev_priv->rps.hw_lock);
ret = sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ,
0x8000);
mutex_unlock(&dev_priv->rps.hw_lock);
@@ -5442,40 +5455,26 @@ static v
[Intel-gfx] [PATCH 18/21] drm/i915: Rewrite broxton_get_display_clock_speed() in terms of the DE PLL vco/refclk
From: Ville Syrjälä
Now that we've read out the DE PLL vco and refclk, we can just use them
in the cdclk calculation. While at it switch over to
DIV_ROUND_CLOSEST().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 834373503a8d..4542c1f5012f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6720,31 +6720,36 @@ static void bxt_de_pll_update(struct drm_i915_private
*dev_priv)
static int broxton_get_display_clock_speed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- uint32_t cdctl = I915_READ(CDCLK_CTL);
- uint32_t pll_ratio = I915_READ(BXT_DE_PLL_CTL) & BXT_DE_PLL_RATIO_MASK;
- uint32_t pll_enab = I915_READ(BXT_DE_PLL_ENABLE);
- int cdclk;
+ u32 divider;
+ int div, vco;
bxt_de_pll_update(dev_priv);
- if (!(pll_enab & BXT_DE_PLL_PLL_ENABLE))
- return 19200;
+ vco = dev_priv->cdclk_pll.vco;
+ if (vco == 0)
+ return dev_priv->cdclk_pll.ref;
- cdclk = 19200 * pll_ratio / 2;
+ divider = I915_READ(CDCLK_CTL) & BXT_CDCLK_CD2X_DIV_SEL_MASK;
- switch (cdctl & BXT_CDCLK_CD2X_DIV_SEL_MASK) {
+ switch (divider) {
case BXT_CDCLK_CD2X_DIV_SEL_1:
- return cdclk; /* 576MHz or 624MHz */
+ div = 2;
+ break;
case BXT_CDCLK_CD2X_DIV_SEL_1_5:
- return cdclk * 2 / 3; /* 384MHz */
+ div = 3;
+ break;
case BXT_CDCLK_CD2X_DIV_SEL_2:
- return cdclk / 2; /* 288MHz */
+ div = 4;
+ break;
case BXT_CDCLK_CD2X_DIV_SEL_4:
- return cdclk / 4; /* 144MHz */
+ div = 8;
+ break;
+ default:
+ MISSING_CASE(divider);
+ return dev_priv->cdclk_pll.ref;
}
- /* error case, do as if DE PLL isn't enabled */
- return 19200;
+ return DIV_ROUND_CLOSEST(vco, div);
}
static int broadwell_get_display_clock_speed(struct drm_device *dev)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/21] drm/i915: Set BXT cdclk to minimum initially
From: Ville Syrjälä
In case the driver is initialized without active displays, we should
just drop the cdclk to the minimum frequency right off the bat. There
might not be a modeset to drop it to the minimum late rafter all.
With DMC supposedly we should always have the cdclk up and running.
The DMC will shut the DE PLL down when appropriate, so let's nuke
the related FIXMEs as well. Trying to do anything different would
go against the expectations of the DMC firmware, and we all know
how fragile the DMC firmware is.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9725ba59716e..ac8d448e96d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -118,6 +118,7 @@ static void ironlake_pfit_enable(struct intel_crtc *crtc);
static void intel_modeset_setup_hw_state(struct drm_device *dev);
static void intel_pre_disable_primary_noatomic(struct drm_crtc *crtc);
static int ilk_max_pixel_rate(struct drm_atomic_state *state);
+static int broxton_calc_cdclk(int max_pixclk);
struct intel_limit {
struct {
@@ -5501,10 +5502,8 @@ void broxton_init_cdclk(struct drm_i915_private
*dev_priv)
* FIXME:
* - The initial CDCLK needs to be read from VBT.
* Need to make this change after VBT has changes for BXT.
-* - check if setting the max (or any) cdclk freq is really necessary
-* here, it belongs to modeset time
*/
- broxton_set_cdclk(dev_priv, 624000);
+ broxton_set_cdclk(dev_priv, broxton_calc_cdclk(0));
}
void broxton_uninit_cdclk(struct drm_i915_private *dev_priv)
@@ -5944,10 +5943,6 @@ static int valleyview_calc_cdclk(struct drm_i915_private
*dev_priv,
static int broxton_calc_cdclk(int max_pixclk)
{
- /*
-* FIXME:
-* - set 19.2MHz bypass frequency if there are no active pipes
-*/
if (max_pixclk > 576000)
return 624000;
else if (max_pixclk > 384000)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/21] drm/i915: Store BXT DE PLL vco and ref clocks in dev_priv
From: Ville Syrjälä
We have need to know the DE PLL refclk and output frequency in various
cdclk calculations, so let's store those in dev_priv.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 76d59d1214f4..0d55e8175573 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5334,7 +5334,7 @@ static void intel_update_cdclk(struct drm_device *dev)
dev_priv->cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
- if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
+ if (INTEL_GEN(dev_priv) >= 9)
DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz, VCO: %d kHz,
ref: %d kHz\n",
dev_priv->cdclk_freq, dev_priv->cdclk_pll.vco,
dev_priv->cdclk_pll.ref);
@@ -5365,6 +5365,8 @@ static void bxt_de_pll_disable(struct drm_i915_private
*dev_priv)
/* Timeout 200us */
if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) == 0, 1))
DRM_ERROR("timeout waiting for DE PLL unlock\n");
+
+ dev_priv->cdclk_pll.vco = 0;
}
static void bxt_de_pll_enable(struct drm_i915_private *dev_priv, u32 ratio)
@@ -5381,6 +5383,8 @@ static void bxt_de_pll_enable(struct drm_i915_private
*dev_priv, u32 ratio)
/* Timeout 200us */
if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) != 0, 1))
DRM_ERROR("timeout waiting for DE PLL lock\n");
+
+ dev_priv->cdclk_pll.vco = ratio * dev_priv->cdclk_pll.ref;
}
static void broxton_set_cdclk(struct drm_i915_private *dev_priv, int cdclk)
@@ -6697,6 +6701,25 @@ static int skylake_get_display_clock_speed(struct
drm_device *dev)
return dev_priv->cdclk_pll.ref;
}
+static void bxt_de_pll_update(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ dev_priv->cdclk_pll.ref = 19200;
+
+ val = I915_READ(BXT_DE_PLL_ENABLE);
+ if ((val & BXT_DE_PLL_PLL_ENABLE) == 0) {
+ dev_priv->cdclk_pll.vco = 0;
+ return;
+ }
+
+ WARN_ON((val & BXT_DE_PLL_LOCK) == 0);
+
+ val = I915_READ(BXT_DE_PLL_CTL);
+ dev_priv->cdclk_pll.vco = (val & BXT_DE_PLL_RATIO_MASK) *
+ dev_priv->cdclk_pll.ref;
+}
+
static int broxton_get_display_clock_speed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -6705,6 +6728,8 @@ static int broxton_get_display_clock_speed(struct
drm_device *dev)
uint32_t pll_enab = I915_READ(BXT_DE_PLL_ENABLE);
int cdclk;
+ bxt_de_pll_update(dev_priv);
+
if (!(pll_enab & BXT_DE_PLL_PLL_ENABLE))
return 19200;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/21] drm/i915: Report the current DPLL0 vco on SKL/KBL
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e65c3da744b0..95997eed9dd6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5320,8 +5320,13 @@ static void intel_update_cdclk(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
dev_priv->cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
- DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz\n",
-dev_priv->cdclk_freq);
+
+ if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
+ DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz, VCO: %d MHz\n",
+dev_priv->cdclk_freq, dev_priv->skl_vco_freq);
+ else
+ DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz\n",
+dev_priv->cdclk_freq);
/*
* 9:0 CMBUS [sic] CDCLK frequency (cdfreq):
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/21] drm/i915: Actually read out DPLL0 vco on skl from hardware
From: Ville Syrjälä
Currently we're trying to guess which lcpll vco frequency is used
use based on the cdclk. That doesn't work for cdclk==540 since
both vco frequencies can generate a 540 Mhz output. Let's stop
guessing and just read the actual vco frequency from the
hardware.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 73 ++-
drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 ---
2 files changed, 37 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c1b1632664a1..e65c3da744b0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5551,31 +5551,35 @@ static int skl_calc_cdclk(int max_pixclk, int vco)
}
}
-static const struct skl_cdclk_entry {
- unsigned int freq;
- unsigned int vco;
-} skl_cdclk_frequencies[] = {
- { .freq = 308570, .vco = 8640 },
- { .freq = 337500, .vco = 8100 },
- { .freq = 432000, .vco = 8640 },
- { .freq = 45, .vco = 8100 },
- { .freq = 54, .vco = 8100 },
- { .freq = 617140, .vco = 8640 },
- { .freq = 675000, .vco = 8100 },
-};
-
-unsigned int skl_cdclk_get_vco(unsigned int freq)
+static void
+skl_dpll0_update(struct drm_i915_private *dev_priv)
{
- unsigned int i;
-
- for (i = 0; i < ARRAY_SIZE(skl_cdclk_frequencies); i++) {
- const struct skl_cdclk_entry *e = &skl_cdclk_frequencies[i];
+ u32 val;
- if (e->freq == freq)
- return e->vco;
+ val = I915_READ(LCPLL1_CTL);
+ if ((val & LCPLL_PLL_ENABLE) == 0) {
+ dev_priv->skl_vco_freq = 0;
+ return;
}
- return 8100;
+ val = I915_READ(DPLL_CTRL1);
+
+ switch (val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0)) {
+ case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, SKL_DPLL0):
+ case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1350, SKL_DPLL0):
+ case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1620, SKL_DPLL0):
+ case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2700, SKL_DPLL0):
+ dev_priv->skl_vco_freq = 8100;
+ break;
+ case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1080, SKL_DPLL0):
+ case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2160, SKL_DPLL0):
+ dev_priv->skl_vco_freq = 8640;
+ break;
+ default:
+ MISSING_CASE(val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0));
+ dev_priv->skl_vco_freq = 0;
+ break;
+ }
}
static void
@@ -6614,43 +6618,40 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
static int skylake_get_display_clock_speed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
- uint32_t cdctl = I915_READ(CDCLK_CTL);
- uint32_t linkrate;
+ uint32_t cdctl;
- if (!(lcpll1 & LCPLL_PLL_ENABLE))
- return 24000; /* 24MHz is the cd freq with NSSC ref */
+ skl_dpll0_update(dev_priv);
- if ((cdctl & CDCLK_FREQ_SEL_MASK) == CDCLK_FREQ_540)
- return 54;
+ if (dev_priv->skl_vco_freq == 0)
+ return 24000; /* 24MHz is the cd freq with NSSC ref */
- linkrate = (I915_READ(DPLL_CTRL1) &
- DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0)) >> 1;
+ cdctl = I915_READ(CDCLK_CTL);
- if (linkrate == DPLL_CTRL1_LINK_RATE_2160 ||
- linkrate == DPLL_CTRL1_LINK_RATE_1080) {
- /* vco 8640 */
+ if (dev_priv->skl_vco_freq == 8640) {
switch (cdctl & CDCLK_FREQ_SEL_MASK) {
case CDCLK_FREQ_450_432:
return 432000;
case CDCLK_FREQ_337_308:
return 308570;
+ case CDCLK_FREQ_540:
+ return 54;
case CDCLK_FREQ_675_617:
return 617140;
default:
- WARN(1, "Unknown cd freq selection\n");
+ MISSING_CASE(cdctl & CDCLK_FREQ_SEL_MASK);
}
} else {
- /* vco 8100 */
switch (cdctl & CDCLK_FREQ_SEL_MASK) {
case CDCLK_FREQ_450_432:
return 45;
case CDCLK_FREQ_337_308:
return 337500;
+ case CDCLK_FREQ_540:
+ return 54;
case CDCLK_FREQ_675_617:
return 675000;
default:
- WARN(1, "Unknown cd freq selection\n");
+ MISSING_CASE(cdctl & CDCLK_FREQ_SEL_MASK);
}
}
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 43ba60b3662e..5391ab66b64d 100644
--- a/drivers/
[Intel-gfx] [PATCH 17/21] drm/i915: Update cached cdclk state from broxton_init_cdclk()
From: Ville Syrjälä
Let's make sure our cached cdclk state is accurate right after
broxton_init_cdclk() whether or not we end up changing the cdclk
frequency.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0d55e8175573..834373503a8d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5508,13 +5508,10 @@ bool broxton_cdclk_verify_state(struct drm_i915_private
*dev_priv)
void broxton_init_cdclk(struct drm_i915_private *dev_priv)
{
- /* check if cd clock is enabled */
- if (broxton_cdclk_is_enabled(dev_priv)) {
- DRM_DEBUG_KMS("CDCLK already enabled, won't reprogram it\n");
- return;
- }
+ intel_update_cdclk(dev_priv->dev);
- DRM_DEBUG_KMS("CDCLK not enabled, enabling it\n");
+ if (dev_priv->cdclk_pll.vco != 0)
+ return;
/*
* FIXME:
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/21] drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk check
From: Ville Syrjälä
Rather than having a BXT specific function to make sure the DE PLL is
enabled after disabling DC6, let's just make sure the current cdclk
is the same as what we last programmed.
Having another check in bxt_display_core_init() almost immediately after
the cdclk init seems redundant, so let's just kill that one.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c| 15 ---
drivers/gpu/drm/i915/intel_drv.h| 1 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 8
3 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 14bc14c7827b..9725ba59716e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5490,21 +5490,6 @@ static void broxton_set_cdclk(struct drm_i915_private
*dev_priv, int cdclk)
intel_update_cdclk(dev_priv->dev);
}
-static bool broxton_cdclk_is_enabled(struct drm_i915_private *dev_priv)
-{
- if (!(I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_PLL_ENABLE))
- return false;
-
- /* TODO: Check for a valid CDCLK rate */
-
- return true;
-}
-
-bool broxton_cdclk_verify_state(struct drm_i915_private *dev_priv)
-{
- return broxton_cdclk_is_enabled(dev_priv);
-}
-
void broxton_init_cdclk(struct drm_i915_private *dev_priv)
{
intel_update_cdclk(dev_priv->dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 319e52278d1f..f1f4bde4108d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1270,7 +1270,6 @@ void hsw_enable_pc8(struct drm_i915_private *dev_priv);
void hsw_disable_pc8(struct drm_i915_private *dev_priv);
void broxton_init_cdclk(struct drm_i915_private *dev_priv);
void broxton_uninit_cdclk(struct drm_i915_private *dev_priv);
-bool broxton_cdclk_verify_state(struct drm_i915_private *dev_priv);
void broxton_ddi_phy_init(struct drm_i915_private *dev_priv);
void broxton_ddi_phy_uninit(struct drm_i915_private *dev_priv);
void broxton_ddi_phy_verify_state(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6817a3cb5fbc..b70e123f67ca 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -811,10 +811,11 @@ static void gen9_dc_off_power_well_enable(struct
drm_i915_private *dev_priv,
{
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
- if (IS_BROXTON(dev_priv)) {
- broxton_cdclk_verify_state(dev_priv);
+ WARN_ON(dev_priv->cdclk_freq !=
+ dev_priv->display.get_display_clock_speed(dev_priv->dev));
+
+ if (IS_BROXTON(dev_priv))
broxton_ddi_phy_verify_state(dev_priv);
- }
}
static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
@@ -2288,7 +2289,6 @@ void bxt_display_core_init(struct drm_i915_private
*dev_priv,
broxton_ddi_phy_init(dev_priv);
- broxton_cdclk_verify_state(dev_priv);
broxton_ddi_phy_verify_state(dev_priv);
if (resume && dev_priv->csr.dmc_payload)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/21] drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit
From: Ville Syrjälä
SKL and BXT have the same snippets of code for enabling disabling the
DBUF. Extract those into helpers and move the calls from
init/unit_cdclk() to the display core init/init since this stuff isn't
really about cdclk. Also doing the enable twice shouldn't hurt since
you're just setting the request bit again when it was already set.
We can also toss in a few WARNs about the register values into
skl_get_dpll0_vco() now that we know that things should always be
sane there.
Flatten skl_init_cdclk() while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c| 58 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 32 ++
2 files changed, 38 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index da903b718c11..e908f360da74 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5480,18 +5480,6 @@ static bool broxton_cdclk_is_enabled(struct
drm_i915_private *dev_priv)
/* TODO: Check for a valid CDCLK rate */
- if (!(I915_READ(DBUF_CTL) & DBUF_POWER_REQUEST)) {
- DRM_DEBUG_DRIVER("CDCLK enabled, but DBUF power not
requested\n");
-
- return false;
- }
-
- if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE)) {
- DRM_DEBUG_DRIVER("CDCLK enabled, but DBUF power hasn't
settled\n");
-
- return false;
- }
-
return true;
}
@@ -5518,26 +5506,10 @@ void broxton_init_cdclk(struct drm_i915_private
*dev_priv)
* here, it belongs to modeset time
*/
broxton_set_cdclk(dev_priv, 624000);
-
- I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
- POSTING_READ(DBUF_CTL);
-
- udelay(10);
-
- if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE))
- DRM_ERROR("DBuf power enable timeout!\n");
}
void broxton_uninit_cdclk(struct drm_i915_private *dev_priv)
{
- I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) & ~DBUF_POWER_REQUEST);
- POSTING_READ(DBUF_CTL);
-
- udelay(10);
-
- if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
- DRM_ERROR("DBuf power disable timeout!\n");
-
/* Set minimum (bypass) frequency, in effect turning off the DE PLL */
broxton_set_cdclk(dev_priv, 19200);
}
@@ -5759,15 +5731,6 @@ static void skl_sanitize_cdclk(struct drm_i915_private
*dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
{
- /* disable DBUF power */
- I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) & ~DBUF_POWER_REQUEST);
- POSTING_READ(DBUF_CTL);
-
- udelay(10);
-
- if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
- DRM_ERROR("DBuf power disable timeout\n");
-
skl_set_cdclk(dev_priv, 24000, 0);
}
@@ -5785,24 +5748,15 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
if (dev_priv->skl_preferred_vco_freq == 0)
skl_set_preferred_cdclk_vco(dev_priv,
dev_priv->skl_vco_freq);
- } else {
- /* set CDCLK to the lowest frequency, Modeset follows */
- vco = dev_priv->skl_preferred_vco_freq;
- if (vco == 0)
- vco = 8100;
- cdclk = skl_calc_cdclk(0, vco);
-
- skl_set_cdclk(dev_priv, cdclk, vco);
+ return;
}
- /* enable DBUF power */
- I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
- POSTING_READ(DBUF_CTL);
-
- udelay(10);
+ vco = dev_priv->skl_preferred_vco_freq;
+ if (vco == 0)
+ vco = 8100;
+ cdclk = skl_calc_cdclk(0, vco);
- if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE))
- DRM_ERROR("DBuf power enable timeout\n");
+ skl_set_cdclk(dev_priv, cdclk, vco);
}
static void skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index fefe22c3c163..6817a3cb5fbc 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2176,6 +2176,28 @@ static void intel_power_domains_sync_hw(struct
drm_i915_private *dev_priv)
mutex_unlock(&power_domains->lock);
}
+static void skl_dbuf_enable(struct drm_i915_private *dev_priv)
+{
+ I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
+ POSTING_READ(DBUF_CTL);
+
+ udelay(10);
+
+ if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE))
+ DRM_ERROR("DBuf power enable timeout\n");
+}
+
+static void skl_dbuf_disable(struct drm_i915_private *dev_priv)
+{
+ I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) & ~DBUF_POWER_REQUEST);
+ POSTING_READ(DBUF_CTL);
+
+ udelay(10);
+
+ if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
+ DRM_ERRO
[Intel-gfx] [PATCH 15/21] drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk()
From: Ville Syrjälä
Enabling and disalbing the DE PLL are two nice self contained
operations, so let's move them into a few small helper functions.
Makes it easier to see the forest from the trees in broxton_set_cdclk().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 41
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 11e90863533b..76d59d1214f4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5358,6 +5358,31 @@ static int skl_cdclk_decimal(int cdclk)
return DIV_ROUND_CLOSEST(cdclk - 1000, 500);
}
+static void bxt_de_pll_disable(struct drm_i915_private *dev_priv)
+{
+ I915_WRITE(BXT_DE_PLL_ENABLE, 0);
+
+ /* Timeout 200us */
+ if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) == 0, 1))
+ DRM_ERROR("timeout waiting for DE PLL unlock\n");
+}
+
+static void bxt_de_pll_enable(struct drm_i915_private *dev_priv, u32 ratio)
+{
+ u32 val;
+
+ val = I915_READ(BXT_DE_PLL_CTL);
+ val &= ~BXT_DE_PLL_RATIO_MASK;
+ val |= ratio;
+ I915_WRITE(BXT_DE_PLL_CTL, val);
+
+ I915_WRITE(BXT_DE_PLL_ENABLE, BXT_DE_PLL_PLL_ENABLE);
+
+ /* Timeout 200us */
+ if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) != 0, 1))
+ DRM_ERROR("timeout waiting for DE PLL lock\n");
+}
+
static void broxton_set_cdclk(struct drm_i915_private *dev_priv, int cdclk)
{
uint32_t divider;
@@ -5425,25 +5450,13 @@ static void broxton_set_cdclk(struct drm_i915_private
*dev_priv, int cdclk)
*/
if (cdclk == 19200 || cdclk == 624000 ||
current_cdclk == 624000) {
- I915_WRITE(BXT_DE_PLL_ENABLE, ~BXT_DE_PLL_PLL_ENABLE);
- /* Timeout 200us */
- if (wait_for(!(I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK),
-1))
- DRM_ERROR("timout waiting for DE PLL unlock\n");
+ bxt_de_pll_disable(dev_priv);
}
if (cdclk != 19200) {
uint32_t val;
- val = I915_READ(BXT_DE_PLL_CTL);
- val &= ~BXT_DE_PLL_RATIO_MASK;
- val |= ratio;
- I915_WRITE(BXT_DE_PLL_CTL, val);
-
- I915_WRITE(BXT_DE_PLL_ENABLE, BXT_DE_PLL_PLL_ENABLE);
- /* Timeout 200us */
- if (wait_for(I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK, 1))
- DRM_ERROR("timeout waiting for DE PLL lock\n");
+ bxt_de_pll_enable(dev_priv, ratio);
val = divider | skl_cdclk_decimal(cdclk);
/*
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/21] drm/i915: Store cdclk PLL reference clock under dev_priv
From: Ville Syrjälä
Future platforms will have multiple options for the cdclk PLL reference
clock, so let's start tracking that under dev_priv alreday on SKL,
although on SKL it's always 24 MHz.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 14 --
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8da787cd2227..422f219450c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1828,7 +1828,7 @@ struct drm_i915_private {
unsigned int czclk_freq;
struct {
- unsigned int vco;
+ unsigned int vco, ref;
} cdclk_pll;
/**
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8bde3ae34869..11e90863533b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5335,8 +5335,9 @@ static void intel_update_cdclk(struct drm_device *dev)
dev_priv->cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
- DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz, VCO: %d kHz\n",
-dev_priv->cdclk_freq, dev_priv->cdclk_pll.vco);
+ DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz, VCO: %d kHz,
ref: %d kHz\n",
+dev_priv->cdclk_freq, dev_priv->cdclk_pll.vco,
+dev_priv->cdclk_pll.ref);
else
DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz\n",
dev_priv->cdclk_freq);
@@ -5542,6 +5543,8 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
{
u32 val;
+ dev_priv->cdclk_pll.ref = 24000;
+
val = I915_READ(LCPLL1_CTL);
if ((val & LCPLL_PLL_ENABLE) == 0) {
dev_priv->cdclk_pll.vco = 0;
@@ -5730,7 +5733,7 @@ static void skl_sanitize_cdclk(struct drm_i915_private
*dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
{
- skl_set_cdclk(dev_priv, 24000, 0);
+ skl_set_cdclk(dev_priv, dev_priv->cdclk_pll.ref, 0);
}
void skl_init_cdclk(struct drm_i915_private *dev_priv)
@@ -6646,7 +6649,7 @@ static int skylake_get_display_clock_speed(struct
drm_device *dev)
skl_dpll0_update(dev_priv);
if (dev_priv->cdclk_pll.vco == 0)
- return 24000; /* 24MHz is the cd freq with NSSC ref */
+ return dev_priv->cdclk_pll.ref;
cdctl = I915_READ(CDCLK_CTL);
@@ -6678,8 +6681,7 @@ static int skylake_get_display_clock_speed(struct
drm_device *dev)
}
}
- /* error case, do as if DPLL0 isn't enabled */
- return 24000;
+ return dev_priv->cdclk_pll.ref;
}
static int broxton_get_display_clock_speed(struct drm_device *dev)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/21] drm/i915: Make 308 and 671 MHz cdclks more accurate on SKL
From: Ville Syrjälä
The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz.
Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz.
Let's use the slightly more accurate numbers. Potentially we might
change to computing all of these based on dividers, but let's
stick to the current theme for now..
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e908f360da74..c0dbff37e2c3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5284,13 +5284,13 @@ static void intel_update_max_cdclk(struct drm_device
*dev)
* if the preferred vco is 8100 instead.
*/
if (limit == SKL_DFSM_CDCLK_LIMIT_675)
- max_cdclk = 617140;
+ max_cdclk = 617143;
else if (limit == SKL_DFSM_CDCLK_LIMIT_540)
max_cdclk = 54;
else if (limit == SKL_DFSM_CDCLK_LIMIT_450)
max_cdclk = 432000;
else
- max_cdclk = 308570;
+ max_cdclk = 308571;
dev_priv->max_cdclk_freq = skl_calc_cdclk(max_cdclk, vco);
} else if (IS_BROXTON(dev)) {
@@ -5518,13 +5518,13 @@ static int skl_calc_cdclk(int max_pixclk, int vco)
{
if (vco == 8640) {
if (max_pixclk > 54)
- return 617140;
+ return 617143;
else if (max_pixclk > 432000)
return 54;
- else if (max_pixclk > 308570)
+ else if (max_pixclk > 308571)
return 432000;
else
- return 308570;
+ return 308571;
} else {
/* VCO 8100 */
if (max_pixclk > 54)
@@ -5696,13 +5696,13 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv, int cdclk, int vco)
freq_select = CDCLK_FREQ_540;
pcu_ack = 2;
break;
- case 308570:
+ case 308571:
case 337500:
default:
freq_select = CDCLK_FREQ_337_308;
pcu_ack = 0;
break;
- case 617140:
+ case 617143:
case 675000:
freq_select = CDCLK_FREQ_675_617;
pcu_ack = 3;
@@ -6656,11 +6656,11 @@ static int skylake_get_display_clock_speed(struct
drm_device *dev)
case CDCLK_FREQ_450_432:
return 432000;
case CDCLK_FREQ_337_308:
- return 308570;
+ return 308571;
case CDCLK_FREQ_540:
return 54;
case CDCLK_FREQ_675_617:
- return 617140;
+ return 617143;
default:
MISSING_CASE(cdctl & CDCLK_FREQ_SEL_MASK);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/21] drm/i915: Rename skl_vco_freq to cdclk_pll.vco
From: Ville Syrjälä
We'll want to store the cdclk PLL (whatever PLL that is in reality) vco
frequency somewhere on other platforms too, so let's rename the
skl_vco_freq to cdclk_pll.vco, and let's store it in kHz instead of MHz
to match most of the other clocks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 5 +++-
drivers/gpu/drm/i915/intel_display.c | 51 ++--
drivers/gpu/drm/i915/intel_dp.c | 4 +--
3 files changed, 31 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 46a22732088e..8da787cd2227 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1820,7 +1820,6 @@ struct drm_i915_private {
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
unsigned int fsb_freq, mem_freq, is_ddr3;
- unsigned int skl_vco_freq;
unsigned int skl_preferred_vco_freq;
unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
unsigned int max_dotclk_freq;
@@ -1828,6 +1827,10 @@ struct drm_i915_private {
unsigned int hpll_freq;
unsigned int czclk_freq;
+ struct {
+ unsigned int vco;
+ } cdclk_pll;
+
/**
* wq - Driver workqueue for GEM.
*
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c0dbff37e2c3..8bde3ae34869 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5276,7 +5276,7 @@ static void intel_update_max_cdclk(struct drm_device *dev)
int max_cdclk, vco;
vco = dev_priv->skl_preferred_vco_freq;
- WARN_ON(vco != 8100 && vco != 8640);
+ WARN_ON(vco != 810 && vco != 864);
/*
* Use the lower (vco 8640) cdclk values as a
@@ -5335,8 +5335,8 @@ static void intel_update_cdclk(struct drm_device *dev)
dev_priv->cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
- DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz, VCO: %d MHz\n",
-dev_priv->cdclk_freq, dev_priv->skl_vco_freq);
+ DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz, VCO: %d kHz\n",
+dev_priv->cdclk_freq, dev_priv->cdclk_pll.vco);
else
DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz\n",
dev_priv->cdclk_freq);
@@ -5516,7 +5516,7 @@ void broxton_uninit_cdclk(struct drm_i915_private
*dev_priv)
static int skl_calc_cdclk(int max_pixclk, int vco)
{
- if (vco == 8640) {
+ if (vco == 864) {
if (max_pixclk > 54)
return 617143;
else if (max_pixclk > 432000)
@@ -5526,7 +5526,6 @@ static int skl_calc_cdclk(int max_pixclk, int vco)
else
return 308571;
} else {
- /* VCO 8100 */
if (max_pixclk > 54)
return 675000;
else if (max_pixclk > 45)
@@ -5545,7 +5544,7 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
val = I915_READ(LCPLL1_CTL);
if ((val & LCPLL_PLL_ENABLE) == 0) {
- dev_priv->skl_vco_freq = 0;
+ dev_priv->cdclk_pll.vco = 0;
return;
}
@@ -5563,15 +5562,15 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1350, SKL_DPLL0):
case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1620, SKL_DPLL0):
case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2700, SKL_DPLL0):
- dev_priv->skl_vco_freq = 8100;
+ dev_priv->cdclk_pll.vco = 810;
break;
case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1080, SKL_DPLL0):
case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2160, SKL_DPLL0):
- dev_priv->skl_vco_freq = 8640;
+ dev_priv->cdclk_pll.vco = 864;
break;
default:
MISSING_CASE(val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0));
- dev_priv->skl_vco_freq = 0;
+ dev_priv->cdclk_pll.vco = 0;
break;
}
}
@@ -5592,7 +5591,7 @@ skl_dpll0_enable(struct drm_i915_private *dev_priv, int
vco)
int min_cdclk = skl_calc_cdclk(0, vco);
u32 val;
- WARN_ON(vco != 8100 && vco != 8640);
+ WARN_ON(vco != 810 && vco != 864);
/* select the minimum CDCLK before enabling DPLL 0 */
val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
@@ -5613,7 +5612,7 @@ skl_dpll0_enable(struct drm_i915_private *dev_priv, int
vco)
val &= ~(DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) | DPLL_CTRL1_SSC(SKL_DPLL0) |
DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0));
[Intel-gfx] [PATCH 07/21] drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL
From: Ville Syrjälä
In case we originally guessed wrong which lcpll vco frequency to use,
we will need to shut down the pll and restart it when reprogamming the
cdclk.
This also allows us to track the actual vco frequency in dev_priv
instead of just a guess.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 54 +++-
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 95997eed9dd6..cd2809179042 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5626,6 +5626,8 @@ skl_dpll0_enable(struct drm_i915_private *dev_priv, int
vco)
if (wait_for(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK, 5))
DRM_ERROR("DPLL0 not locked\n");
+
+ dev_priv->skl_vco_freq = vco;
}
static void
@@ -5634,6 +5636,8 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) & ~LCPLL_PLL_ENABLE);
if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
DRM_ERROR("Couldn't disable DPLL0\n");
+
+ dev_priv->skl_vco_freq = 0;
}
static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
@@ -5663,12 +5667,14 @@ static bool skl_cdclk_wait_for_pcu_ready(struct
drm_i915_private *dev_priv)
return false;
}
-static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk)
+static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk, int
vco)
{
struct drm_device *dev = dev_priv->dev;
u32 freq_select, pcu_ack;
- DRM_DEBUG_DRIVER("Changing CDCLK to %dKHz\n", cdclk);
+ WARN_ON((cdclk == 24000) != (vco == 0));
+
+ DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d MHz)\n", cdclk, vco);
if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
DRM_ERROR("failed to inform PCU about cdclk change\n");
@@ -5699,6 +5705,13 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv, int cdclk)
break;
}
+ if (dev_priv->skl_vco_freq != 0 &&
+ dev_priv->skl_vco_freq != vco)
+ skl_dpll0_disable(dev_priv);
+
+ if (dev_priv->skl_vco_freq != vco)
+ skl_dpll0_enable(dev_priv, vco);
+
I915_WRITE(CDCLK_CTL, freq_select | skl_cdclk_decimal(cdclk));
POSTING_READ(CDCLK_CTL);
@@ -5721,26 +5734,21 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
DRM_ERROR("DBuf power disable timeout\n");
- skl_dpll0_disable(dev_priv);
+ skl_set_cdclk(dev_priv, 24000, 0);
}
void skl_init_cdclk(struct drm_i915_private *dev_priv)
{
- unsigned int cdclk;
-
/* DPLL0 not enabled (happens on early BIOS versions) */
- if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
- /* enable DPLL0 */
- if (dev_priv->skl_vco_freq != 8640)
- dev_priv->skl_vco_freq = 8100;
- skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
- cdclk = skl_calc_cdclk(0, dev_priv->skl_vco_freq);
- } else {
- cdclk = dev_priv->cdclk_freq;
- }
+ if (dev_priv->skl_vco_freq == 0) {
+ int cdclk, vco;
- /* set CDCLK to the lowest frequency, Modeset follows */
- skl_set_cdclk(dev_priv, cdclk);
+ /* set CDCLK to the lowest frequency, Modeset follows */
+ vco = 8100;
+ cdclk = skl_calc_cdclk(0, vco);
+
+ skl_set_cdclk(dev_priv, cdclk, vco);
+ }
/* enable DBUF power */
I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
@@ -9777,16 +9785,12 @@ static int skl_modeset_calc_cdclk(struct
drm_atomic_state *state)
static void skl_modeset_commit_cdclk(struct drm_atomic_state *old_state)
{
- struct drm_device *dev = old_state->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- unsigned int req_cdclk = to_intel_atomic_state(old_state)->dev_cdclk;
-
- /*
-* FIXME disable/enable PLL should wrap set_cdclk()
-*/
- skl_set_cdclk(dev_priv, req_cdclk);
+ struct drm_i915_private *dev_priv = to_i915(old_state->dev);
+ struct intel_atomic_state *intel_state =
to_intel_atomic_state(old_state);
+ unsigned int req_cdclk = intel_state->dev_cdclk;
+ unsigned int req_vco = intel_state->cdclk_pll_vco;
- dev_priv->skl_vco_freq =
to_intel_atomic_state(old_state)->cdclk_pll_vco;
+ skl_set_cdclk(dev_priv, req_cdclk, req_vco);
}
static int haswell_crtc_compute_clock(struct intel_crtc *crtc,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/21] drm/i915: Keep track of preferred cdclk vco frequency on SKL
From: Ville Syrjälä
Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need
something that keeps track of which vco frequency we want to use in case
the current vco is 0. This would be important across supend/resume since
we'll disable DPLL0 around those parts.
We'll also update our idea of max cdclk/dotclock when the preferred
vco changes. That could happen if out initial guess was wrong, and
later eDP would force us to change it. One issue here could be that
changing the max dotclock could cause our mode list to change during
next time the displays get probed. But I don't see a good way to avoid
that, except perhaps by allowing either vco frequency to be used as
needed. But the docs suggest that such usage wasn't really inteded.
Also need to make sure we don't update our max_cdclk value before we
have a preferred vco value, which means moving that to happen after
the cdclk sanitation.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 48 +--
drivers/gpu/drm/i915/intel_dpll_mgr.c | 5
drivers/gpu/drm/i915/intel_drv.h | 1 +
4 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b319da970c8a..46a22732088e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1821,6 +1821,7 @@ struct drm_i915_private {
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_vco_freq;
+ unsigned int skl_preferred_vco_freq;
unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
unsigned int max_dotclk_freq;
unsigned int rawclk_freq;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cd2809179042..107a7799bdde 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5265,21 +5265,34 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
return max_cdclk_freq*90/100;
}
+static int skl_calc_cdclk(int max_pixclk, int vco);
+
static void intel_update_max_cdclk(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) {
u32 limit = I915_READ(SKL_DFSM) & SKL_DFSM_CDCLK_LIMIT_MASK;
+ int max_cdclk, vco;
+
+ vco = dev_priv->skl_preferred_vco_freq;
+ WARN_ON(vco != 8100 && vco != 8640);
+ /*
+* Use the lower (vco 8640) cdclk values as a
+* first guess. skl_calc_cdclk() will correct it
+* if the preferred vco is 8100 instead.
+*/
if (limit == SKL_DFSM_CDCLK_LIMIT_675)
- dev_priv->max_cdclk_freq = 675000;
+ max_cdclk = 617140;
else if (limit == SKL_DFSM_CDCLK_LIMIT_540)
- dev_priv->max_cdclk_freq = 54;
+ max_cdclk = 54;
else if (limit == SKL_DFSM_CDCLK_LIMIT_450)
- dev_priv->max_cdclk_freq = 45;
+ max_cdclk = 432000;
else
- dev_priv->max_cdclk_freq = 337500;
+ max_cdclk = 308570;
+
+ dev_priv->max_cdclk_freq = skl_calc_cdclk(max_cdclk, vco);
} else if (IS_BROXTON(dev)) {
dev_priv->max_cdclk_freq = 624000;
} else if (IS_BROADWELL(dev)) {
@@ -5336,9 +5349,6 @@ static void intel_update_cdclk(struct drm_device *dev)
*/
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq,
1000));
-
- if (dev_priv->max_cdclk_freq == 0)
- intel_update_max_cdclk(dev);
}
/* convert from kHz to .1 fixpoint MHz with -1MHz offset */
@@ -5587,12 +5597,24 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
}
}
+void skl_set_preferred_cdclk_vco(struct drm_i915_private *dev_priv, int vco)
+{
+ bool changed = dev_priv->skl_preferred_vco_freq != vco;
+
+ dev_priv->skl_preferred_vco_freq = vco;
+
+ if (changed)
+ intel_update_max_cdclk(dev_priv->dev);
+}
+
static void
skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
{
int min_cdclk = skl_calc_cdclk(0, vco);
u32 val;
+ WARN_ON(vco != 8100 && vco != 8640);
+
/* select the minimum CDCLK before enabling DPLL 0 */
val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
I915_WRITE(CDCLK_CTL, val);
@@ -5628,6 +5650,9 @@ skl_dpll0_enable(struct drm_i915_private *dev_priv, int
vco)
DRM_ERROR("DPLL0 not locked\n");
dev_priv->skl_vco_freq = vco;
+
+ /* We'll want to keep using the current vco from now on. */
+ skl_set_preferred_cdclk_vc
[Intel-gfx] [PATCH 09/21] drm/i915: Beef up skl_sanitize_cdclk() a bit
From: Ville Syrjälä
Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw
out a few unneeded variables, and write the CDCLK_CTL check a bit more
legible way.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 107a7799bdde..493160682b2a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5789,9 +5789,7 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
{
- uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
- uint32_t cdctl = I915_READ(CDCLK_CTL);
- int freq = dev_priv->cdclk_freq;
+ uint32_t cdctl, expected;
/*
* check if the pre-os intialized the display
@@ -5802,7 +5800,14 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
goto sanitize;
/* Is PLL enabled and locked ? */
- if (!((lcpll1 & LCPLL_PLL_ENABLE) && (lcpll1 & LCPLL_PLL_LOCK)))
+ if ((I915_READ(LCPLL1_CTL) & (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK)) !=
+ (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK))
+ goto sanitize;
+
+ if ((I915_READ(DPLL_CTRL1) & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
+ DPLL_CTRL1_SSC(SKL_DPLL0) |
+ DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
+ DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
goto sanitize;
/* DPLL okay; verify the cdclock
@@ -5811,7 +5816,10 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
* decimal part is programmed wrong from BIOS where pre-os does not
* enable display. Verify the same as well.
*/
- if (cdctl == ((cdctl & CDCLK_FREQ_SEL_MASK) | skl_cdclk_decimal(freq)))
+ cdctl = I915_READ(CDCLK_CTL);
+ expected = (cdctl & CDCLK_FREQ_SEL_MASK) |
+ skl_cdclk_decimal(dev_priv->cdclk_freq);
+ if (cdctl == expected)
/* All well; nothing to sanitize */
return false;
sanitize:
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/21] drm/i915: Unify SKL cdclk init paths
From: Ville Syrjälä
Currently we initialize cdclk on SKL from two different places,
depending on whether it's during driver init or resume. Let's
unify it to happen from the same place always, and that place will be
the display core init function.
To do this we first run through the cdclk sanitation code, which will
first verify that the PLL is programmed correctly, after which we can
read out the current cdclk frequency, and once the cdclk is known we
verify that the cdclk "decimal" frequency is programmed correctly. If
any of these fail we will force a cdclk change, and to be safe we also
force the PLL to be turned off and on again. If the sanitation step
didn't notice anything amiss, we'll skip the cdclk programming which
will prevent cdclk reprogramming when the displays might be active.
We can also toss in a few WARNs about the register values into
skl_update_dpll0() since we now know that the PLL state should
always be sane when that function is called.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c| 40 +
drivers/gpu/drm/i915/intel_dpll_mgr.c | 11 ++---
drivers/gpu/drm/i915/intel_drv.h| 1 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
4 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 493160682b2a..da903b718c11 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5577,8 +5577,15 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
return;
}
+ WARN_ON((val & LCPLL_PLL_LOCK) == 0);
+
val = I915_READ(DPLL_CTRL1);
+ WARN_ON((val & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
+ DPLL_CTRL1_SSC(SKL_DPLL0) |
+ DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
+ DPLL_CTRL1_OVERRIDE(SKL_DPLL0));
+
switch (val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0)) {
case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, SKL_DPLL0):
case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1350, SKL_DPLL0):
@@ -5748,6 +5755,8 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv, int cdclk, int vco)
intel_update_cdclk(dev);
}
+static void skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
+
void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
{
/* disable DBUF power */
@@ -5764,10 +5773,19 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
void skl_init_cdclk(struct drm_i915_private *dev_priv)
{
- /* DPLL0 not enabled (happens on early BIOS versions) */
- if (dev_priv->skl_vco_freq == 0) {
- int cdclk, vco;
+ int cdclk, vco;
+
+ skl_sanitize_cdclk(dev_priv);
+ if (dev_priv->cdclk_freq != 0 && dev_priv->skl_vco_freq != 0) {
+ /*
+* Use the current vco as out initial
+* guess as to what the preferred vco is.
+*/
+ if (dev_priv->skl_preferred_vco_freq == 0)
+ skl_set_preferred_cdclk_vco(dev_priv,
+ dev_priv->skl_vco_freq);
+ } else {
/* set CDCLK to the lowest frequency, Modeset follows */
vco = dev_priv->skl_preferred_vco_freq;
if (vco == 0)
@@ -5787,7 +5805,7 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
DRM_ERROR("DBuf power enable timeout\n");
}
-int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
+static void skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
{
uint32_t cdctl, expected;
@@ -5810,6 +5828,8 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
goto sanitize;
+ intel_update_cdclk(dev_priv->dev);
+
/* DPLL okay; verify the cdclock
*
* Noticed in some instances that the freq selection is correct but
@@ -5821,13 +5841,15 @@ int skl_sanitize_cdclk(struct drm_i915_private
*dev_priv)
skl_cdclk_decimal(dev_priv->cdclk_freq);
if (cdctl == expected)
/* All well; nothing to sanitize */
- return false;
-sanitize:
+ return;
- skl_init_cdclk(dev_priv);
+sanitize:
+ DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
- /* we did have to sanitize */
- return true;
+ /* force cdclk programming */
+ dev_priv->cdclk_freq = 0;
+ /* force full PLL disable + enable */
+ dev_priv->skl_vco_freq = -1;
}
/* Adjust CDclk dividers to allow high res or save power if possible */
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 34ec149fde85..6b70e1eccb13 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1630,17 +1630,10 @@ static const struct intel_shar
[Intel-gfx] [PATCH 04/21] drm/i915: Extract skl_calc_cdclk()
From: Ville Syrjälä
We have many places where we want to pick a suitable cdclk frequency for
skl based on the dotclock and lcpll vco. Split that code into a small
helper and call it from all over.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 63 +---
1 file changed, 30 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 41fe18c4b761..c1b1632664a1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5527,6 +5527,30 @@ void broxton_uninit_cdclk(struct drm_i915_private
*dev_priv)
broxton_set_cdclk(dev_priv, 19200);
}
+static int skl_calc_cdclk(int max_pixclk, int vco)
+{
+ if (vco == 8640) {
+ if (max_pixclk > 54)
+ return 617140;
+ else if (max_pixclk > 432000)
+ return 54;
+ else if (max_pixclk > 308570)
+ return 432000;
+ else
+ return 308570;
+ } else {
+ /* VCO 8100 */
+ if (max_pixclk > 54)
+ return 675000;
+ else if (max_pixclk > 45)
+ return 54;
+ else if (max_pixclk > 337500)
+ return 45;
+ else
+ return 337500;
+ }
+}
+
static const struct skl_cdclk_entry {
unsigned int freq;
unsigned int vco;
@@ -5557,15 +5581,10 @@ unsigned int skl_cdclk_get_vco(unsigned int freq)
static void
skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
{
- int min_cdclk;
+ int min_cdclk = skl_calc_cdclk(0, vco);
u32 val;
/* select the minimum CDCLK before enabling DPLL 0 */
- if (vco == 8640)
- min_cdclk = 308570;
- else
- min_cdclk = 337500;
-
val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
I915_WRITE(CDCLK_CTL, val);
POSTING_READ(CDCLK_CTL);
@@ -5577,7 +5596,7 @@ skl_dpll0_enable(struct drm_i915_private *dev_priv, int
vco)
* 8100 while the eDP 1.4 alternate link rates need a VCO of 8640.
* The modeset code is responsible for the selection of the exact link
* rate later on, with the constraint of choosing a frequency that
-* works with required_vco.
+* works with vco.
*/
val = I915_READ(DPLL_CTRL1);
@@ -5706,7 +5725,7 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
if (dev_priv->skl_vco_freq != 8640)
dev_priv->skl_vco_freq = 8100;
skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
- cdclk = ((dev_priv->skl_vco_freq == 8100) ? 337500 : 308570);
+ cdclk = skl_calc_cdclk(0, dev_priv->skl_vco_freq);
} else {
cdclk = dev_priv->cdclk_freq;
}
@@ -9724,34 +9743,14 @@ static int skl_modeset_calc_cdclk(struct
drm_atomic_state *state)
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_i915_private *dev_priv = to_i915(state->dev);
const int max_pixclk = ilk_max_pixel_rate(state);
+ int vco = intel_state->cdclk_pll_vco;
int cdclk;
/*
* FIXME should also account for plane ratio
* once 64bpp pixel formats are supported.
*/
-
- if (intel_state->cdclk_pll_vco == 8640) {
- /* vco 8640 */
- if (max_pixclk > 54)
- cdclk = 617140;
- else if (max_pixclk > 432000)
- cdclk = 54;
- else if (max_pixclk > 308570)
- cdclk = 432000;
- else
- cdclk = 308570;
- } else {
- /* VCO 8100 */
- if (max_pixclk > 54)
- cdclk = 675000;
- else if (max_pixclk > 45)
- cdclk = 54;
- else if (max_pixclk > 337500)
- cdclk = 45;
- else
- cdclk = 337500;
- }
+ cdclk = skl_calc_cdclk(max_pixclk, vco);
/*
* FIXME move the cdclk caclulation to
@@ -9765,9 +9764,7 @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state
*state)
intel_state->cdclk = intel_state->dev_cdclk = cdclk;
if (!intel_state->active_crtcs)
- intel_state->dev_cdclk = ((intel_state->cdclk_pll_vco == 8640) ?
- 308570 : 337500);
-
+ intel_state->dev_cdclk = skl_calc_cdclk(0, vco);
return 0;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/21] drm/i915: Move the SKL DPLL0 VCO computation into intel_dp_compute_config()
From: Ville Syrjälä
Shared plls won't get assigned until the .compute_clocks() hook gets
called, which happens from the crtc .atomic_check hook. That's too late
as the cdclk computation has already happened. So let's move the DPLL0
VCO computation into intel_dp_compute_config() so that it's done when
the cdclk computation happens. Also only do it for eDP since we only
pick DPLL0 for eDP.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 21 +
drivers/gpu/drm/i915/intel_dpll_mgr.c | 4
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 36330026ceff..908c6f0f7feb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1577,6 +1577,27 @@ found:
&pipe_config->dp_m2_n2);
}
+ /*
+* DPLL0 VCO may need to be adjusted to get the correct
+* clock for eDP. This will affect cdclk as well.
+*/
+ if (is_edp(intel_dp) &&
+ (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))) {
+ int vco;
+
+ switch (pipe_config->port_clock / 2) {
+ case 108000:
+ case 216000:
+ vco = 8640;
+ break;
+ default:
+ vco = 8100;
+ break;
+ }
+
+ to_intel_atomic_state(pipe_config->base.state)->cdclk_pll_vco =
vco;
+ }
+
if (!HAS_DDI(dev))
intel_dp_set_clock(encoder, pipe_config);
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index e99e306e8743..43ba60b3662e 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1194,7 +1194,6 @@ skl_get_dpll(struct intel_crtc *crtc, struct
intel_crtc_state *crtc_state,
struct intel_shared_dpll *pll;
uint32_t ctrl1, cfgcr1, cfgcr2;
int clock = crtc_state->port_clock;
- uint32_t vco = 8100;
/*
* See comment in intel_dpll_hw_state to understand why we always use 0
@@ -1239,15 +1238,12 @@ skl_get_dpll(struct intel_crtc *crtc, struct
intel_crtc_state *crtc_state,
break;
case 108000:
ctrl1 |=
DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1080, 0);
- vco = 8640;
break;
case 216000:
ctrl1 |=
DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2160, 0);
- vco = 8640;
break;
}
- to_intel_atomic_state(crtc_state->base.state)->cdclk_pll_vco =
vco;
cfgcr1 = cfgcr2 = 0;
} else {
return NULL;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/21] drm/i915: Fix BXT min_pixclk after state readout
From: Ville Syrjälä
commit 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk
calculation")
tried to change BXT to use ilk_max_pixel_rate() to compute the
pipe pixel rate. I failed to notice that there was another place
in the state readout code that needs the same treatment. So let's
change that one too.
Should probably just change things to always compuyte the pipe pixel
rates, instead of just doing on platforms that can change cdclk
dynamically. But for now let's just move BXT fully over to the
side that uses ilk_pipe_pixel_rate().
Cc: Jani Nikula
Fixes: 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk
calculation")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c5f0a6f30879..cc9a8b42fbc6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15748,18 +15748,16 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
if (crtc_state->base.active) {
dev_priv->active_crtcs |= 1 << crtc->pipe;
- if (IS_BROADWELL(dev_priv)) {
+ if (IS_BROXTON(dev_priv) || IS_BROADWELL(dev_priv))
pixclk = ilk_pipe_pixel_rate(crtc_state);
-
- /* pixel rate mustn't exceed 95% of cdclk with
IPS on BDW */
- if (crtc_state->ips_enabled)
- pixclk = DIV_ROUND_UP(pixclk * 100, 95);
- } else if (IS_VALLEYVIEW(dev_priv) ||
- IS_CHERRYVIEW(dev_priv) ||
- IS_BROXTON(dev_priv))
+ else if (IS_VALLEYVIEW(dev_priv) ||
IS_CHERRYVIEW(dev_priv))
pixclk =
crtc_state->base.adjusted_mode.crtc_clock;
else
WARN_ON(dev_priv->display.modeset_calc_cdclk);
+
+ /* pixel rate mustn't exceed 95% of cdclk with IPS on
BDW */
+ if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
+ pixclk = DIV_ROUND_UP(pixclk * 100, 95);
}
dev_priv->min_pixclk[crtc->pipe] = pixclk;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/21] drm/i915/skl: SKL CDCLK change on modeset tracking VCO
From: Clint Taylor
WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected
to DDI1 the system will hard hang during a cold boot. Occurs when DDI1
is enabled when the cdclk is less then required. DP connected to DDI2
and HPD on either port works correctly.
Set cdclk based on the max required pixel clock based on VCO
selected. Track boot vco instead of boot cdclk.
The vco is now tracked at the atomic level and all CRTCs updated if
the required vco is changed. Not tested with eDP v1.4 panels that
require 8640 vco due to availability.
V1: initial version
V2: add vco tracking in intel_dp_compute_config(), rename
skl_boot_cdclk.
V3: rebase, V2 feedback not possible as encoders are not aware of
atomic.
V4: track target vco is atomic state. modeset all CRTCs if vco changes
V5: rename atomic variable, cleaner if/else logic, use existing vco if
encoder does not return a new vco value. check_patch.pl cleanup
V6: simplify logic in intel_modeset_checks.
V7: reorder an IF for readability and whitespace fix.
V8: use dev_cdclk for tracking new cdclk during atomic
V9: correctly handle vco 8640 when crtcs==0
V10: Clean up if else in crtcs==0
V11: Rebase for new intel_dpll_mgr.c
Reviewed-by: Ville Syrjälä
Signed-off-by: Clint Taylor
[vsyrjala: rebased due to churn]
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 109 +-
drivers/gpu/drm/i915/intel_dpll_mgr.c | 9 +--
drivers/gpu/drm/i915/intel_drv.h | 4 ++
4 files changed, 104 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ba614193cc9..b319da970c8a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1820,7 +1820,7 @@ struct drm_i915_private {
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
unsigned int fsb_freq, mem_freq, is_ddr3;
- unsigned int skl_boot_cdclk;
+ unsigned int skl_vco_freq;
unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
unsigned int max_dotclk_freq;
unsigned int rawclk_freq;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cc9a8b42fbc6..41fe18c4b761 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5540,7 +5540,7 @@ static const struct skl_cdclk_entry {
{ .freq = 675000, .vco = 8100 },
};
-static unsigned int skl_cdclk_get_vco(unsigned int freq)
+unsigned int skl_cdclk_get_vco(unsigned int freq)
{
unsigned int i;
@@ -5698,17 +5698,21 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
void skl_init_cdclk(struct drm_i915_private *dev_priv)
{
- unsigned int vco;
+ unsigned int cdclk;
/* DPLL0 not enabled (happens on early BIOS versions) */
if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
/* enable DPLL0 */
- vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
- skl_dpll0_enable(dev_priv, vco);
+ if (dev_priv->skl_vco_freq != 8640)
+ dev_priv->skl_vco_freq = 8100;
+ skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
+ cdclk = ((dev_priv->skl_vco_freq == 8100) ? 337500 : 308570);
+ } else {
+ cdclk = dev_priv->cdclk_freq;
}
- /* set CDCLK to the frequency the BIOS chose */
- skl_set_cdclk(dev_priv, dev_priv->skl_boot_cdclk);
+ /* set CDCLK to the lowest frequency, Modeset follows */
+ skl_set_cdclk(dev_priv, cdclk);
/* enable DBUF power */
I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
@@ -5724,7 +5728,7 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
{
uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
uint32_t cdctl = I915_READ(CDCLK_CTL);
- int freq = dev_priv->skl_boot_cdclk;
+ int freq = dev_priv->cdclk_freq;
/*
* check if the pre-os intialized the display
@@ -5748,11 +5752,7 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
/* All well; nothing to sanitize */
return false;
sanitize:
- /*
-* As of now initialize with max cdclk till
-* we get dynamic cdclk support
-* */
- dev_priv->skl_boot_cdclk = dev_priv->max_cdclk_freq;
+
skl_init_cdclk(dev_priv);
/* we did have to sanitize */
@@ -9719,6 +9719,73 @@ static void broadwell_modeset_commit_cdclk(struct
drm_atomic_state *old_state)
broadwell_set_cdclk(dev, req_cdclk);
}
+static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
+{
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_i915_private *dev_priv = to_i915(state->dev);
+ const int max_pixclk = ilk_max_pixel_rate(state);
+ int cdclk;
+
+ /*
+* FI
[Intel-gfx] [PATCH 00/21] drm/i915: SKL/KBL/BXT cdclk stuff
From: Ville Syrjälä Here's my second installment of SKL+ cdclk stuff. I've picked up Clint's latest SKL/KBL cdclk patch and expanded on it quite a bit. After this series we're capable of actually changing the DPLL0 VCO frequency dynamically, and a lot of the code gets a much more uniform feel to it between SKL/KBL vs. BXT. This should make it possible to land some future hardware work on top as well, without making the code an awful mess. Series available here: git://github.com/vsyrjala/linux.git skl_bxt_cdclk_part_2 Clint Taylor (1): drm/i915/skl: SKL CDCLK change on modeset tracking VCO Ville Syrjälä (20): drm/i915: Fix BXT min_pixclk after state readout drm/i915: Move the SKL DPLL0 VCO computation into intel_dp_compute_config() drm/i915: Extract skl_calc_cdclk() drm/i915: Actually read out DPLL0 vco on skl from hardware drm/i915: Report the current DPLL0 vco on SKL/KBL drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL drm/i915: Keep track of preferred cdclk vco frequency on SKL drm/i915: Beef up skl_sanitize_cdclk() a bit drm/i915: Unify SKL cdclk init paths drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit drm/i915: Make 308 and 671 MHz cdclks more accurate on SKL drm/i915: Rename skl_vco_freq to cdclk_pll.vco drm/i915: Store cdclk PLL reference clock under dev_priv drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk() drm/i915: Store BXT DE PLL vco and ref clocks in dev_priv drm/i915: Update cached cdclk state from broxton_init_cdclk() drm/i915: Rewrite broxton_get_display_clock_speed() in terms of the DE PLL vco/refclk drm/i915: Make bxt_set_cdclk() operate in terms of the current vs target DE PLL vco drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk check drm/i915: Set BXT cdclk to minimum initially drivers/gpu/drm/i915/i915_drv.h | 6 +- drivers/gpu/drm/i915/intel_display.c| 623 +++- drivers/gpu/drm/i915/intel_dp.c | 21 ++ drivers/gpu/drm/i915/intel_dpll_mgr.c | 19 +- drivers/gpu/drm/i915/intel_drv.h| 7 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 45 ++- 6 files changed, 443 insertions(+), 278 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/4] drm/i915: Add distinct stubs for PM hibernation phases (rev7)
== Series Details == Series: series starting with [1/4] drm/i915: Add distinct stubs for PM hibernation phases (rev7) URL : https://patchwork.freedesktop.org/series/7063/ State : failure == Summary == Applying: drm/i915: Add distinct stubs for PM hibernation phases Applying: drm/i915: Update domain tracking for GEM objects on hibernation Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_drv.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.c Patch failed at 0002 drm/i915: Update domain tracking for GEM objects on hibernation The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix for resume regression in ilk-bdw due to watermarks (rev2)
== Series Details == Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks (rev2) URL : https://patchwork.freedesktop.org/series/7155/ State : failure == Summary == Series 7155v2 drm/i915: Fix for resume regression in ilk-bdw due to watermarks http://patchwork.freedesktop.org/api/1.0/series/7155/revisions/2/mbox Test drv_hangman: Subgroup error-state-basic: fail -> PASS (ro-ilk1-i5-650) Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: pass -> FAIL (ro-byt-n2820) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:174 dwarn:0 dfail:0 fail:3 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_897/ accd824 drm-intel-nightly: 2016y-05m-13d-14h-38m-15s UTC integration manifest 4fc355d drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2) 03bf66b drm/i915: Don't leave old junk in ilk active watermarks on readout ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/13] drm/i915: cdclk code cleanup
On Wed, May 11, 2016 at 10:44:39PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Here's a bunch of cleanup, refactoring, etc. of the cdclk code. Much of > this serves as prep work for a larger series I have lined up which > takes Clint's SKL cdclk patch, expands on it, and then tries to unify > a lot of the SKL and BXT cdclk and display core init/uninit code. The > final goal is some future hardware enabling, and I really want that to > follow the same unified style as much as possible. > > Anyways, I thought I'd try to get some of the less controversial cleanups > out of the way first, and so I'm sending out this series first. > > Series available here: > git://github.com/vsyrjala/linux.git skl_bxt_cdclk_part_1 > > Ville Syrjälä (13): > drm/i915: Drop checks for max_pixclk failures in cdclk computation > drm/i915: Extract broadwell_calc_cdclk() > drm/i915: Untangle .fdi_link_train and cdclk vfunc setup > drm/i915: Don't pass dev_priv to broxton_calc_cdclk() > drm/i915: Use ilk_max_pixel_rate() for BXT cdclk calculation > drm/i915: Use skl_cdclk_decimal() on bxt > drm/i915: Remove 10% cdclk guardband on BXT > drm/i915: Extract skl_dpll0_disable() > drm/i915: Kill off dead code from skl_dpll0_enable() > drm/i915: s/freq/cdclk/ > drm/i915: s/required_vco/vco/ in skl cdclk code > drm/i915: Program BXT_CDCLK_CD2X_PIPE > drm/i915: Eliminate the CDCLK_CTL RMW on BXT Entire series pushed to dinq. Thanks for the reviews. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Refresh cached DP port register value on resume
From: Ville Syrjälä
During hibernation the cached DP port register value will be left with
whatever value we have there when we create the hibernation image.
Currently that means the port (and eDP PLL) will be off in the cached
value. However when we resume there is no guarantee that the value
in the actual register will match the cached value. If i915 isn't
loaded in the kernel that loads the hibernation image, the port may
well be on (eg. left on by the BIOS). The encoder state readout
does the right thing in this case and updates our encoder state
to reflect the actual hardware state. However the post-resume modeset
will then use the stale cached port register value in
intel_dp_link_down() and potentially confuse the hardware.
This was caught by the following assert
WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184
assert_edp_pll+0x99/0xa0 [i915]
eDP PLL state assertion failure (expected on, current off)
on account of the eDP PLL getting prematurely turned off when
shutting down the port, since the DP_PLL_ENABLE bit wasn't set
in the cached register value.
Presumably I introduced this problem in
commit 6fec76628333 ("drm/i915: Use intel_dp->DP in eDP PLL setup")
as before that we didn't update the cached value after shuttting the
port down. That's assuming the port got enabled at least once prior
to hibernating. If that didn't happen then the cached value would
still have been totally out of sync with reality (eg. first boot w/o
eDP on, then hibernate, and then resume with eDP on).
So, let's fix this properly and refresh the cached register value from
the hardware register during resume.
DDI platforms shouldn't use the cached value during port disable at
least, so shouldn't have this particular issue. They might still have
issues if we skip the initial modeset and then try to retrain the link
or something. But untangling this DP vs. DDI mess is a bigger topic,
so let's jut punt on DDI for now.
Cc: Jani Nikula
Cc: sta...@vger.kernel.org
Fixes: 6fec76628333 ("drm/i915: Use intel_dp->DP in eDP PLL setup")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 36330026ceff..a3f38115a3bd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4522,13 +4522,15 @@ static void intel_edp_panel_vdd_sanitize(struct
intel_dp *intel_dp)
void intel_dp_encoder_reset(struct drm_encoder *encoder)
{
- struct intel_dp *intel_dp;
+ struct drm_i915_private *dev_priv = to_i915(encoder->dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ if (!HAS_DDI(dev_priv))
+ intel_dp->DP = I915_READ(intel_dp->output_reg);
if (to_intel_encoder(encoder)->type != INTEL_OUTPUT_EDP)
return;
- intel_dp = enc_to_intel_dp(encoder);
-
pps_lock(intel_dp);
/*
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw
On Fri, May 13, 2016 at 10:35:16AM -0700, Matt Roper wrote:
> On Fri, May 13, 2016 at 08:18:18PM +0300, Ville Syrjälä wrote:
> > On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote:
> > > On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > When we resume the watermark register may contain some BIOS leftovers,
> > > > or just the hardware reset values. We should ignore those as the
> > > > pipes will be off anyway, and so frobbing around with intermediate
> > > > watermarks doesn't make much sense.
> > > >
> > > > In fact I think we should just throw the skip_intermediate_wm flag
> > > > out, and instead properly sanitize the "active" watermarks to match
> > > > the current plane and pipe states.
> > >
> > > That's what the flag was originally added for. The easiest way to
> > > sanitize the active watermarks is to run the current atomic state
> > > through our whole atomic check process to calculate all derived state
> > > plus the watermark values, and then just push the optimal values into
> > > the hardware. The flag tells us to just skip calculating the
> > > intermediate values (which might be bogus and/or fail anyway) since all
> > > we care about are the final/optimal values.
> >
> > We should still care about the transition to avoid any underruns,
> > so we should rather have proper intermediate watermarks here. I
> > think the problem we're working around here is basically poor hw state
> > readout. That is, we should more or less just discard the results of
> > the hw readout for any plane/pipe that is disabled.
>
> What I mean is that during initial boot, the sanitization we do is only
> programming the watermarks and not changing the configuration at all.
>
> For resume that's a bit different at the moment since we read out the
> hardware state and then immediately perform an atomic commit (with the
> saved state) without having sanitized the watermarks first. So I think
> another potential fix might be to just call sanitize_watermarks() after
> reading out the hardware state, but before committing the saved state.
> I think that approach is what you were referring to above by "sanitize
> the 'active' watermarks to match the current plane and pipe states," but
> unless we also changed our sanitization logic, we'd still have the
> skip_intermediate_wm flag since it gets used inside the sanitization
> code.
Invoking the entire machinery for this is pretty much overkill, I think.
And it requires these special cases in the normal modeset paths. If we
just did the readout in a better way, it would all be dealt with by the
readout code basically. We might still want to do a manual
active->hw->program hardware step right after the read hardware->hw->active
step to make sure both the cached hw and active values, and the actual
hardware are all in sync. This explicit progamming step would basically
be the sanitize part, with the first part being just the more proper
hardware readout.
>
> >
> > The end result should be one less special case to worry about. The less
> > we have of those the better.
> >
> > If we would ever run into a genuine case where we couldn't do the
> > intermediate watermarks properly, then we could always just shut
> > everything down first, and then bring it back up from scratch.
>
> Yeah, that's a good point.
>
>
> Matt
>
> >
> > >
> > > Anyway, this looks pretty similar to the fix I wrote right before I went
> > > OOO, but never got a chance to send out; I set the skip flag when the
> > > atomic state was created in the suspend function and you do it in the
> > > resume function, but I think the result should be the same either way,
> > > so overall lgtm.
> > >
> > > For both patches:
> > > Reviewed-by: Matt Roper
> > >
> > >
> > > > The actual wm state readout might
> > > > also need a bit of work. But for now, let's continue with the
> > > > skip_intermediate_wm to keep the fix more minimal.
> > > >
> > > > Fixes this sort of errors on resume
> > > > [drm:ilk_validate_pipe_wm] LP0 watermark invalid
> > > > [drm:intel_crtc_atomic_check] No valid intermediate pipe watermarks are
> > > > possible
> > > > [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed
> > > > with -22
> > > > and a boatload of subsequent modeset BAT fails on my ILK.
> > > >
> > > > Cc: Matt Roper
> > > > Cc: Maarten Lankhorst
> > > > Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark
> > > > programming (v11)")
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.c | 6 ++
> > > > 1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index a08c4a45b8d3..938653063f15 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -12003,6 +12003,9 @@ static int inte
[Intel-gfx] [CI 3/4] drm/i915: Lazily migrate the objects after hibernation
Now that we mark the object domains for having been restored from the
hibernation image, we not need to flush everything during resume and
can instead rely on the normal domain tracking to flush only when
required. The only caveat here are objects that are pinned for use by
the hardware, whose contents must be coherent for when the device
resumes reading from then (shortly afterwards with the driver assuming
the objects are in the correct domain).
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Tested-by: David Weinehall
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5fb14c835543..319f3b459b3e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3245,7 +3245,6 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
struct i915_ggtt *ggtt = &dev_priv->ggtt;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- bool flush;
i915_check_and_clear_faults(dev_priv);
@@ -3255,19 +3254,16 @@ void i915_gem_restore_gtt_mappings(struct drm_device
*dev)
/* Cache flush objects bound into GGTT and rebind them. */
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
- flush = false;
list_for_each_entry(vma, &obj->vma_list, obj_link) {
if (vma->vm != &ggtt->base)
continue;
WARN_ON(i915_vma_bind(vma, obj->cache_level,
PIN_UPDATE));
-
- flush = true;
}
- if (flush)
- i915_gem_clflush_object(obj, obj->pin_display);
+ if (obj->pin_display)
+ WARN_ON(i915_gem_object_set_to_gtt_domain(obj, false));
}
if (INTEL_INFO(dev)->gen >= 8) {
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/4] drm/i915: Update domain tracking for GEM objects on hibernation
When creating the hibernation image, the CPU will read the pages of all
objects and thus conflict with our domain tracking. We need to update
our domain tracking to accurately reflect the state on restoration.
v2: Perform the domain tracking inside freeze, before the image is
written, rather than upon restoration.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 12 +++-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 28
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6a2e7f84276b..dba03c026151 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1123,7 +1123,17 @@ static int i915_pm_freeze(struct device *dev)
static int i915_pm_freeze_late(struct device *dev)
{
- return i915_pm_suspend_late(dev);
+ int ret;
+
+ ret = i915_pm_suspend_late(dev);
+ if (ret)
+ return ret;
+
+ ret = i915_gem_freeze_late(dev_to_i915(dev));
+ if (ret)
+ return ret;
+
+ return 0;
}
/* thaw: called after creating the hibernation image, but before turning off.
*/
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ba614193cc9..72f0b02a8372 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2976,6 +2976,8 @@ int i915_gem_wait_ioctl(struct drm_device *dev, void
*data,
void i915_gem_load_init(struct drm_device *dev);
void i915_gem_load_cleanup(struct drm_device *dev);
void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
+int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
+
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 a3d826bb216b..aff386eea8ce 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5051,6 +5051,34 @@ void i915_gem_load_cleanup(struct drm_device *dev)
kmem_cache_destroy(dev_priv->objects);
}
+int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
+{
+ struct drm_i915_gem_object *obj;
+
+ /* Called just before we write the hibernation image.
+*
+* We need to update the domain tracking to reflect that the CPU
+* will be accessing all the pages to create and restore from the
+* hibernation, and so upon restoration those pages will be in the
+* CPU domain.
+*
+* To make sure the hibernation image contains the latest state,
+* we update that state just before writing out the image.
+*/
+
+ list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list) {
+ obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+ }
+
+ list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
+ obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+ }
+
+ return 0;
+}
+
void i915_gem_release(struct drm_device *dev, struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/4] drm/i915: Add distinct stubs for PM hibernation phases
Currently for handling the extra hibernation phases we just call the
equivalent suspend/resume phases. In the next couple of patches, I wish
to specialise the hibernation phases to reduce the amount of work
required for handling GEM objects.
v2: There are more! Don't forget the freeze phases.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5ae79601335c..6a2e7f84276b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1115,6 +1115,39 @@ static int i915_pm_resume(struct device *dev)
return i915_drm_resume(drm_dev);
}
+/* freeze: before creating the hibernation_image */
+static int i915_pm_freeze(struct device *dev)
+{
+ return i915_pm_suspend(dev);
+}
+
+static int i915_pm_freeze_late(struct device *dev)
+{
+ return i915_pm_suspend_late(dev);
+}
+
+/* thaw: called after creating the hibernation image, but before turning off.
*/
+static int i915_pm_thaw_early(struct device *dev)
+{
+ return i915_pm_resume_early(dev);
+}
+
+static int i915_pm_thaw(struct device *dev)
+{
+ return i915_pm_resume(dev);
+}
+
+/* restore: called after loading the hibernation image. */
+static int i915_pm_restore_early(struct device *dev)
+{
+ return i915_pm_resume_early(dev);
+}
+
+static int i915_pm_restore(struct device *dev)
+{
+ return i915_pm_resume(dev);
+}
+
/*
* Save all Gunit registers that may be lost after a D3 and a subsequent
* S0i[R123] transition. The list of registers needing a save/restore is
@@ -1669,14 +1702,14 @@ static const struct dev_pm_ops i915_pm_ops = {
* @restore, @restore_early : called after rebooting and restoring the
*hibernation image [PMSG_RESTORE]
*/
- .freeze = i915_pm_suspend,
- .freeze_late = i915_pm_suspend_late,
- .thaw_early = i915_pm_resume_early,
- .thaw = i915_pm_resume,
+ .freeze = i915_pm_freeze,
+ .freeze_late = i915_pm_freeze_late,
+ .thaw_early = i915_pm_thaw_early,
+ .thaw = i915_pm_thaw,
.poweroff = i915_pm_suspend,
.poweroff_late = i915_pm_poweroff_late,
- .restore_early = i915_pm_resume_early,
- .restore = i915_pm_resume,
+ .restore_early = i915_pm_restore_early,
+ .restore = i915_pm_restore,
/* S0ix (via runtime suspend) event handlers */
.runtime_suspend = intel_runtime_suspend,
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] drm/i915: Skip clearing the GGTT on full-ppgtt systems
Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.
For aliasing-ppgtt, we could almost do the same except that we do allow
userspace access to the global-GTT via execbuf in order to workraound
some quirks of certain instructions. (This execbuf path is filtered out
with EINVAL on full-ppgtt.)
The most dramatic effect this will have will be during resume, as with
full-ppgtt the GGTT is only used sparingly.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Tested-by: David Weinehall
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 319f3b459b3e..7eab619a3eb2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2477,6 +2477,13 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
+static void nop_clear_range(struct i915_address_space *vm,
+ uint64_t start,
+ uint64_t length,
+ bool use_scratch)
+{
+}
+
static void gen8_ggtt_clear_range(struct i915_address_space *vm,
uint64_t start,
uint64_t length,
@@ -3072,14 +3079,17 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ret = ggtt_probe_common(dev, ggtt->size);
- ggtt->base.clear_range = gen8_ggtt_clear_range;
- if (IS_CHERRYVIEW(dev_priv))
- ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
- else
- ggtt->base.insert_entries = gen8_ggtt_insert_entries;
ggtt->base.bind_vma = ggtt_bind_vma;
ggtt->base.unbind_vma = ggtt_unbind_vma;
+ ggtt->base.clear_range = nop_clear_range;
+ if (!USES_FULL_PPGTT(dev_priv))
+ ggtt->base.clear_range = gen8_ggtt_clear_range;
+
+ ggtt->base.insert_entries = gen8_ggtt_insert_entries;
+ if (IS_CHERRYVIEW(dev_priv))
+ ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
+
return ret;
}
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw
On Fri, May 13, 2016 at 08:18:18PM +0300, Ville Syrjälä wrote:
> On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote:
> > On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > When we resume the watermark register may contain some BIOS leftovers,
> > > or just the hardware reset values. We should ignore those as the
> > > pipes will be off anyway, and so frobbing around with intermediate
> > > watermarks doesn't make much sense.
> > >
> > > In fact I think we should just throw the skip_intermediate_wm flag
> > > out, and instead properly sanitize the "active" watermarks to match
> > > the current plane and pipe states.
> >
> > That's what the flag was originally added for. The easiest way to
> > sanitize the active watermarks is to run the current atomic state
> > through our whole atomic check process to calculate all derived state
> > plus the watermark values, and then just push the optimal values into
> > the hardware. The flag tells us to just skip calculating the
> > intermediate values (which might be bogus and/or fail anyway) since all
> > we care about are the final/optimal values.
>
> We should still care about the transition to avoid any underruns,
> so we should rather have proper intermediate watermarks here. I
> think the problem we're working around here is basically poor hw state
> readout. That is, we should more or less just discard the results of
> the hw readout for any plane/pipe that is disabled.
What I mean is that during initial boot, the sanitization we do is only
programming the watermarks and not changing the configuration at all.
For resume that's a bit different at the moment since we read out the
hardware state and then immediately perform an atomic commit (with the
saved state) without having sanitized the watermarks first. So I think
another potential fix might be to just call sanitize_watermarks() after
reading out the hardware state, but before committing the saved state.
I think that approach is what you were referring to above by "sanitize
the 'active' watermarks to match the current plane and pipe states," but
unless we also changed our sanitization logic, we'd still have the
skip_intermediate_wm flag since it gets used inside the sanitization
code.
>
> The end result should be one less special case to worry about. The less
> we have of those the better.
>
> If we would ever run into a genuine case where we couldn't do the
> intermediate watermarks properly, then we could always just shut
> everything down first, and then bring it back up from scratch.
Yeah, that's a good point.
Matt
>
> >
> > Anyway, this looks pretty similar to the fix I wrote right before I went
> > OOO, but never got a chance to send out; I set the skip flag when the
> > atomic state was created in the suspend function and you do it in the
> > resume function, but I think the result should be the same either way,
> > so overall lgtm.
> >
> > For both patches:
> > Reviewed-by: Matt Roper
> >
> >
> > > The actual wm state readout might
> > > also need a bit of work. But for now, let's continue with the
> > > skip_intermediate_wm to keep the fix more minimal.
> > >
> > > Fixes this sort of errors on resume
> > > [drm:ilk_validate_pipe_wm] LP0 watermark invalid
> > > [drm:intel_crtc_atomic_check] No valid intermediate pipe watermarks are
> > > possible
> > > [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with
> > > -22
> > > and a boatload of subsequent modeset BAT fails on my ILK.
> > >
> > > Cc: Matt Roper
> > > Cc: Maarten Lankhorst
> > > Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark
> > > programming (v11)")
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index a08c4a45b8d3..938653063f15 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -12003,6 +12003,9 @@ static int intel_crtc_atomic_check(struct
> > > drm_crtc *crtc,
> > > DRM_DEBUG_KMS("No valid intermediate pipe watermarks
> > > are possible\n");
> > > return ret;
> > > }
> > > + } else if (dev_priv->display.compute_intermediate_wm) {
> > > + if (HAS_PCH_SPLIT(dev_priv) && INTEL_GEN(dev_priv) < 9)
> > > + pipe_config->wm.intermediate =
> > > pipe_config->wm.optimal.ilk;
> > > }
> > >
> > > if (INTEL_INFO(dev)->gen >= 9) {
> > > @@ -15991,6 +15994,9 @@ retry:
> > >
> > > state->acquire_ctx = &ctx;
> > >
> > > + /* ignore any reset values/BIOS leftovers in the WM registers */
> > > + to_intel_atomic_state(state)->skip_intermediate_wm = true;
> > > +
> > > for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > >
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw
On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote:
> On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When we resume the watermark register may contain some BIOS leftovers,
> > or just the hardware reset values. We should ignore those as the
> > pipes will be off anyway, and so frobbing around with intermediate
> > watermarks doesn't make much sense.
> >
> > In fact I think we should just throw the skip_intermediate_wm flag
> > out, and instead properly sanitize the "active" watermarks to match
> > the current plane and pipe states.
>
> That's what the flag was originally added for. The easiest way to
> sanitize the active watermarks is to run the current atomic state
> through our whole atomic check process to calculate all derived state
> plus the watermark values, and then just push the optimal values into
> the hardware. The flag tells us to just skip calculating the
> intermediate values (which might be bogus and/or fail anyway) since all
> we care about are the final/optimal values.
We should still care about the transition to avoid any underruns,
so we should rather have proper intermediate watermarks here. I
think the problem we're working around here is basically poor hw state
readout. That is, we should more or less just discard the results of
the hw readout for any plane/pipe that is disabled.
The end result should be one less special case to worry about. The less
we have of those the better.
If we would ever run into a genuine case where we couldn't do the
intermediate watermarks properly, then we could always just shut
everything down first, and then bring it back up from scratch.
>
> Anyway, this looks pretty similar to the fix I wrote right before I went
> OOO, but never got a chance to send out; I set the skip flag when the
> atomic state was created in the suspend function and you do it in the
> resume function, but I think the result should be the same either way,
> so overall lgtm.
>
> For both patches:
> Reviewed-by: Matt Roper
>
>
> > The actual wm state readout might
> > also need a bit of work. But for now, let's continue with the
> > skip_intermediate_wm to keep the fix more minimal.
> >
> > Fixes this sort of errors on resume
> > [drm:ilk_validate_pipe_wm] LP0 watermark invalid
> > [drm:intel_crtc_atomic_check] No valid intermediate pipe watermarks are
> > possible
> > [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with
> > -22
> > and a boatload of subsequent modeset BAT fails on my ILK.
> >
> > Cc: Matt Roper
> > Cc: Maarten Lankhorst
> > Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark
> > programming (v11)")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a08c4a45b8d3..938653063f15 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12003,6 +12003,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
> > *crtc,
> > DRM_DEBUG_KMS("No valid intermediate pipe watermarks
> > are possible\n");
> > return ret;
> > }
> > + } else if (dev_priv->display.compute_intermediate_wm) {
> > + if (HAS_PCH_SPLIT(dev_priv) && INTEL_GEN(dev_priv) < 9)
> > + pipe_config->wm.intermediate =
> > pipe_config->wm.optimal.ilk;
> > }
> >
> > if (INTEL_INFO(dev)->gen >= 9) {
> > @@ -15991,6 +15994,9 @@ retry:
> >
> > state->acquire_ctx = &ctx;
> >
> > + /* ignore any reset values/BIOS leftovers in the WM registers */
> > + to_intel_atomic_state(state)->skip_intermediate_wm = true;
> > +
> > for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > /*
> > * Force recalculation even if we restore
> > --
> > 2.7.4
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2)
From: Ville Syrjälä
When we resume the watermark register may contain some BIOS leftovers,
or just the hardware reset values. We should ignore those as the
pipes will be off anyway, and so frobbing around with intermediate
watermarks doesn't make much sense.
In fact I think we should just throw the skip_intermediate_wm flag
out, and instead properly sanitize the "active" watermarks to match
the current plane and pipe states. The actual wm state readout might
also need a bit of work. But for now, let's continue with the
skip_intermediate_wm to keep the fix more minimal.
Fixes this sort of errors on resume
[drm:ilk_validate_pipe_wm] LP0 watermark invalid
[drm:intel_crtc_atomic_check] No valid intermediate pipe watermarks are possible
[drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22
and a boatload of subsequent modeset BAT fails on my ILK.
v2:
- Rebase; the SKL atomic WM patches that just landed changed the WM
structure fields in intel_crtc_state slightly. (Matt)
Cc: Matt Roper
Cc: Maarten Lankhorst
Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming
(v11)")
Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
Signed-off-by: Matt Roper
---
Ville sent his patch just as the SKL atomic wm code was being merged to dinq,
so pipe_config->wm.intermediate becomes pipe_config->wm.ilk.intermediate now.
The logic remains the same, so just re-sending a rebased copy of his patch
so CI knows how to build it.
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0194390..e6f763e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12003,6 +12003,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
DRM_DEBUG_KMS("No valid intermediate pipe watermarks
are possible\n");
return ret;
}
+ } else if (dev_priv->display.compute_intermediate_wm) {
+ if (HAS_PCH_SPLIT(dev_priv) && INTEL_GEN(dev_priv) < 9)
+ pipe_config->wm.ilk.intermediate =
pipe_config->wm.ilk.optimal;
}
if (INTEL_INFO(dev)->gen >= 9) {
@@ -15970,6 +15973,9 @@ retry:
state->acquire_ctx = &ctx;
+ /* ignore any reset values/BIOS leftovers in the WM registers */
+ to_intel_atomic_state(state)->skip_intermediate_wm = true;
+
for_each_crtc_in_state(state, crtc, crtc_state, i) {
/*
* Force recalculation even if we restore
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths
== Series Details == Series: drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths URL : https://patchwork.freedesktop.org/series/7158/ State : failure == Summary == Series 7158v1 drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths http://patchwork.freedesktop.org/api/1.0/series/7158/revisions/1/mbox Test drv_hangman: Subgroup error-state-basic: fail -> PASS (ro-ilk1-i5-650) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ro-hsw-i3-4010u) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:175 dwarn:0 dfail:0 fail:2 skip:41 ro-hsw-i3-4010u total:218 pass:192 dwarn:0 dfail:0 fail:1 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_896/ accd824 drm-intel-nightly: 2016y-05m-13d-14h-38m-15s UTC integration manifest 297334a9 drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw
On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When we resume the watermark register may contain some BIOS leftovers,
> or just the hardware reset values. We should ignore those as the
> pipes will be off anyway, and so frobbing around with intermediate
> watermarks doesn't make much sense.
>
> In fact I think we should just throw the skip_intermediate_wm flag
> out, and instead properly sanitize the "active" watermarks to match
> the current plane and pipe states.
That's what the flag was originally added for. The easiest way to
sanitize the active watermarks is to run the current atomic state
through our whole atomic check process to calculate all derived state
plus the watermark values, and then just push the optimal values into
the hardware. The flag tells us to just skip calculating the
intermediate values (which might be bogus and/or fail anyway) since all
we care about are the final/optimal values.
Anyway, this looks pretty similar to the fix I wrote right before I went
OOO, but never got a chance to send out; I set the skip flag when the
atomic state was created in the suspend function and you do it in the
resume function, but I think the result should be the same either way,
so overall lgtm.
For both patches:
Reviewed-by: Matt Roper
> The actual wm state readout might
> also need a bit of work. But for now, let's continue with the
> skip_intermediate_wm to keep the fix more minimal.
>
> Fixes this sort of errors on resume
> [drm:ilk_validate_pipe_wm] LP0 watermark invalid
> [drm:intel_crtc_atomic_check] No valid intermediate pipe watermarks are
> possible
> [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22
> and a boatload of subsequent modeset BAT fails on my ILK.
>
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming
> (v11)")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a08c4a45b8d3..938653063f15 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12003,6 +12003,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> DRM_DEBUG_KMS("No valid intermediate pipe watermarks
> are possible\n");
> return ret;
> }
> + } else if (dev_priv->display.compute_intermediate_wm) {
> + if (HAS_PCH_SPLIT(dev_priv) && INTEL_GEN(dev_priv) < 9)
> + pipe_config->wm.intermediate =
> pipe_config->wm.optimal.ilk;
> }
>
> if (INTEL_INFO(dev)->gen >= 9) {
> @@ -15991,6 +15994,9 @@ retry:
>
> state->acquire_ctx = &ctx;
>
> + /* ignore any reset values/BIOS leftovers in the WM registers */
> + to_intel_atomic_state(state)->skip_intermediate_wm = true;
> +
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> /*
>* Force recalculation even if we restore
> --
> 2.7.4
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable GuC submission
== Series Details ==
Series: Enable GuC submission
URL : https://patchwork.freedesktop.org/series/7153/
State : failure
== Summary ==
Series 7153v1 Enable GuC submission
http://patchwork.freedesktop.org/api/1.0/series/7153/revisions/1/mbox
Test drv_hangman:
Subgroup error-state-basic:
fail -> PASS (ro-ilk1-i5-650)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass -> FAIL (ro-ivb2-i7-3770)
ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38
ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13
ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32
ro-byt-n2820 total:218 pass:175 dwarn:0 dfail:0 fail:2 skip:41
ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25
ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25
ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67
ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61
ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36
ro-ivb2-i7-3770 total:219 pass:186 dwarn:0 dfail:0 fail:1 skip:32
ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25
ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41
Results at /archive/results/CI_IGT_test/RO_Patchwork_894/
accd824 drm-intel-nightly: 2016y-05m-13d-14h-38m-15s UTC integration manifest
9f94194 drm/i915/guc: change default to using GuC submission if possible
1d395e6 drm/i915/guc: rework guc_add_workqueue_item()
0800e1c drm/i915/guc: don't spinwait if the GuC's workqueue is full
befef39 drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space,
submit}()
6fd5f03 drm/i915/guc: add enable_guc_loading parameter
35a330e drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED
d0009d1 drm/i915/guc: rename loader entry points
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix for resume regression in ilk-bdw due to watermarks
== Series Details == Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks URL : https://patchwork.freedesktop.org/series/7155/ State : failure == Summary == CC drivers/usb/host/xhci-trace.o CC [M] drivers/video/fbdev/core/sysfillrect.o CC [M] drivers/video/fbdev/core/syscopyarea.o CC drivers/usb/host/xhci-pci.o CC [M] drivers/video/fbdev/core/sysimgblt.o LD drivers/usb/core/usbcore.o LD drivers/usb/core/built-in.o CC [M] drivers/video/fbdev/core/fb_sys_fops.o CC drivers/tty/serial/8250/8250_pci.o LD [M] drivers/usb/serial/usbserial.o LD drivers/video/console/built-in.o CC drivers/tty/serial/8250/8250_early.o LD drivers/video/fbdev/core/fb.o LD drivers/tty/serial/8250/8250.o LD drivers/video/fbdev/core/built-in.o LD drivers/video/fbdev/built-in.o LD drivers/video/built-in.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o LD drivers/tty/serial/8250/8250_base.o LD drivers/tty/serial/8250/built-in.o LD drivers/tty/serial/built-in.o LD drivers/usb/host/xhci-hcd.o LD drivers/usb/host/built-in.o LD drivers/usb/built-in.o LD drivers/tty/vt/built-in.o LD drivers/tty/built-in.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/4] drm/i915: Add distinct stubs for PM hibernation phases (rev4)
== Series Details == Series: series starting with [1/4] drm/i915: Add distinct stubs for PM hibernation phases (rev4) URL : https://patchwork.freedesktop.org/series/7063/ State : failure == Summary == Applying: drm/i915: Add distinct stubs for PM hibernation phases Applying: drm/i915: Update domain tracking for GEM objects on hibernation Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c M drivers/gpu/drm/i915/i915_drv.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_drv.h Auto-merging drivers/gpu/drm/i915/i915_drv.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.c Patch failed at 0002 drm/i915: Update domain tracking for GEM objects on hibernation The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for Move dpio access out of intel_display.c
== Series Details == Series: Move dpio access out of intel_display.c URL : https://patchwork.freedesktop.org/series/7150/ State : failure == Summary == Series 7150v1 Move dpio access out of intel_display.c http://patchwork.freedesktop.org/api/1.0/series/7150/revisions/1/mbox Test drv_hangman: Subgroup error-state-basic: fail -> PASS (ro-ilk1-i5-650) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ro-ivb2-i7-3770) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:175 dwarn:0 dfail:0 fail:2 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:186 dwarn:0 dfail:0 fail:1 skip:32 ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_892/ accd824 drm-intel-nightly: 2016y-05m-13d-14h-38m-15s UTC integration manifest e926ca9 drm/i915: Move toggling of CHV DPIO_DCLKP_EN to intel_dpio_phy.c 7d40ee1 drm/i915: Move CHV divider readout to intel_dpio_phy.c 4c6ddda drm/i915: Move VLV divider readout to intel_dpio_phy.c 2ba6b64 drm/i915: Merge vlv/chv _prepare_pll() with their enable counterpart 55b0906 drm/i915: Move dpio code of VLV/CHV dpll enabling to intel_dpio_phy.c 74a984c drm/i915: Rename struct dpll to struct intel_dpll ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/7] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED
On 13/05/16 15:36, Dave Gordon wrote:
For now, anything with a GuC requires uCode loading, and then supports
command submission once loaded. But these are logically distinct from
simply "having a GuC", so we need a separate macro for the latter. Then,
various tests should use this new macro rather than HAS_GUC_UCODE() or
testing enable_guc_submission.
v4:
Added a couple more uses of the new macro.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
4 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b7..3b9ee51 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2726,8 +2726,14 @@ struct drm_i915_cmd_table {
#define HAS_CSR(dev) (IS_GEN9(dev))
-#define HAS_GUC_UCODE(dev) (IS_GEN9(dev) && !IS_KABYLAKE(dev))
-#define HAS_GUC_SCHED(dev) (IS_GEN9(dev) && !IS_KABYLAKE(dev))
+/*
+ * For now, anything with a GuC requires uCode loading, and then supports
+ * command submission once loaded. But these are logically independent
+ * properties, so we have separate macros to test them.
+ */
+#define HAS_GUC(dev) (IS_GEN9(dev) && !IS_KABYLAKE(dev))
+#define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
+#define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 43e45b7..2a7be71 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4866,7 +4866,7 @@ int i915_gem_init_engines(struct drm_device *dev)
intel_mocs_init_l3cc_table(dev);
/* We can't enable contexts until all firmware is loaded */
- if (HAS_GUC_UCODE(dev)) {
+ if (HAS_GUC(dev)) {
ret = intel_guc_setup(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1bb0f9a..c584282 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4844,7 +4844,7 @@ static void gen9_enable_rc6(struct drm_i915_private
*dev_priv)
for_each_engine(engine, dev_priv)
I915_WRITE(RING_MAX_IDLE(engine->mmio_base), 10);
- if (HAS_GUC_UCODE(dev_priv))
+ if (HAS_GUC(dev_priv))
I915_WRITE(GUC_MAX_IDLE_COUNT, 0xA);
I915_WRITE(GEN6_RC_SLEEP, 0);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 385114b..c1ca458 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1715,7 +1715,7 @@ int intel_guc_reset(struct drm_i915_private *dev_priv)
int ret;
unsigned long irqflags;
- if (!i915.enable_guc_submission)
+ if (!HAS_GUC(dev_priv))
return -EINVAL;
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 5/7] drm/i915/guc: don't spinwait if the GuC's workqueue is full
On 13/05/16 15:36, Dave Gordon wrote:
Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)
We'll also add a counter to the GuC client statistics, to see how often
we find the WQ full.
v2:
Flag the likely() code path (Tvtrko Ursulin).
v4:
Add/update comments about failure counters (Tvtrko Ursulin).
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 1 +
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
drivers/gpu/drm/i915/intel_guc.h | 22 --
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 24f4105..de05841 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2506,6 +2506,7 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
client->wq_size, client->wq_offset, client->wq_tail);
+ seq_printf(m, "\tWork queue full: %u\n", client->no_wq_space);
seq_printf(m, "\tFailed to queue: %u\n", client->q_fail);
seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
seq_printf(m, "\tLast submission result: %d\n", client->retcode);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 87cb739..85b2b89 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -468,26 +468,22 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
*/
int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
{
- const size_t size = sizeof(struct guc_wq_item);
+ const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
struct guc_process_desc *desc;
- int ret = -ETIMEDOUT, timeout_counter = 200;
+ u32 freespace;
GEM_BUG_ON(gc == NULL);
desc = gc->client_base + gc->proc_desc_offset;
- while (timeout_counter-- > 0) {
- if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) {
- ret = 0;
- break;
- }
+ freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
+ if (likely(freespace >= wqi_size))
+ return 0;
- if (timeout_counter)
- usleep_range(1000, 2000);
- };
+ gc->no_wq_space += 1;
- return ret;
+ return -EAGAIN;
}
static int guc_add_workqueue_item(struct i915_guc_client *gc,
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 91f315c..380a743 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -48,9 +48,18 @@ struct drm_i915_gem_request;
* queue (a circular array of work items), again described in the process
* descriptor. Work queue pages are mapped momentarily as required.
*
- * Finally, we also keep a few statistics here, including the number of
- * submissions to each engine, and a record of the last submission failure
- * (if any).
+ * We also keep a few statistics on failures. Ideally, these should all
+ * be zero!
+ * no_wq_space: times that the submission pre-check found no space was
+ *available in the work queue (note, the queue is shared,
+ *not per-engine). It is OK for this to be nonzero, but
+ *it should not be huge!
+ * q_fail: failed to enqueue a work item. This should never happen,
+ * because we check for space beforehand.
+ * b_fail: failed to ring the doorbell. This should never happen, unless
+ * somehow the hardware misbehaves, or maybe if the GuC firmware
+ * crashes? We probably need to reset the GPU to recover.
+ * retcode: errno from last guc_submit()
*/
struct i915_guc_client {
struct drm_i915_gem_object *client_obj;
@@ -71,12 +80,13 @@ struct i915_guc_client {
uint32_t wq_tail;
uint32_t unused;/* Was 'wq_head'*/
- /* GuC submission statistics & status */
- uint64_t submissions[GUC_MAX_ENGINES_NUM];
+ uint32_t no_wq_space;
uint32_t q_fail;
uint32_t b_fail;
int retcode;
- int spare; /* pad to 32 DWords */
+
+ /* Per-engine counts of GuC submissions */
+ uint64_t submissions[GUC_MAX_ENGINES_NUM];
};
enum intel_guc_fw_status {
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/7] drm/i915/guc: add enable_guc_loading parameter
On 13/05/16 15:36, Dave Gordon wrote:
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.
In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
-1 (default) whatever the platform default is
0 DISABLE don't load/use the GuC
1 BEST EFFORT try to load/use the GuC, fallback if not available
2 REQUIRE must load/use the GuC, else leave the GPU wedged
The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.
v4:
Changed some error-message levels, mostly ERROR->INFO, per
review comments by Tvrtko Ursulin.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c| 1 -
drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
drivers/gpu/drm/i915/i915_params.c | 14 +++-
drivers/gpu/drm/i915/i915_params.h | 3 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 108 -
5 files changed, 76 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2a7be71..2bf8743 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4870,7 +4870,6 @@ int i915_gem_init_engines(struct drm_device *dev)
ret = intel_guc_setup(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
This error msg should go as well I think.
- ret = -EIO;
goto out;
}
}
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 169242a..916cd67 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -969,7 +969,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
- if (!i915.enable_guc_submission)
+ if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
ctx = dev_priv->kernel_context;
@@ -995,7 +995,7 @@ int intel_guc_resume(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
- if (!i915.enable_guc_submission)
+ if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
Will the above two do the right thing for the fw_path == NULL case? That
is !HAS_GUC_UCODE && HAS_GUC_SCHED? Looks like load status will bt NONE
in that case, GuC submission will be enabled and suspend and resume
hooks will be skipped?
Maybe fetch and load status should be set to success on such platforms?
ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 383c076..6a5578c 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -54,7 +54,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_submission = false,
+ .enable_guc_loading = -1,
+ .enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -198,8 +199,15 @@ struct i915_params i915 __read_mostly = {
"(0=use value from vbt [default], 1=low power swing(200mV),"
"2=default swing(400mV))");
-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int,
0400);
+MODULE_PARM_DESC(enable_guc_loading,
+ "Enable GuC firmware loading "
+ "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+ "Enable GuC submission "
+ "(-1=auto, 0=never [default], 1=if available, 2=required)");
module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 65e73dd..1323261 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,8 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+ int enable_guc_loading;
+ int enable_guc_submission;
[Intel-gfx] [PATCH] drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths
From: Ville Syrjälä
DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares
about. However error paths everyone cares about, so hiding the error
debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS
for those instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a08c4a45b8d3..4fe5c23f784a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13590,7 +13590,7 @@ static int intel_atomic_commit(struct drm_device *dev,
ret = intel_atomic_prepare_commit(dev, state, nonblock);
if (ret) {
- DRM_DEBUG_ATOMIC("Preparing state failed with %i\n", ret);
+ DRM_DEBUG_KMS("Preparing state failed with %i\n", ret);
return ret;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] Revert "tests: Separate tests with lots of subtests"
This reverts commit a633ad03c6a0e96eecfd4933ea0dffb68ed40e07 as it
completely breaks building the gem_concurrent_blit tests.
---
tests/Makefile.am | 12 +++-
tests/Makefile.sources | 22 ++
2 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 7bbec84..f3ae369 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -14,12 +14,6 @@ test-list.txt: Makefile.sources
@echo ${single_kernel_tests} ${multi_kernel_tests} >> $@
@echo END TESTLIST >> $@
-test-list-full.txt: Makefile.sources
- @echo TESTLIST > $@
- @echo ${single_kernel_tests} ${multi_kernel_tests}
${extra_multi_kernel_tests} >> $@
- @echo END TESTLIST >> $@
-
-
noinst_PROGRAMS = \
$(HANG) \
$(TESTS_testsuite) \
@@ -44,14 +38,14 @@ dist_pkgdata_DATA = \
all-local: .gitignore
.gitignore: Makefile.sources
- @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt test-list-full.txt
.gitignore" | sed 's/\s\+/\n/g' | sort > $@
+ @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt .gitignore" | sed
's/\s\+/\n/g' | sort > $@
-pkgdata_DATA = test-list.txt test-list-full.txt
+pkgdata_DATA = test-list.txt
EXTRA_PROGRAMS = $(HANG)
EXTRA_DIST = $(common_files)
-CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt test-list-full.txt .gitignore
+CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt .gitignore
AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\
-I$(srcdir)/.. \
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ad54317..50c5b14 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -20,6 +20,8 @@ TESTS_progs_M = \
gem_busy \
gem_caching \
gem_close_race \
+ gem_concurrent_blit \
+ gem_concurrent_all \
gem_create \
gem_cs_tlb \
gem_ctx_bad_exec \
@@ -119,11 +121,6 @@ TESTS_progs_M = \
template \
$(NULL)
-TESTS_progs_XM = \
-gem_concurrent_blit \
-gem_concurrent_all \
-$(NULL)
-
TESTS_progs = \
core_auth \
core_getclient \
@@ -226,15 +223,6 @@ multi_kernel_tests = \
$(TESTS_scripts_M) \
$(NULL)
-
-# This target contains testcases with lots of subtests.
-# It was split from multi_kernel_tests because of the overhead of listing all
-# the subtests in piglit
-extra_multi_kernel_tests = \
- $(TESTS_progs_XM) \
- $(NULL)
-
-
# This target is for simple testcase which don't expose any subtest.
#
# Your testcase should probably use igt_simple_main, but none of the other
magic
@@ -249,12 +237,6 @@ kernel_tests = \
$(multi_kernel_tests) \
$(NULL)
-kernel_tests_full = \
-$(single_kernel_tests) \
-$(multi_kernel_tests) \
- $(extra_multi_kernel_tests) \
- $(NULL)
-
# Test that exercise specific asserts in the test framework library and are
# hence expected to fail.
XFAIL_TESTS = \
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/7] drm/i915/guc: rename loader entry points
On 13/05/16 15:36, Dave Gordon wrote:
The GuC initialisation code could do other things apart from loading
firmware, so here we rename the three primary entry points to remove any
specific reference to "ucode" (no functional changes, just renaming).
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/intel_guc.h| 6 +++---
drivers/gpu/drm/i915/intel_guc_loader.c | 19 ++-
4 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 547100f..7d93f8f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -507,7 +507,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
* working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
- intel_guc_ucode_init(dev);
+ intel_guc_init(dev);
ret = i915_gem_init(dev);
if (ret)
@@ -547,7 +547,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
cleanup_gem:
i915_gem_fini(dev);
cleanup_irq:
- intel_guc_ucode_fini(dev);
+ intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
cleanup_csr:
@@ -1528,7 +1528,7 @@ int i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
flush_workqueue(dev_priv->wq);
- intel_guc_ucode_fini(dev);
+ intel_guc_fini(dev);
i915_gem_fini(dev);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a3d826b..43e45b7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4867,7 +4867,7 @@ int i915_gem_init_engines(struct drm_device *dev)
/* We can't enable contexts until all firmware is loaded */
if (HAS_GUC_UCODE(dev)) {
- ret = intel_guc_ucode_load(dev);
+ ret = intel_guc_setup(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
ret = -EIO;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9d79c4c..3984136 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -138,9 +138,9 @@ struct intel_guc {
};
/* intel_guc_loader.c */
-extern void intel_guc_ucode_init(struct drm_device *dev);
-extern int intel_guc_ucode_load(struct drm_device *dev);
-extern void intel_guc_ucode_fini(struct drm_device *dev);
+extern void intel_guc_init(struct drm_device *dev);
+extern int intel_guc_setup(struct drm_device *dev);
+extern void intel_guc_fini(struct drm_device *dev);
extern const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status);
extern int intel_guc_suspend(struct drm_device *dev);
extern int intel_guc_resume(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 23345e1..b14a3a3 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -375,18 +375,19 @@ static int i915_reset_guc(struct drm_i915_private
*dev_priv)
}
/**
- * intel_guc_ucode_load() - load GuC uCode into the device
+ * intel_guc_setup() - finish preparing the GuC for activity
* @dev: drm device
*
* Called from gem_init_hw() during driver loading and also after a GPU reset.
*
+ * The main action required here it to load the GuC uCode into the device.
* The firmware image should have already been fetched into memory by the
- * earlier call to intel_guc_ucode_init(), so here we need only check that
- * is succeeded, and then transfer the image to the h/w.
+ * earlier call to intel_guc_init(), so here we need only check that worked,
+ * and then transfer the image to the h/w.
*
* Return:non-zero code on error
*/
-int intel_guc_ucode_load(struct drm_device *dev)
+int intel_guc_setup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
@@ -620,15 +621,15 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
}
/**
- * intel_guc_ucode_init() - define parameters and fetch firmware
+ * intel_guc_init() - define parameters and fetch firmware
* @dev: drm device
*
* Called early during driver load, but after GEM is initialised.
*
* The firmware will be transferred to the GuC's memory later,
- * when intel_guc_ucode_load() is called.
+ * when intel_guc_setup() is called.
*/
-void intel_guc_ucode_init(struct drm_device *dev)
+void intel_guc_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
@@ -676,10 +677,10 @@ void intel_guc_ucode_init(st
Re: [Intel-gfx] [PATCH RESEND 2/2] drm/i915: don't mix bitwise and logical operations for has_snoop
On 13/05/16 15:04, Jani Nikula wrote:
Also make the code more readable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 547100fa3122..a8c79f6512a4 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -954,9 +954,11 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 9)
gen9_sseu_info_init(dev);
- /* Snooping is broken on BXT A stepping. */
info->has_snoop = !info->has_llc;
- info->has_snoop &= !IS_BXT_REVID(dev, 0, BXT_REVID_A1);
+
+ /* Snooping is broken on BXT A stepping. */
+ if (IS_BXT_REVID(dev, 0, BXT_REVID_A1))
+ info->has_snoop = false;
DRM_DEBUG_DRIVER("slice total: %u\n", info->slice_total);
DRM_DEBUG_DRIVER("subslice total: %u\n", info->subslice_total);
Yeah that is more readable.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools
On 13/05/16 15:47, Jani Nikula wrote:
On Fri, 13 May 2016, Chris Wilson wrote:
On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
On 13/05/16 15:04, Jani Nikula wrote:
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b70f05c..bb0b6f64000e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -752,7 +752,7 @@ struct intel_csr {
func(has_ddi) sep \
func(has_fpga_dbg)
-#define DEFINE_FLAG(name) u8 name:1
+#define DEFINE_FLAG(name) bool name:1
#define SEP_SEMICOLON ;
struct intel_device_info {
The churn virus spreads? :)
I tried that but it was negatively impacting the compiler. For some
reason it increases .text by 2.5k here. Don't see anything obvious,
would have to look at the code more closely to spot exactly why.
Oh, that's not fun. bool:1 holds such promise for a clear explanation of
the most common form of bitfield.
Really a bummer, especially since assigning any positive even number to
unsigned int foo:1 will result in 0.
That is a pretty strong argument to go for this rather than make sure
all places which set them are correct.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [RESEND,1/2] drm/i915: make device info bitfield flags bools
== Series Details == Series: series starting with [RESEND,1/2] drm/i915: make device info bitfield flags bools URL : https://patchwork.freedesktop.org/series/7149/ State : failure == Summary == Series 7149v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/7149/revisions/1/mbox Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ro-byt-n2820) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (ro-ivb2-i7-3770) Test kms_sink_crc_basic: skip -> PASS (ro-skl-i7-6700hq) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:174 dwarn:0 dfail:0 fail:3 skip:42 ro-byt-n2820 total:218 pass:173 dwarn:0 dfail:0 fail:4 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-skl-i7-6700hq total:214 pass:190 dwarn:0 dfail:0 fail:0 skip:24 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_891/ b72b8e4 drm-intel-nightly: 2016y-05m-13d-12h-18m-56s UTC integration manifest 23b0257 drm/i915: don't mix bitwise and logical operations for has_snoop 0e2cf7a drm/i915: make device info bitfield flags bools ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Ignore stale wm register values on resume on ilk-bdw
From: Ville Syrjälä
When we resume the watermark register may contain some BIOS leftovers,
or just the hardware reset values. We should ignore those as the
pipes will be off anyway, and so frobbing around with intermediate
watermarks doesn't make much sense.
In fact I think we should just throw the skip_intermediate_wm flag
out, and instead properly sanitize the "active" watermarks to match
the current plane and pipe states. The actual wm state readout might
also need a bit of work. But for now, let's continue with the
skip_intermediate_wm to keep the fix more minimal.
Fixes this sort of errors on resume
[drm:ilk_validate_pipe_wm] LP0 watermark invalid
[drm:intel_crtc_atomic_check] No valid intermediate pipe watermarks are possible
[drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22
and a boatload of subsequent modeset BAT fails on my ILK.
Cc: Matt Roper
Cc: Maarten Lankhorst
Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming
(v11)")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a08c4a45b8d3..938653063f15 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12003,6 +12003,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
DRM_DEBUG_KMS("No valid intermediate pipe watermarks
are possible\n");
return ret;
}
+ } else if (dev_priv->display.compute_intermediate_wm) {
+ if (HAS_PCH_SPLIT(dev_priv) && INTEL_GEN(dev_priv) < 9)
+ pipe_config->wm.intermediate =
pipe_config->wm.optimal.ilk;
}
if (INTEL_INFO(dev)->gen >= 9) {
@@ -15991,6 +15994,9 @@ retry:
state->acquire_ctx = &ctx;
+ /* ignore any reset values/BIOS leftovers in the WM registers */
+ to_intel_atomic_state(state)->skip_intermediate_wm = true;
+
for_each_crtc_in_state(state, crtc, crtc_state, i) {
/*
* Force recalculation even if we restore
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Don't leave old junk in ilk active watermarks on readout
From: Ville Syrjälä
When we read out the watermark state from the hardware we're supposed to
transfer that into the active watermarks, but currently we fail to any
part of the active watermarks that isn't explicitly written. Let's clear
it all upfront.
Looks like this has been like this since the beginning, when I added the
readout. No idea why I didn't clear it up.
Cc: Matt Roper
Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in
intel_modeset_setup_hw_state()")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1bb0f9ac104c..17c9f9865a18 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3904,6 +3904,8 @@ static void ilk_pipe_wm_get_hw_state(struct drm_crtc
*crtc)
if (IS_HASWELL(dev) || IS_BROADWELL(dev))
hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
+ memset(active, 0, sizeof(*active));
+
active->pipe_enabled = intel_crtc->active;
if (active->pipe_enabled) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] drm/i915: Fix for resume regression in ilk-bdw due to watermarks
From: Ville Syrjälä My ILK was very unhappy runnin BAT tests. Caused by watermark fail during resume. Here's the smallest fix I thought of. Ville Syrjälä (2): drm/i915: Don't leave old junk in ilk active watermarks on readout drm/i915: Ignore stale wm register values on resume on ilk-bdw drivers/gpu/drm/i915/intel_display.c | 6 ++ drivers/gpu/drm/i915/intel_pm.c | 2 ++ 2 files changed, 8 insertions(+) Cc: Matt Roper -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools
On Fri, 13 May 2016, Chris Wilson wrote:
> On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
>>
>> On 13/05/16 15:04, Jani Nikula wrote:
>> >This is more robust for assignments and comparisons.
>> >
>> >Signed-off-by: Jani Nikula
>> >---
>> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> >b/drivers/gpu/drm/i915/i915_drv.h
>> >index d9d07b70f05c..bb0b6f64000e 100644
>> >--- a/drivers/gpu/drm/i915/i915_drv.h
>> >+++ b/drivers/gpu/drm/i915/i915_drv.h
>> >@@ -752,7 +752,7 @@ struct intel_csr {
>> >func(has_ddi) sep \
>> >func(has_fpga_dbg)
>> >
>> >-#define DEFINE_FLAG(name) u8 name:1
>> >+#define DEFINE_FLAG(name) bool name:1
>> > #define SEP_SEMICOLON ;
>> >
>> > struct intel_device_info {
>> >
>>
>> The churn virus spreads? :)
>>
>> I tried that but it was negatively impacting the compiler. For some
>> reason it increases .text by 2.5k here. Don't see anything obvious,
>> would have to look at the code more closely to spot exactly why.
>
> Oh, that's not fun. bool:1 holds such promise for a clear explanation of
> the most common form of bitfield.
Really a bummer, especially since assigning any positive even number to
unsigned int foo:1 will result in 0.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Rename struct dpll to struct intel_dpll
On Fri, May 13, 2016 at 05:14:58PM +0300, Ander Conselvan de Oliveira wrote:
> Prefix struct dpll with intel_ to follow the convention in the driver.
>
> Cc: Ville Syrjälä
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_ddi.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 76
> +--
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 10 ++---
> drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
> 7 files changed, 48 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7a0b513..5f9dda2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -577,7 +577,7 @@ struct intel_crtc_state;
> struct intel_initial_plane_config;
> struct intel_crtc;
> struct intel_limit;
> -struct dpll;
> +struct intel_dpll;
Now that I see that, it kinda makes me think someone is bould to
confuse it to mean an actual DPLL instead of just the dividers and
whanot.
>
> struct drm_i915_display_funcs {
> int (*get_display_clock_speed)(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index c454744..1387acd 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -948,7 +948,7 @@ static int bxt_calc_pll_link(struct drm_i915_private
> *dev_priv,
> {
> struct intel_shared_dpll *pll;
> struct intel_dpll_hw_state *state;
> - struct dpll clock;
> + struct intel_dpll clock;
>
> /* For DDI ports we always use a shared PLL. */
> if (WARN_ON(dpll == DPLL_ID_PRIVATE))
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 05c7533..048a5bf 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -578,7 +578,7 @@ static bool intel_pipe_will_have_type(const struct
> intel_crtc_state *crtc_state,
> * divided-down version of it.
> */
> /* m1 is reserved as 0 in Pineview, n is a ring counter */
> -static int pnv_calc_dpll_params(int refclk, struct dpll *clock)
> +static int pnv_calc_dpll_params(int refclk, struct intel_dpll *clock)
> {
> clock->m = clock->m2 + 2;
> clock->p = clock->p1 * clock->p2;
> @@ -590,12 +590,12 @@ static int pnv_calc_dpll_params(int refclk, struct dpll
> *clock)
> return clock->dot;
> }
>
> -static uint32_t i9xx_dpll_compute_m(struct dpll *dpll)
> +static uint32_t i9xx_dpll_compute_m(struct intel_dpll *dpll)
> {
> return 5 * (dpll->m1 + 2) + (dpll->m2 + 2);
> }
>
> -static int i9xx_calc_dpll_params(int refclk, struct dpll *clock)
> +static int i9xx_calc_dpll_params(int refclk, struct intel_dpll *clock)
> {
> clock->m = i9xx_dpll_compute_m(clock);
> clock->p = clock->p1 * clock->p2;
> @@ -607,7 +607,7 @@ static int i9xx_calc_dpll_params(int refclk, struct dpll
> *clock)
> return clock->dot;
> }
>
> -static int vlv_calc_dpll_params(int refclk, struct dpll *clock)
> +static int vlv_calc_dpll_params(int refclk, struct intel_dpll *clock)
> {
> clock->m = clock->m1 * clock->m2;
> clock->p = clock->p1 * clock->p2;
> @@ -619,7 +619,7 @@ static int vlv_calc_dpll_params(int refclk, struct dpll
> *clock)
> return clock->dot / 5;
> }
>
> -int chv_calc_dpll_params(int refclk, struct dpll *clock)
> +int chv_calc_dpll_params(int refclk, struct intel_dpll *clock)
> {
> clock->m = clock->m1 * clock->m2;
> clock->p = clock->p1 * clock->p2;
> @@ -640,7 +640,7 @@ int chv_calc_dpll_params(int refclk, struct dpll *clock)
>
> static bool intel_PLL_is_valid(struct drm_device *dev,
> const struct intel_limit *limit,
> -const struct dpll *clock)
> +const struct intel_dpll *clock)
> {
> if (clock->n < limit->n.min || limit->n.max < clock->n)
> INTELPllInvalid("n out of range\n");
> @@ -712,11 +712,11 @@ i9xx_select_p2_div(const struct intel_limit *limit,
> static bool
> i9xx_find_best_dpll(const struct intel_limit *limit,
> struct intel_crtc_state *crtc_state,
> - int target, int refclk, struct dpll *match_clock,
> - struct dpll *best_clock)
> + int target, int refclk, struct intel_dpll *match_clock,
> + struct intel_dpll *best_clock)
> {
> struct drm_device *dev = crtc_state->base.crtc->dev;
> - struct dpll clock;
> + struct intel_dpll clock;
> int err = target;
>
> memset(best_clock, 0, sizeof(*best_clock));
> @@ -769,11 +769,11 @@ i9xx_find_best_dpll(const struct intel_limit *limit,
> static bool
> pnv_find_best_dpll(const struct intel_limit *limit,
> struct intel_c
Re: [Intel-gfx] ✓ Ro.CI.BAT: success for Pre-calculate SKL-style atomic watermarks (final CI run) (rev2)
On Thu, May 12, 2016 at 10:52:11PM +, Patchwork wrote: > == Series Details == > > Series: Pre-calculate SKL-style atomic watermarks (final CI run) (rev2) > URL : https://patchwork.freedesktop.org/series/7075/ > State : success Maarten confirmed on IRC that his r-b stands for the updated version of patch #15, so pushed to dinq. CI was happy this time around, but on a previous iteration it complained about a sporadic BYT failure that we didn't seem to have a bugzilla for yet; I opened a new one at https://bugs.freedesktop.org/show_bug.cgi?id=95372 Matt > > == Summary == > > Series 7075v2 Pre-calculate SKL-style atomic watermarks (final CI run) > http://patchwork.freedesktop.org/api/1.0/series/7075/revisions/2/mbox > > Test kms_flip: > Subgroup basic-flip-vs-wf_vblank: > fail -> PASS (ro-hsw-i7-4770r) > > ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 > ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 > ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 > ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 > ro-byt-n2820 total:218 pass:175 dwarn:0 dfail:0 fail:2 skip:41 > ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 > ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 > ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 > ro-ilk1-i5-650 total:214 pass:151 dwarn:0 dfail:0 fail:2 skip:61 > ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 > ro-ivb2-i7-3770 total:219 pass:186 dwarn:0 dfail:0 fail:1 skip:32 > ro-skl-i7-6700hq total:214 pass:190 dwarn:0 dfail:0 fail:0 skip:24 > ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 > > Results at /archive/results/CI_IGT_test/RO_Patchwork_876/ > > a6ac4ab drm-intel-nightly: 2016y-05m-12d-15h-37m-38s UTC integration manifest > 1096cb7 drm/i915: Remove wm_config from dev_priv/intel_atomic_state > 053fa3d drm/i915/gen9: Reject display updates that exceed wm limitations (v2) > 73fcc6d drm/i915/gen9: Calculate watermarks during atomic 'check' (v2) > 616a9e9 drm/i915/gen9: Propagate watermark calculation failures up the call > chain > 9941f42 drm/i915/gen9: Use a bitmask to track dirty pipe watermarks > ea3f449 drm/i915/gen9: Allow watermark calculation on in-flight atomic state > (v3) > 7ba9a23 drm/i915/gen9: Calculate plane WM's from state > fe3a3bf drm/i915/gen9: Drop re-allocation of DDB at atomic commit (v2) > 7e4426f drm/i915/gen9: Compute DDB allocation at atomic check time (v4) > f769eb6 drm/i915: Add distrust_bios_wm flag to dev_priv (v2) > 94af186 drm/i915/gen9: Allow skl_allocate_pipe_ddb() to operate on in-flight > state (v3) > 4499d87 drm/i915: Track whether an atomic transaction changes the active > CRTC's > 0e5fa43 drm/i915/gen9: Store plane minimum blocks in CRTC wm state (v2) > 0979389 drm/i915/gen9: Allow calculation of data rate for in-flight state (v2) > d0b9477 drm/i915/gen9: Cache plane data rates in CRTC state > 77c1d12 drm/i915: Rename s/skl_compute_pipe_wm/skl_build_pipe_wm/ > d9d40b7 drm/i915: Reorganize WM structs/unions in CRTC state > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/7] Enable GuC submission
This patchset covers various GuC-related changes, but most important of
these are (1) splitting the original "enable_guc_submission" parameter
into separate flags for loading GuC firmware vs. using the GuC for job
submission [PATCH 3/7], and (2) actually enabling GuC submission by
default on suitable platforms [PATCH 7/7].
Dave Gordon (7):
drm/i915/guc: rename loader entry points
drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED
drm/i915/guc: add enable_guc_loading parameter
drm/i915/guc: pass request (not client) to
i915_guc_{wq_check_space,submit}()
drm/i915/guc: don't spinwait if the GuC's workqueue is full
drm/i915/guc: rework guc_add_workqueue_item()
drm/i915/guc: change default to using GuC submission if possible
drivers/gpu/drm/i915/i915_debugfs.c| 1 +
drivers/gpu/drm/i915/i915_dma.c| 6 +-
drivers/gpu/drm/i915/i915_drv.h| 10 ++-
drivers/gpu/drm/i915/i915_gem.c| 5 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 137 +
drivers/gpu/drm/i915/i915_params.c | 14 ++-
drivers/gpu/drm/i915/i915_params.h | 3 +-
drivers/gpu/drm/i915/intel_guc.h | 35 +---
drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 127 ++
drivers/gpu/drm/i915/intel_lrc.c | 9 +-
drivers/gpu/drm/i915/intel_pm.c| 2 +-
drivers/gpu/drm/i915/intel_uncore.c| 2 +-
13 files changed, 207 insertions(+), 147 deletions(-)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 6/7] drm/i915/guc: rework guc_add_workqueue_item()
Mostly little optimisations and future-proofing against code breakage.
For instance, if the driver is correctly following the submission
protocol, the "out of space" condition is impossible, so the previous
runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic
effect in development and less impact in end-user systems.
Similarly we can make alignment checking more stringent and replace
other WARN_ON() conditions that don't relate to the runtime hardware
state with either BUILD_BUG_ON() for compile-time-detectable issues, or
GEM_BUG_ON() for logical "can't happen" errors.
With those changes, we can convert it to void, as suggested by Chris
Wilson, and update the calling code appropriately.
v2:
Note that we're now putting the request seqno in the "fence_id"
field of each GuC-work-item, in case it turns up somewhere useful
(e.g. in a GuC log) [Tvrtko Ursulin].
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 71 +++---
drivers/gpu/drm/i915/intel_guc.h | 2 +-
drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +-
3 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 85b2b89..42a8508 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -486,23 +486,28 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request
*request)
return -EAGAIN;
}
-static int guc_add_workqueue_item(struct i915_guc_client *gc,
- struct drm_i915_gem_request *rq)
+static void guc_add_workqueue_item(struct i915_guc_client *gc,
+ struct drm_i915_gem_request *rq)
{
+ /* wqi_len is in DWords, and does not include the one-word header */
+ const size_t wqi_size = sizeof(struct guc_wq_item);
+ const u32 wqi_len = wqi_size/sizeof(u32) - 1;
struct guc_process_desc *desc;
struct guc_wq_item *wqi;
void *base;
- u32 tail, wq_len, wq_off, space;
+ u32 freespace, tail, wq_off, wq_page;
desc = gc->client_base + gc->proc_desc_offset;
- space = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
- if (WARN_ON(space < sizeof(struct guc_wq_item)))
- return -ENOSPC; /* shouldn't happen */
- /* postincrement WQ tail for next time */
- wq_off = gc->wq_tail;
- gc->wq_tail += sizeof(struct guc_wq_item);
- gc->wq_tail &= gc->wq_size - 1;
+ /* Free space is guaranteed, see i915_guc_wq_check_space() above */
+ freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
+ GEM_BUG_ON(freespace < wqi_size);
+
+ /* The GuC firmware wants the tail index in QWords, not bytes */
+ tail = rq->tail;
+ GEM_BUG_ON(tail & 7);
+ tail >>= 3;
+ GEM_BUG_ON(tail > WQ_RING_TAIL_MAX);
/* For now workqueue item is 4 DWs; workqueue buffer is 2 pages. So we
* should not have the case where structure wqi is across page, neither
@@ -511,19 +516,23 @@ static int guc_add_workqueue_item(struct i915_guc_client
*gc,
* XXX: if not the case, we need save data to a temp wqi and copy it to
* workqueue buffer dw by dw.
*/
- WARN_ON(sizeof(struct guc_wq_item) != 16);
- WARN_ON(wq_off & 3);
+ BUILD_BUG_ON(wqi_size != 16);
+
+ /* postincrement WQ tail for next time */
+ wq_off = gc->wq_tail;
+ gc->wq_tail += wqi_size;
+ gc->wq_tail &= gc->wq_size - 1;
+ GEM_BUG_ON(wq_off & (wqi_size - 1));
- /* wq starts from the page after doorbell / process_desc */
- base = kmap_atomic(i915_gem_object_get_page(gc->client_obj,
- (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT));
+ /* WQ starts from the page after doorbell / process_desc */
+ wq_page = (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT;
wq_off &= PAGE_SIZE - 1;
+ base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, wq_page));
wqi = (struct guc_wq_item *)((char *)base + wq_off);
- /* len does not include the header */
- wq_len = sizeof(struct guc_wq_item) / sizeof(u32) - 1;
+ /* Now fill in the 4-word work queue item */
wqi->header = WQ_TYPE_INORDER |
- (wq_len << WQ_LEN_SHIFT) |
+ (wqi_len << WQ_LEN_SHIFT) |
(rq->engine->guc_id << WQ_TARGET_SHIFT) |
WQ_NO_WCFLUSH_WAIT;
@@ -531,14 +540,10 @@ static int guc_add_workqueue_item(struct i915_guc_client
*gc,
wqi->context_desc = (u32)intel_lr_context_descriptor(rq->ctx,
rq->engine);
- /* The GuC firmware wants the tail index in QWords, not bytes */
- tail = rq->ringbuf->tail >> 3;
wqi->ring_tail = tail << WQ_RING_TAIL_SHIFT;
- wqi->fence_i
[Intel-gfx] [PATCH v4 7/7] drm/i915/guc: change default to using GuC submission if possible
This patch simply changes the default value of "enable_guc_submission"
from 0 (never) to -1 (auto). This means that GuC submission will be
used if the platform has a GuC, the GuC supports the request submission
protocol, and any required GuC firmwware was successfully loaded. If any
of these conditions are not met, the driver will fall back to using
execlist mode.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 6a5578c..573e787 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,7 +55,7 @@ struct i915_params i915 __read_mostly = {
.nuclear_pageflip = 0,
.edp_vswing = 0,
.enable_guc_loading = -1,
- .enable_guc_submission = 0,
+ .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -207,7 +207,7 @@ struct i915_params i915 __read_mostly = {
module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
int, 0400);
MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
- "(-1=auto, 0=never [default], 1=if available, 2=required)");
+ "(-1=auto [default], 0=never, 1=if available, 2=required)");
module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
MODULE_PARM_DESC(guc_log_level,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/7] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED
For now, anything with a GuC requires uCode loading, and then supports
command submission once loaded. But these are logically distinct from
simply "having a GuC", so we need a separate macro for the latter. Then,
various tests should use this new macro rather than HAS_GUC_UCODE() or
testing enable_guc_submission.
v4:
Added a couple more uses of the new macro.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
4 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b7..3b9ee51 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2726,8 +2726,14 @@ struct drm_i915_cmd_table {
#define HAS_CSR(dev) (IS_GEN9(dev))
-#define HAS_GUC_UCODE(dev) (IS_GEN9(dev) && !IS_KABYLAKE(dev))
-#define HAS_GUC_SCHED(dev) (IS_GEN9(dev) && !IS_KABYLAKE(dev))
+/*
+ * For now, anything with a GuC requires uCode loading, and then supports
+ * command submission once loaded. But these are logically independent
+ * properties, so we have separate macros to test them.
+ */
+#define HAS_GUC(dev) (IS_GEN9(dev) && !IS_KABYLAKE(dev))
+#define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
+#define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 43e45b7..2a7be71 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4866,7 +4866,7 @@ int i915_gem_init_engines(struct drm_device *dev)
intel_mocs_init_l3cc_table(dev);
/* We can't enable contexts until all firmware is loaded */
- if (HAS_GUC_UCODE(dev)) {
+ if (HAS_GUC(dev)) {
ret = intel_guc_setup(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1bb0f9a..c584282 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4844,7 +4844,7 @@ static void gen9_enable_rc6(struct drm_i915_private
*dev_priv)
for_each_engine(engine, dev_priv)
I915_WRITE(RING_MAX_IDLE(engine->mmio_base), 10);
- if (HAS_GUC_UCODE(dev_priv))
+ if (HAS_GUC(dev_priv))
I915_WRITE(GUC_MAX_IDLE_COUNT, 0xA);
I915_WRITE(GEN6_RC_SLEEP, 0);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 385114b..c1ca458 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1715,7 +1715,7 @@ int intel_guc_reset(struct drm_i915_private *dev_priv)
int ret;
unsigned long irqflags;
- if (!i915.enable_guc_submission)
+ if (!HAS_GUC(dev_priv))
return -EINVAL;
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/7] drm/i915/guc: add enable_guc_loading parameter
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.
In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
-1 (default) whatever the platform default is
0 DISABLE don't load/use the GuC
1 BEST EFFORT try to load/use the GuC, fallback if not available
2 REQUIRE must load/use the GuC, else leave the GPU wedged
The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.
v4:
Changed some error-message levels, mostly ERROR->INFO, per
review comments by Tvrtko Ursulin.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c| 1 -
drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
drivers/gpu/drm/i915/i915_params.c | 14 +++-
drivers/gpu/drm/i915/i915_params.h | 3 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 108 -
5 files changed, 76 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2a7be71..2bf8743 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4870,7 +4870,6 @@ int i915_gem_init_engines(struct drm_device *dev)
ret = intel_guc_setup(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
- ret = -EIO;
goto out;
}
}
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 169242a..916cd67 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -969,7 +969,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
- if (!i915.enable_guc_submission)
+ if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
ctx = dev_priv->kernel_context;
@@ -995,7 +995,7 @@ int intel_guc_resume(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
- if (!i915.enable_guc_submission)
+ if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 383c076..6a5578c 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -54,7 +54,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_submission = false,
+ .enable_guc_loading = -1,
+ .enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -198,8 +199,15 @@ struct i915_params i915 __read_mostly = {
"(0=use value from vbt [default], 1=low power swing(200mV),"
"2=default swing(400mV))");
-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int,
0400);
+MODULE_PARM_DESC(enable_guc_loading,
+ "Enable GuC firmware loading "
+ "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+ "Enable GuC submission "
+ "(-1=auto, 0=never [default], 1=if available, 2=required)");
module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 65e73dd..1323261 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,8 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+ int enable_guc_loading;
+ int enable_guc_submission;
int guc_log_level;
int use_mmio_flip;
int mmio_debug;
@@ -57,7 +59,6 @@ struct i915_params {
bool load_detect_test;
bool reset;
bool disable_display;
- bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
bool enable_dp_mst;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc
[Intel-gfx] [PATCH v4 5/7] drm/i915/guc: don't spinwait if the GuC's workqueue is full
Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)
We'll also add a counter to the GuC client statistics, to see how often
we find the WQ full.
v2:
Flag the likely() code path (Tvtrko Ursulin).
v4:
Add/update comments about failure counters (Tvtrko Ursulin).
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 1 +
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
drivers/gpu/drm/i915/intel_guc.h | 22 --
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 24f4105..de05841 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2506,6 +2506,7 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
client->wq_size, client->wq_offset, client->wq_tail);
+ seq_printf(m, "\tWork queue full: %u\n", client->no_wq_space);
seq_printf(m, "\tFailed to queue: %u\n", client->q_fail);
seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
seq_printf(m, "\tLast submission result: %d\n", client->retcode);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 87cb739..85b2b89 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -468,26 +468,22 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
*/
int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
{
- const size_t size = sizeof(struct guc_wq_item);
+ const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
struct guc_process_desc *desc;
- int ret = -ETIMEDOUT, timeout_counter = 200;
+ u32 freespace;
GEM_BUG_ON(gc == NULL);
desc = gc->client_base + gc->proc_desc_offset;
- while (timeout_counter-- > 0) {
- if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) {
- ret = 0;
- break;
- }
+ freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
+ if (likely(freespace >= wqi_size))
+ return 0;
- if (timeout_counter)
- usleep_range(1000, 2000);
- };
+ gc->no_wq_space += 1;
- return ret;
+ return -EAGAIN;
}
static int guc_add_workqueue_item(struct i915_guc_client *gc,
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 91f315c..380a743 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -48,9 +48,18 @@ struct drm_i915_gem_request;
* queue (a circular array of work items), again described in the process
* descriptor. Work queue pages are mapped momentarily as required.
*
- * Finally, we also keep a few statistics here, including the number of
- * submissions to each engine, and a record of the last submission failure
- * (if any).
+ * We also keep a few statistics on failures. Ideally, these should all
+ * be zero!
+ * no_wq_space: times that the submission pre-check found no space was
+ *available in the work queue (note, the queue is shared,
+ *not per-engine). It is OK for this to be nonzero, but
+ *it should not be huge!
+ * q_fail: failed to enqueue a work item. This should never happen,
+ * because we check for space beforehand.
+ * b_fail: failed to ring the doorbell. This should never happen, unless
+ * somehow the hardware misbehaves, or maybe if the GuC firmware
+ * crashes? We probably need to reset the GPU to recover.
+ * retcode: errno from last guc_submit()
*/
struct i915_guc_client {
struct drm_i915_gem_object *client_obj;
@@ -71,12 +80,13 @@ struct i915_guc_client {
uint32_t wq_tail;
uint32_t unused;/* Was 'wq_head'*/
- /* GuC submission statistics & status */
- uint64_t submissions[GUC_MAX_ENGINES_NUM];
+ uint32_t no_wq_space;
uint32_t q_fail;
uint32_t b_fail;
int retcode;
- int spare; /* pad to 32 DWords */
+
+ /* Per-engine counts of GuC submissions */
+ uint64_t submissions[GUC_MAX_ENGINES_NUM];
};
enum intel_guc_fw_status {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/7] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()
The knowledge of how to derive the relevant client from the request
should be localised within i915_guc_submission.c; the LRC code shouldn't
have to know about the internal details of the GuC submission process.
And all the information the GuC code needs should be encapsulated in (or
reachable from) the request.
v2:
GEM_BUG_ON() for bad GuC client (Tvrtko Ursulin).
Add/update kerneldoc explaining check_space/submit protocol
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 46 --
drivers/gpu/drm/i915/intel_guc.h | 5 ++--
drivers/gpu/drm/i915/intel_lrc.c | 9 ++
3 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 916cd67..87cb739 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -450,14 +450,30 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
sizeof(desc) * client->ctx_index);
}
-int i915_guc_wq_check_space(struct i915_guc_client *gc)
+/**
+ * i915_guc_wq_check_space() - check that the GuC can accept a request
+ * @request: request associated with the commands
+ *
+ * Return: 0 if space is available
+ * -EAGAIN if space is not currently available
+ *
+ * This function must be called (and must return 0) before a request
+ * is submitted to the GuC via i915_guc_submit() below. Once a result
+ * of 0 has been returned, it remains valid until (but only until)
+ * the next call to submit().
+ *
+ * This precheck allows the caller to determine in advance that space
+ * will be available for the next submission before committing resources
+ * to it, and helps avoid late failures with complicated recovery paths.
+ */
+int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
{
+ const size_t size = sizeof(struct guc_wq_item);
+ struct i915_guc_client *gc = request->i915->guc.execbuf_client;
struct guc_process_desc *desc;
- u32 size = sizeof(struct guc_wq_item);
int ret = -ETIMEDOUT, timeout_counter = 200;
- if (!gc)
- return 0;
+ GEM_BUG_ON(gc == NULL);
desc = gc->client_base + gc->proc_desc_offset;
@@ -531,16 +547,28 @@ static int guc_add_workqueue_item(struct i915_guc_client
*gc,
/**
* i915_guc_submit() - Submit commands through GuC
- * @client:the guc client where commands will go through
* @rq:request associated with the commands
*
- * Return: 0 if succeed
+ * Return: 0 on success, otherwise an errno.
+ * (Note: nonzero really shouldn't happen!)
+ *
+ * The caller must have already called i915_guc_wq_check_space() above
+ * with a result of 0 (success) since the last request submission. This
+ * guarantees that there is space in the work queue for the new request,
+ * so enqueuing the item cannot fail.
+ *
+ * Bad Things Will Happen if the caller violates this protocol e.g. calls
+ * submit() when check() says there's no space, or calls submit() multiple
+ * times with no intervening check().
+ *
+ * The only error here arises if the doorbell hardware isn't functioning
+ * as expected, which really shouln't happen.
*/
-int i915_guc_submit(struct i915_guc_client *client,
- struct drm_i915_gem_request *rq)
+int i915_guc_submit(struct drm_i915_gem_request *rq)
{
- struct intel_guc *guc = client->guc;
unsigned int engine_id = rq->engine->guc_id;
+ struct intel_guc *guc = &rq->i915->guc;
+ struct i915_guc_client *client = guc->execbuf_client;
int q_ret, b_ret;
q_ret = guc_add_workqueue_item(client, rq);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3984136..91f315c 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -148,10 +148,9 @@ extern int intel_guc_resume(struct drm_device *dev);
/* i915_guc_submission.c */
int i915_guc_submission_init(struct drm_device *dev);
int i915_guc_submission_enable(struct drm_device *dev);
-int i915_guc_submit(struct i915_guc_client *client,
- struct drm_i915_gem_request *rq);
+int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
+int i915_guc_submit(struct drm_i915_gem_request *rq);
void i915_guc_submission_disable(struct drm_device *dev);
void i915_guc_submission_fini(struct drm_device *dev);
-int i915_guc_wq_check_space(struct i915_guc_client *client);
#endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index db10c96..c0bd3db 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -698,9 +698,7 @@ int intel_logical_ring_alloc_request_extras(struct
drm_i915_gem_request *request
* going any further, as the i915_add_request() call
* later on
[Intel-gfx] [PATCH v4 1/7] drm/i915/guc: rename loader entry points
The GuC initialisation code could do other things apart from loading
firmware, so here we rename the three primary entry points to remove any
specific reference to "ucode" (no functional changes, just renaming).
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/intel_guc.h| 6 +++---
drivers/gpu/drm/i915/intel_guc_loader.c | 19 ++-
4 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 547100f..7d93f8f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -507,7 +507,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
* working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
- intel_guc_ucode_init(dev);
+ intel_guc_init(dev);
ret = i915_gem_init(dev);
if (ret)
@@ -547,7 +547,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
cleanup_gem:
i915_gem_fini(dev);
cleanup_irq:
- intel_guc_ucode_fini(dev);
+ intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
cleanup_csr:
@@ -1528,7 +1528,7 @@ int i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
flush_workqueue(dev_priv->wq);
- intel_guc_ucode_fini(dev);
+ intel_guc_fini(dev);
i915_gem_fini(dev);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a3d826b..43e45b7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4867,7 +4867,7 @@ int i915_gem_init_engines(struct drm_device *dev)
/* We can't enable contexts until all firmware is loaded */
if (HAS_GUC_UCODE(dev)) {
- ret = intel_guc_ucode_load(dev);
+ ret = intel_guc_setup(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
ret = -EIO;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9d79c4c..3984136 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -138,9 +138,9 @@ struct intel_guc {
};
/* intel_guc_loader.c */
-extern void intel_guc_ucode_init(struct drm_device *dev);
-extern int intel_guc_ucode_load(struct drm_device *dev);
-extern void intel_guc_ucode_fini(struct drm_device *dev);
+extern void intel_guc_init(struct drm_device *dev);
+extern int intel_guc_setup(struct drm_device *dev);
+extern void intel_guc_fini(struct drm_device *dev);
extern const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status);
extern int intel_guc_suspend(struct drm_device *dev);
extern int intel_guc_resume(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 23345e1..b14a3a3 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -375,18 +375,19 @@ static int i915_reset_guc(struct drm_i915_private
*dev_priv)
}
/**
- * intel_guc_ucode_load() - load GuC uCode into the device
+ * intel_guc_setup() - finish preparing the GuC for activity
* @dev: drm device
*
* Called from gem_init_hw() during driver loading and also after a GPU reset.
*
+ * The main action required here it to load the GuC uCode into the device.
* The firmware image should have already been fetched into memory by the
- * earlier call to intel_guc_ucode_init(), so here we need only check that
- * is succeeded, and then transfer the image to the h/w.
+ * earlier call to intel_guc_init(), so here we need only check that worked,
+ * and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
-int intel_guc_ucode_load(struct drm_device *dev)
+int intel_guc_setup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
@@ -620,15 +621,15 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
}
/**
- * intel_guc_ucode_init() - define parameters and fetch firmware
+ * intel_guc_init() - define parameters and fetch firmware
* @dev: drm device
*
* Called early during driver load, but after GEM is initialised.
*
* The firmware will be transferred to the GuC's memory later,
- * when intel_guc_ucode_load() is called.
+ * when intel_guc_setup() is called.
*/
-void intel_guc_ucode_init(struct drm_device *dev)
+void intel_guc_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
@@ -676,10 +677,10 @@ void intel_guc_ucode_init(struct drm_device *dev)
}
/**
- * intel_guc_ucode_fini() - cl
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter
On 10/05/16 15:37, Tvrtko Ursulin wrote:
On 06/05/16 17:39, Dave Gordon wrote:
On 29/04/16 16:03, Tvrtko Ursulin wrote:
[snip]
+goto fail;
+if (fw_path == NULL)
+goto fail;
+if (*fw_path == '\0') {
+DRM_ERROR("No GuC firmware known for this platform\n");
It is not an error unless i915.enable_guc_loading == 2, no? And if best
effort then it is probably debug or informational.
No, it's still an ERROR. You're running the driver on a platform for
which we don't know what firmware is required. That probably means an
old driver on new hardware, so it might not work at all. You can
suppress the error by setting i915.enable_guc_loading=0 if you want to
try this version of the driver anyway. Also note the difference between
path == NULL (no GuC, or no firmware required => not an error) vs. path
== "" (has GuC, presumably needs firmware, but we don't know where to
look => ERROR).
I think that if i915.enable_guc_loading == 1 then no error should be
logged. Documentation says that value meand "try to load/use the GuC,
fallback if not available" and to me that means it is not an error and
an informational message only should be logged.
OK, this message is now DRM_INFO
Also, don't the checks against fw_path (together with the error or debug
message) belong in the fw fetch function? If they are invalid fw fetch
would have failed and this function would be able to inspect the high
level status of that step here, no?
The checks are done in intel_guc_ucode_init(), before fw_fetch() is even
called; but that function is void, so can't return failure. (Also, we
originally supported asynchronous loading, which also can't return
failure). So this function will get called even when we already know
that we haven't got any firmware to load, and these tests are indeed
checking the high-level status from _init().
Anyhow the special meanings conveyed in fw_path == NULL and *fw_path ==
0 are imho just too hard to follow. I see it is not your code, but
reworking this looked like an opportunity to clean that up. Never mind.
For fw_path:
== NULL means no firmware needed, not an error.
== ""means the driver actually doesn't know what to load in this
situation - the hardware is not recognised. IMHO this should
be an ERROR, but I've made it just informational now.
== path the file we want.
Those are the only three possibilities, it's set just once according the
hardware type and is constant thereafter. It doesn't depend on the
actual load status. That really isn't very complicated.
+goto fail;
+}
-if (guc_fw->guc_fw_fetch_status == GUC_FIRMWARE_NONE)
-return 0;
+/* Fetch failed, or already fetched but failed to load? */
+if (guc_fw->guc_fw_fetch_status != GUC_FIRMWARE_SUCCESS)
+goto fail;
+if (guc_fw->guc_fw_load_status == GUC_FIRMWARE_FAIL)
+goto fail;
Leads back to the question of load status in this function. So it is
expected we always enter here with load status of none? Is it possible
to get here with the firmware already loaded already?
Not *actually* loaded, because it's been erased by poweroff. But the
status tracking variables are persistent, so they reflect the last
attempt. So on resume, we actually expect "SUCCESS" at this point, and
therefore change it back to PENDING below.
Shouldn't the code then update the status variables on suspend/whatever?
Same as above, I find it very hard to follow the logic here.
It proceeds by identifying all the ways in which the loading process can
fail; what's left must be The Path To Success (tm) :)
1. Loading forbidden => fail
2. No firmware wanted => fail
3. No firmware known => fail
4. Firmware not fetched => fail
5. Previous load failed => fail
At this point we commit to trying to load the firmware into the h/w.
Then we try three times to reset-and-load the GuC.
-if (guc_fw->guc_fw_fetch_status == GUC_FIRMWARE_SUCCESS &&
-guc_fw->guc_fw_load_status == GUC_FIRMWARE_FAIL)
-return -ENOEXEC;
+direct_interrupts_to_host(dev_priv);
guc_fw->guc_fw_load_status = GUC_FIRMWARE_PENDING;
-DRM_DEBUG_DRIVER("GuC fw fetch status %s\n",
-intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
-
-switch (guc_fw->guc_fw_fetch_status) {
-case GUC_FIRMWARE_FAIL:
-/* something went wrong :( */
-err = -EIO;
-goto fail;
-
-case GUC_FIRMWARE_NONE:
-case GUC_FIRMWARE_PENDING:
-default:
-/* "can't happen" */
-WARN_ONCE(1, "GuC fw %s invalid guc_fw_fetch_status %s
[%d]\n",
-guc_fw->guc_fw_path,
-intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
-guc_fw->guc_fw_fetch_status);
-err = -ENXIO;
-goto fail;
-
-case GUC_FIRMWARE_SUCCESS:
-break;
-}
Look how many lines of complicated logic this patch removes :)
+DRM_DEBUG_DRIVER("GuC fw status: fetch %s, load %s\n",
+intel_guc_fw_status_r
Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools
On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
>
> On 13/05/16 15:04, Jani Nikula wrote:
> >This is more robust for assignments and comparisons.
> >
> >Signed-off-by: Jani Nikula
> >---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index d9d07b70f05c..bb0b6f64000e 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -752,7 +752,7 @@ struct intel_csr {
> > func(has_ddi) sep \
> > func(has_fpga_dbg)
> >
> >-#define DEFINE_FLAG(name) u8 name:1
> >+#define DEFINE_FLAG(name) bool name:1
> > #define SEP_SEMICOLON ;
> >
> > struct intel_device_info {
> >
>
> The churn virus spreads? :)
>
> I tried that but it was negatively impacting the compiler. For some
> reason it increases .text by 2.5k here. Don't see anything obvious,
> would have to look at the code more closely to spot exactly why.
Oh, that's not fun. bool:1 holds such promise for a clear explanation of
the most common form of bitfield.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Move CHV divider readout to intel_dpio_phy.c
On Fri, May 13, 2016 at 05:15:02PM +0300, Ander Conselvan de Oliveira wrote:
> Reading the dividers depends on sideband messaging, so it fits well if
> the other functions in intel_dpio_phy.c. The new function will also be
> used in a future patch.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 18 +-
> drivers/gpu/drm/i915/intel_dpio_phy.c | 24
> 3 files changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7dfa555..149317c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3630,6 +3630,8 @@ void chv_phy_post_pll_disable(struct intel_encoder
> *encoder);
> void chv_phy_prepare_pll(struct intel_crtc *crtc, u32 bestn,
>u32 bestm1, u32 bestm2, u32 bestp1, u32 bestp2,
>int vco);
> +void chv_phy_read_dividers(struct drm_i915_private *dev_priv,
> +enum pipe pipe, struct intel_dpll *clock);
_pll_dividers() again?
>
> void vlv_set_phy_signal_level(struct intel_encoder *encoder,
> u32 demph_reg_value, u32 preemph_reg_value,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8d61263..5ba000a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7892,30 +7892,14 @@ static void chv_crtc_clock_get(struct intel_crtc
> *crtc,
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> int pipe = pipe_config->cpu_transcoder;
> - enum dpio_channel port = vlv_pipe_to_channel(pipe);
> struct intel_dpll clock;
> - u32 cmn_dw13, pll_dw0, pll_dw1, pll_dw2, pll_dw3;
> int refclk = 10;
>
> /* In case of DSI, DPLL will not be used */
> if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
> return;
>
> - mutex_lock(&dev_priv->sb_lock);
> - cmn_dw13 = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW13(port));
> - pll_dw0 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW0(port));
> - pll_dw1 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW1(port));
> - pll_dw2 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW2(port));
> - pll_dw3 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW3(port));
> - mutex_unlock(&dev_priv->sb_lock);
> -
> - clock.m1 = (pll_dw1 & 0x7) == DPIO_CHV_M1_DIV_BY_2 ? 2 : 0;
> - clock.m2 = (pll_dw0 & 0xff) << 22;
> - if (pll_dw3 & DPIO_CHV_FRAC_DIV_EN)
> - clock.m2 |= pll_dw2 & 0x3f;
> - clock.n = (pll_dw1 >> DPIO_CHV_N_DIV_SHIFT) & 0xf;
> - clock.p1 = (cmn_dw13 >> DPIO_CHV_P1_DIV_SHIFT) & 0x7;
> - clock.p2 = (cmn_dw13 >> DPIO_CHV_P2_DIV_SHIFT) & 0x1f;
> + chv_phy_read_dividers(dev_priv, pipe, &clock);
>
> pipe_config->port_clock = chv_calc_dpll_params(refclk, &clock);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index d28ef9f..2a5d333 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -461,6 +461,30 @@ void chv_phy_prepare_pll(struct intel_crtc *crtc, u32
> bestn,
> mutex_unlock(&dev_priv->sb_lock);
> }
>
> +void chv_phy_read_dividers(struct drm_i915_private *dev_priv,
> +enum pipe pipe, struct intel_dpll *clock)
> +{
> + enum dpio_channel port = vlv_pipe_to_channel(pipe);
> + u32 cmn_dw13, pll_dw0, pll_dw1, pll_dw2, pll_dw3;
> +
> + mutex_lock(&dev_priv->sb_lock);
> + cmn_dw13 = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW13(port));
> + pll_dw0 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW0(port));
> + pll_dw1 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW1(port));
> + pll_dw2 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW2(port));
> + pll_dw3 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW3(port));
> + mutex_unlock(&dev_priv->sb_lock);
> +
> + clock->m1 = (pll_dw1 & 0x7) == DPIO_CHV_M1_DIV_BY_2 ? 2 : 0;
> + clock->m2 = (pll_dw0 & 0xff) << 22;
> + if (pll_dw3 & DPIO_CHV_FRAC_DIV_EN)
> + clock->m2 |= pll_dw2 & 0x3f;
> + clock->n = (pll_dw1 >> DPIO_CHV_N_DIV_SHIFT) & 0xf;
> + clock->p1 = (cmn_dw13 >> DPIO_CHV_P1_DIV_SHIFT) & 0x7;
> + clock->p2 = (cmn_dw13 >> DPIO_CHV_P2_DIV_SHIFT) & 0x1f;
> +}
> +
> +
> void vlv_set_phy_signal_level(struct intel_encoder *encoder,
> u32 demph_reg_value, u32 preemph_reg_value,
> u32 uniqtranscale_reg_value, u32 tx3_demph)
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
[Intel-gfx] [CI 1/4] drm/i915: Add distinct stubs for PM hibernation phases
Currently for handling the extra hibernation phases we just call the
equivalent suspend/resume phases. In the next couple of patches, I wish
to specialise the hibernation phases to reduce the amount of work
required for handling GEM objects.
v2: There are more! Don't forget the freeze phases.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5ae79601335c..6a2e7f84276b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1115,6 +1115,39 @@ static int i915_pm_resume(struct device *dev)
return i915_drm_resume(drm_dev);
}
+/* freeze: before creating the hibernation_image */
+static int i915_pm_freeze(struct device *dev)
+{
+ return i915_pm_suspend(dev);
+}
+
+static int i915_pm_freeze_late(struct device *dev)
+{
+ return i915_pm_suspend_late(dev);
+}
+
+/* thaw: called after creating the hibernation image, but before turning off.
*/
+static int i915_pm_thaw_early(struct device *dev)
+{
+ return i915_pm_resume_early(dev);
+}
+
+static int i915_pm_thaw(struct device *dev)
+{
+ return i915_pm_resume(dev);
+}
+
+/* restore: called after loading the hibernation image. */
+static int i915_pm_restore_early(struct device *dev)
+{
+ return i915_pm_resume_early(dev);
+}
+
+static int i915_pm_restore(struct device *dev)
+{
+ return i915_pm_resume(dev);
+}
+
/*
* Save all Gunit registers that may be lost after a D3 and a subsequent
* S0i[R123] transition. The list of registers needing a save/restore is
@@ -1669,14 +1702,14 @@ static const struct dev_pm_ops i915_pm_ops = {
* @restore, @restore_early : called after rebooting and restoring the
*hibernation image [PMSG_RESTORE]
*/
- .freeze = i915_pm_suspend,
- .freeze_late = i915_pm_suspend_late,
- .thaw_early = i915_pm_resume_early,
- .thaw = i915_pm_resume,
+ .freeze = i915_pm_freeze,
+ .freeze_late = i915_pm_freeze_late,
+ .thaw_early = i915_pm_thaw_early,
+ .thaw = i915_pm_thaw,
.poweroff = i915_pm_suspend,
.poweroff_late = i915_pm_poweroff_late,
- .restore_early = i915_pm_resume_early,
- .restore = i915_pm_resume,
+ .restore_early = i915_pm_restore_early,
+ .restore = i915_pm_restore,
/* S0ix (via runtime suspend) event handlers */
.runtime_suspend = intel_runtime_suspend,
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/4] drm/i915: Lazily migrate the objects after hibernation
Now that we mark the object domains for having been restored from the
hibernation image, we not need to flush everything during resume and
can instead rely on the normal domain tracking to flush only when
required. The only caveat here are objects that are pinned for use by
the hardware, whose contents must be coherent for when the device
resumes reading from then (shortly afterwards with the driver assuming
the objects are in the correct domain).
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Tested-by: David Weinehall
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5fb14c835543..319f3b459b3e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3245,7 +3245,6 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
struct i915_ggtt *ggtt = &dev_priv->ggtt;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- bool flush;
i915_check_and_clear_faults(dev_priv);
@@ -3255,19 +3254,16 @@ void i915_gem_restore_gtt_mappings(struct drm_device
*dev)
/* Cache flush objects bound into GGTT and rebind them. */
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
- flush = false;
list_for_each_entry(vma, &obj->vma_list, obj_link) {
if (vma->vm != &ggtt->base)
continue;
WARN_ON(i915_vma_bind(vma, obj->cache_level,
PIN_UPDATE));
-
- flush = true;
}
- if (flush)
- i915_gem_clflush_object(obj, obj->pin_display);
+ if (obj->pin_display)
+ WARN_ON(i915_gem_object_set_to_gtt_domain(obj, false));
}
if (INTEL_INFO(dev)->gen >= 8) {
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] drm/i915: Skip clearing the GGTT on full-ppgtt systems
Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.
For aliasing-ppgtt, we could almost do the same except that we do allow
userspace access to the global-GTT via execbuf in order to workraound
some quirks of certain instructions. (This execbuf path is filtered out
with EINVAL on full-ppgtt.)
The most dramatic effect this will have will be during resume, as with
full-ppgtt the GGTT is only used sparingly.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Tested-by: David Weinehall
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 319f3b459b3e..7eab619a3eb2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2477,6 +2477,13 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
+static void nop_clear_range(struct i915_address_space *vm,
+ uint64_t start,
+ uint64_t length,
+ bool use_scratch)
+{
+}
+
static void gen8_ggtt_clear_range(struct i915_address_space *vm,
uint64_t start,
uint64_t length,
@@ -3072,14 +3079,17 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ret = ggtt_probe_common(dev, ggtt->size);
- ggtt->base.clear_range = gen8_ggtt_clear_range;
- if (IS_CHERRYVIEW(dev_priv))
- ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
- else
- ggtt->base.insert_entries = gen8_ggtt_insert_entries;
ggtt->base.bind_vma = ggtt_bind_vma;
ggtt->base.unbind_vma = ggtt_unbind_vma;
+ ggtt->base.clear_range = nop_clear_range;
+ if (!USES_FULL_PPGTT(dev_priv))
+ ggtt->base.clear_range = gen8_ggtt_clear_range;
+
+ ggtt->base.insert_entries = gen8_ggtt_insert_entries;
+ if (IS_CHERRYVIEW(dev_priv))
+ ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
+
return ret;
}
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/4] drm/i915: Update domain tracking for GEM objects on hibernation
When creating the hibernation image, the CPU will read the pages of all
objects and thus conflict with our domain tracking. We need to update
our domain tracking to accurately reflect the state on restoration.
v2: Perform the domain tracking inside freeze, before the image is
written, rather than upon restoration.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: David Weinehall
Reviewed-by: Joonas Lahtinen
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 12 +++-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 28
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6a2e7f84276b..dba03c026151 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1123,7 +1123,17 @@ static int i915_pm_freeze(struct device *dev)
static int i915_pm_freeze_late(struct device *dev)
{
- return i915_pm_suspend_late(dev);
+ int ret;
+
+ ret = i915_pm_suspend_late(dev);
+ if (ret)
+ return ret;
+
+ ret = i915_gem_freeze_late(dev_to_i915(dev));
+ if (ret)
+ return ret;
+
+ return 0;
}
/* thaw: called after creating the hibernation image, but before turning off.
*/
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b70f05c..593baa3e8da0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2961,6 +2961,8 @@ int i915_gem_wait_ioctl(struct drm_device *dev, void
*data,
void i915_gem_load_init(struct drm_device *dev);
void i915_gem_load_cleanup(struct drm_device *dev);
void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
+int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
+
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 a3d826bb216b..aff386eea8ce 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5051,6 +5051,34 @@ void i915_gem_load_cleanup(struct drm_device *dev)
kmem_cache_destroy(dev_priv->objects);
}
+int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
+{
+ struct drm_i915_gem_object *obj;
+
+ /* Called just before we write the hibernation image.
+*
+* We need to update the domain tracking to reflect that the CPU
+* will be accessing all the pages to create and restore from the
+* hibernation, and so upon restoration those pages will be in the
+* CPU domain.
+*
+* To make sure the hibernation image contains the latest state,
+* we update that state just before writing out the image.
+*/
+
+ list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list) {
+ obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+ }
+
+ list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
+ obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+ }
+
+ return 0;
+}
+
void i915_gem_release(struct drm_device *dev, struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Move toggling of CHV DPIO_DCLKP_EN to intel_dpio_phy.c
On Fri, May 13, 2016 at 05:15:03PM +0300, Ander Conselvan de Oliveira wrote:
> This simplifies the pll enable/disable a code a bit and hides the
> sideband message neatly in intel_dpio_phy.c.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 19 ++-
> drivers/gpu/drm/i915/intel_dpio_phy.c | 18 ++
> 3 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 149317c..44f4b7a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3630,6 +3630,8 @@ void chv_phy_post_pll_disable(struct intel_encoder
> *encoder);
> void chv_phy_prepare_pll(struct intel_crtc *crtc, u32 bestn,
>u32 bestm1, u32 bestm2, u32 bestp1, u32 bestp2,
>int vco);
> +void chv_phy_toggle_dclkp(struct drm_i915_private *dev_priv, enum pipe pipe,
> + bool enable);
Toggle makes me think it just flips the bit. _enable_dclkp()
_set_dclkp() or something might be better?
> void chv_phy_read_dividers(struct drm_i915_private *dev_priv,
> enum pipe pipe, struct intel_dpll *clock);
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5ba000a..d43bdff 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1574,17 +1574,9 @@ static void _chv_enable_pll(struct intel_crtc *crtc,
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
> - enum dpio_channel port = vlv_pipe_to_channel(pipe);
> - u32 tmp;
> -
> - mutex_lock(&dev_priv->sb_lock);
>
> /* Enable back the 10bit clock to display controller */
> - tmp = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW14(port));
> - tmp |= DPIO_DCLKP_EN;
> - vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), tmp);
> -
> - mutex_unlock(&dev_priv->sb_lock);
> + chv_phy_toggle_dclkp(dev_priv, pipe, true);
>
> /*
>* Need to wait > 100ns between dclkp clock enable bit and PLL enable.
> @@ -1777,7 +1769,6 @@ static void vlv_disable_pll(struct drm_i915_private
> *dev_priv, enum pipe pipe)
>
> static void chv_disable_pll(struct drm_i915_private *dev_priv, enum pipe
> pipe)
> {
> - enum dpio_channel port = vlv_pipe_to_channel(pipe);
> u32 val;
>
> /* Make sure the pipe isn't still relying on us */
> @@ -1791,14 +1782,8 @@ static void chv_disable_pll(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> I915_WRITE(DPLL(pipe), val);
> POSTING_READ(DPLL(pipe));
>
> - mutex_lock(&dev_priv->sb_lock);
> -
> /* Disable 10bit clock to display controller */
> - val = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW14(port));
> - val &= ~DPIO_DCLKP_EN;
> - vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), val);
> -
> - mutex_unlock(&dev_priv->sb_lock);
> + chv_phy_toggle_dclkp(dev_priv, pipe, false);
> }
>
> void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index 2a5d333..64788e3 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -461,6 +461,24 @@ void chv_phy_prepare_pll(struct intel_crtc *crtc, u32
> bestn,
> mutex_unlock(&dev_priv->sb_lock);
> }
>
> +void chv_phy_toggle_dclkp(struct drm_i915_private *dev_priv, enum pipe pipe,
> + bool enable)
> +{
> + enum dpio_channel port = vlv_pipe_to_channel(pipe);
> + u32 dpio_val;
> +
> + mutex_lock(&dev_priv->sb_lock);
> +
> + dpio_val = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW14(port));
> + if (enable)
> + dpio_val |= DPIO_DCLKP_EN;
> + else
> + dpio_val &= ~DPIO_DCLKP_EN;
> + vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), dpio_val);
> +
> + mutex_unlock(&dev_priv->sb_lock);
> +}
> +
> void chv_phy_read_dividers(struct drm_i915_private *dev_priv,
> enum pipe pipe, struct intel_dpll *clock)
> {
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools
On 13/05/16 15:04, Jani Nikula wrote:
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b70f05c..bb0b6f64000e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -752,7 +752,7 @@ struct intel_csr {
func(has_ddi) sep \
func(has_fpga_dbg)
-#define DEFINE_FLAG(name) u8 name:1
+#define DEFINE_FLAG(name) bool name:1
#define SEP_SEMICOLON ;
struct intel_device_info {
The churn virus spreads? :)
I tried that but it was negatively impacting the compiler. For some
reason it increases .text by 2.5k here. Don't see anything obvious,
would have to look at the code more closely to spot exactly why.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Move VLV divider readout to intel_dpio_phy.c
On Fri, May 13, 2016 at 05:15:01PM +0300, Ander Conselvan de Oliveira wrote:
> Reading the dividers depends on sideband messaging, so it fits well if
> the other functions in intel_dpio_phy.c. The new function will also be
> used in a future patch.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 11 +--
> drivers/gpu/drm/i915/intel_dpio_phy.c | 16
> 3 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 99dfacd..7dfa555 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3640,6 +3640,8 @@ void vlv_phy_reset_lanes(struct intel_encoder *encoder);
> void vlv_phy_prepare_pll(struct intel_crtc *crtc, u32 bestn,
>u32 bestm1, u32 bestm2, u32 bestp1, u32 bestp2,
>int port_clock, bool dp);
> +void vlv_phy_read_dividers(struct drm_i915_private *dev_priv,
> +enum pipe pipe, struct intel_dpll *clock);
..._pll_dividers() ?
>
> int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
> int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3e494ec..8d61263 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7806,22 +7806,13 @@ static void vlv_crtc_clock_get(struct intel_crtc
> *crtc,
> struct drm_i915_private *dev_priv = dev->dev_private;
> int pipe = pipe_config->cpu_transcoder;
> struct intel_dpll clock;
> - u32 mdiv;
> int refclk = 10;
>
> /* In case of DSI, DPLL will not be used */
> if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
> return;
>
> - mutex_lock(&dev_priv->sb_lock);
> - mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
> - mutex_unlock(&dev_priv->sb_lock);
> -
> - clock.m1 = (mdiv >> DPIO_M1DIV_SHIFT) & 7;
> - clock.m2 = mdiv & DPIO_M2DIV_MASK;
> - clock.n = (mdiv >> DPIO_N_SHIFT) & 0xf;
> - clock.p1 = (mdiv >> DPIO_P1_SHIFT) & 7;
> - clock.p2 = (mdiv >> DPIO_P2_SHIFT) & 0x1f;
> + vlv_phy_read_dividers(dev_priv, pipe, &clock);
>
> pipe_config->port_clock = vlv_calc_dpll_params(refclk, &clock);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index fcadc92..d28ef9f 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -670,3 +670,19 @@ void vlv_phy_prepare_pll(struct intel_crtc *crtc, u32
> bestn,
> vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW11(pipe), 0x87871000);
> mutex_unlock(&dev_priv->sb_lock);
> }
> +
> +void vlv_phy_read_dividers(struct drm_i915_private *dev_priv,
> +enum pipe pipe, struct intel_dpll *clock)
> +{
> + u32 mdiv;
> +
> + mutex_lock(&dev_priv->sb_lock);
> + mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
> + mutex_unlock(&dev_priv->sb_lock);
> +
> + clock->m1 = (mdiv >> DPIO_M1DIV_SHIFT) & 7;
> + clock->m2 = mdiv & DPIO_M2DIV_MASK;
> + clock->n = (mdiv >> DPIO_N_SHIFT) & 0xf;
> + clock->p1 = (mdiv >> DPIO_P1_SHIFT) & 7;
> + clock->p2 = (mdiv >> DPIO_P2_SHIFT) & 0x1f;
> +}
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: Move toggling of CHV DPIO_DCLKP_EN to intel_dpio_phy.c
This simplifies the pll enable/disable a code a bit and hides the
sideband message neatly in intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 19 ++-
drivers/gpu/drm/i915/intel_dpio_phy.c | 18 ++
3 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 149317c..44f4b7a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3630,6 +3630,8 @@ void chv_phy_post_pll_disable(struct intel_encoder
*encoder);
void chv_phy_prepare_pll(struct intel_crtc *crtc, u32 bestn,
u32 bestm1, u32 bestm2, u32 bestp1, u32 bestp2,
int vco);
+void chv_phy_toggle_dclkp(struct drm_i915_private *dev_priv, enum pipe pipe,
+ bool enable);
void chv_phy_read_dividers(struct drm_i915_private *dev_priv,
enum pipe pipe, struct intel_dpll *clock);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5ba000a..d43bdff 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1574,17 +1574,9 @@ static void _chv_enable_pll(struct intel_crtc *crtc,
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- enum dpio_channel port = vlv_pipe_to_channel(pipe);
- u32 tmp;
-
- mutex_lock(&dev_priv->sb_lock);
/* Enable back the 10bit clock to display controller */
- tmp = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW14(port));
- tmp |= DPIO_DCLKP_EN;
- vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), tmp);
-
- mutex_unlock(&dev_priv->sb_lock);
+ chv_phy_toggle_dclkp(dev_priv, pipe, true);
/*
* Need to wait > 100ns between dclkp clock enable bit and PLL enable.
@@ -1777,7 +1769,6 @@ static void vlv_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
static void chv_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
{
- enum dpio_channel port = vlv_pipe_to_channel(pipe);
u32 val;
/* Make sure the pipe isn't still relying on us */
@@ -1791,14 +1782,8 @@ static void chv_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
I915_WRITE(DPLL(pipe), val);
POSTING_READ(DPLL(pipe));
- mutex_lock(&dev_priv->sb_lock);
-
/* Disable 10bit clock to display controller */
- val = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW14(port));
- val &= ~DPIO_DCLKP_EN;
- vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), val);
-
- mutex_unlock(&dev_priv->sb_lock);
+ chv_phy_toggle_dclkp(dev_priv, pipe, false);
}
void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 2a5d333..64788e3 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -461,6 +461,24 @@ void chv_phy_prepare_pll(struct intel_crtc *crtc, u32
bestn,
mutex_unlock(&dev_priv->sb_lock);
}
+void chv_phy_toggle_dclkp(struct drm_i915_private *dev_priv, enum pipe pipe,
+ bool enable)
+{
+ enum dpio_channel port = vlv_pipe_to_channel(pipe);
+ u32 dpio_val;
+
+ mutex_lock(&dev_priv->sb_lock);
+
+ dpio_val = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW14(port));
+ if (enable)
+ dpio_val |= DPIO_DCLKP_EN;
+ else
+ dpio_val &= ~DPIO_DCLKP_EN;
+ vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), dpio_val);
+
+ mutex_unlock(&dev_priv->sb_lock);
+}
+
void chv_phy_read_dividers(struct drm_i915_private *dev_priv,
enum pipe pipe, struct intel_dpll *clock)
{
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: Merge vlv/chv _prepare_pll() with their enable counterpart
With the bulk of the dpio code moved out of the vlv/chv prepare pll
functions into intel_dpio_phy.c, those functions became simple enough
that they can be merged with the pll enabling function, that always
succeeds the prepare call.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 82
1 file changed, 26 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 06d9b96..3e494ec 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -104,10 +104,6 @@ static void intel_cpu_transcoder_set_m_n(struct intel_crtc
*crtc,
static void ironlake_set_pipeconf(struct drm_crtc *crtc);
static void haswell_set_pipeconf(struct drm_crtc *crtc);
static void haswell_set_pipemisc(struct drm_crtc *crtc);
-static void vlv_prepare_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config);
-static void chv_prepare_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config);
static void intel_begin_crtc_commit(struct drm_crtc *, struct drm_crtc_state
*);
static void intel_finish_crtc_commit(struct drm_crtc *, struct drm_crtc_state
*);
static void skl_init_scalers(struct drm_device *dev, struct intel_crtc
*intel_crtc,
@@ -1547,6 +1543,19 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
+ /* Enable Refclk */
+ I915_WRITE(DPLL(pipe),
+ pipe_config->dpll_hw_state.dpll &
+ ~(DPLL_VCO_ENABLE | DPLL_EXT_BUFFER_ENABLE_VLV));
+
+ /* No need to actually set up the DPLL with DSI */
+ if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) != 0)
+ vlv_phy_prepare_pll(crtc, pipe_config->dpll.n,
+ pipe_config->dpll.m1, pipe_config->dpll.m2,
+ pipe_config->dpll.p1, pipe_config->dpll.p2,
+ pipe_config->port_clock,
+ pipe_config->has_dp_encoder);
+
assert_pipe_disabled(dev_priv, pipe);
/* PLL is protected by panel, make sure we can write it */
@@ -1596,6 +1605,17 @@ static void chv_enable_pll(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
+ /* Enable Refclk and SSC */
+ I915_WRITE(DPLL(pipe),
+ pipe_config->dpll_hw_state.dpll & ~DPLL_VCO_ENABLE);
+
+ /* No need to actually set up the DPLL with DSI */
+ if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) != 0)
+ chv_phy_prepare_pll(crtc, pipe_config->dpll.n,
+ pipe_config->dpll.m1, pipe_config->dpll.m2,
+ pipe_config->dpll.p1, pipe_config->dpll.p2,
+ pipe_config->dpll.vco);
+
assert_pipe_disabled(dev_priv, pipe);
/* PLL is protected by panel, make sure we can write it */
@@ -6086,13 +6106,10 @@ static void valleyview_crtc_enable(struct drm_crtc
*crtc)
if (encoder->pre_pll_enable)
encoder->pre_pll_enable(encoder);
- if (IS_CHERRYVIEW(dev)) {
- chv_prepare_pll(intel_crtc, intel_crtc->config);
+ if (IS_CHERRYVIEW(dev))
chv_enable_pll(intel_crtc, intel_crtc->config);
- } else {
- vlv_prepare_pll(intel_crtc, intel_crtc->config);
+ else
vlv_enable_pll(intel_crtc, intel_crtc->config);
- }
for_each_encoder_on_crtc(dev, crtc, encoder)
if (encoder->pre_enable)
@@ -7185,51 +7202,6 @@ static void chv_compute_dpll(struct intel_crtc *crtc,
(pipe_config->pixel_multiplier - 1) <<
DPLL_MD_UDI_MULTIPLIER_SHIFT;
}
-static void vlv_prepare_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config)
-{
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- enum pipe pipe = crtc->pipe;
-
- /* Enable Refclk */
- I915_WRITE(DPLL(pipe),
- pipe_config->dpll_hw_state.dpll &
- ~(DPLL_VCO_ENABLE | DPLL_EXT_BUFFER_ENABLE_VLV));
-
- /* No need to actually set up the DPLL with DSI */
- if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
- return;
-
- vlv_phy_prepare_pll(crtc, pipe_config->dpll.n,
- pipe_config->dpll.m1, pipe_config->dpll.m2,
- pipe_config->dpll.p1, pipe_config->dpll.p2,
- pipe_config->port_clock,
- pipe_config->has_dp_encoder);
-
-}
-
-static void chv_prepare_pll(struct intel_c
[Intel-gfx] [PATCH 5/6] drm/i915: Move CHV divider readout to intel_dpio_phy.c
Reading the dividers depends on sideband messaging, so it fits well if
the other functions in intel_dpio_phy.c. The new function will also be
used in a future patch.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 18 +-
drivers/gpu/drm/i915/intel_dpio_phy.c | 24
3 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7dfa555..149317c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3630,6 +3630,8 @@ void chv_phy_post_pll_disable(struct intel_encoder
*encoder);
void chv_phy_prepare_pll(struct intel_crtc *crtc, u32 bestn,
u32 bestm1, u32 bestm2, u32 bestp1, u32 bestp2,
int vco);
+void chv_phy_read_dividers(struct drm_i915_private *dev_priv,
+ enum pipe pipe, struct intel_dpll *clock);
void vlv_set_phy_signal_level(struct intel_encoder *encoder,
u32 demph_reg_value, u32 preemph_reg_value,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d61263..5ba000a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7892,30 +7892,14 @@ static void chv_crtc_clock_get(struct intel_crtc *crtc,
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe = pipe_config->cpu_transcoder;
- enum dpio_channel port = vlv_pipe_to_channel(pipe);
struct intel_dpll clock;
- u32 cmn_dw13, pll_dw0, pll_dw1, pll_dw2, pll_dw3;
int refclk = 10;
/* In case of DSI, DPLL will not be used */
if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
return;
- mutex_lock(&dev_priv->sb_lock);
- cmn_dw13 = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW13(port));
- pll_dw0 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW0(port));
- pll_dw1 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW1(port));
- pll_dw2 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW2(port));
- pll_dw3 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW3(port));
- mutex_unlock(&dev_priv->sb_lock);
-
- clock.m1 = (pll_dw1 & 0x7) == DPIO_CHV_M1_DIV_BY_2 ? 2 : 0;
- clock.m2 = (pll_dw0 & 0xff) << 22;
- if (pll_dw3 & DPIO_CHV_FRAC_DIV_EN)
- clock.m2 |= pll_dw2 & 0x3f;
- clock.n = (pll_dw1 >> DPIO_CHV_N_DIV_SHIFT) & 0xf;
- clock.p1 = (cmn_dw13 >> DPIO_CHV_P1_DIV_SHIFT) & 0x7;
- clock.p2 = (cmn_dw13 >> DPIO_CHV_P2_DIV_SHIFT) & 0x1f;
+ chv_phy_read_dividers(dev_priv, pipe, &clock);
pipe_config->port_clock = chv_calc_dpll_params(refclk, &clock);
}
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index d28ef9f..2a5d333 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -461,6 +461,30 @@ void chv_phy_prepare_pll(struct intel_crtc *crtc, u32
bestn,
mutex_unlock(&dev_priv->sb_lock);
}
+void chv_phy_read_dividers(struct drm_i915_private *dev_priv,
+ enum pipe pipe, struct intel_dpll *clock)
+{
+ enum dpio_channel port = vlv_pipe_to_channel(pipe);
+ u32 cmn_dw13, pll_dw0, pll_dw1, pll_dw2, pll_dw3;
+
+ mutex_lock(&dev_priv->sb_lock);
+ cmn_dw13 = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW13(port));
+ pll_dw0 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW0(port));
+ pll_dw1 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW1(port));
+ pll_dw2 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW2(port));
+ pll_dw3 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW3(port));
+ mutex_unlock(&dev_priv->sb_lock);
+
+ clock->m1 = (pll_dw1 & 0x7) == DPIO_CHV_M1_DIV_BY_2 ? 2 : 0;
+ clock->m2 = (pll_dw0 & 0xff) << 22;
+ if (pll_dw3 & DPIO_CHV_FRAC_DIV_EN)
+ clock->m2 |= pll_dw2 & 0x3f;
+ clock->n = (pll_dw1 >> DPIO_CHV_N_DIV_SHIFT) & 0xf;
+ clock->p1 = (cmn_dw13 >> DPIO_CHV_P1_DIV_SHIFT) & 0x7;
+ clock->p2 = (cmn_dw13 >> DPIO_CHV_P2_DIV_SHIFT) & 0x1f;
+}
+
+
void vlv_set_phy_signal_level(struct intel_encoder *encoder,
u32 demph_reg_value, u32 preemph_reg_value,
u32 uniqtranscale_reg_value, u32 tx3_demph)
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Move VLV divider readout to intel_dpio_phy.c
Reading the dividers depends on sideband messaging, so it fits well if
the other functions in intel_dpio_phy.c. The new function will also be
used in a future patch.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 11 +--
drivers/gpu/drm/i915/intel_dpio_phy.c | 16
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 99dfacd..7dfa555 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3640,6 +3640,8 @@ void vlv_phy_reset_lanes(struct intel_encoder *encoder);
void vlv_phy_prepare_pll(struct intel_crtc *crtc, u32 bestn,
u32 bestm1, u32 bestm2, u32 bestp1, u32 bestp2,
int port_clock, bool dp);
+void vlv_phy_read_dividers(struct drm_i915_private *dev_priv,
+ enum pipe pipe, struct intel_dpll *clock);
int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3e494ec..8d61263 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7806,22 +7806,13 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe = pipe_config->cpu_transcoder;
struct intel_dpll clock;
- u32 mdiv;
int refclk = 10;
/* In case of DSI, DPLL will not be used */
if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
return;
- mutex_lock(&dev_priv->sb_lock);
- mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
- mutex_unlock(&dev_priv->sb_lock);
-
- clock.m1 = (mdiv >> DPIO_M1DIV_SHIFT) & 7;
- clock.m2 = mdiv & DPIO_M2DIV_MASK;
- clock.n = (mdiv >> DPIO_N_SHIFT) & 0xf;
- clock.p1 = (mdiv >> DPIO_P1_SHIFT) & 7;
- clock.p2 = (mdiv >> DPIO_P2_SHIFT) & 0x1f;
+ vlv_phy_read_dividers(dev_priv, pipe, &clock);
pipe_config->port_clock = vlv_calc_dpll_params(refclk, &clock);
}
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index fcadc92..d28ef9f 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -670,3 +670,19 @@ void vlv_phy_prepare_pll(struct intel_crtc *crtc, u32
bestn,
vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW11(pipe), 0x87871000);
mutex_unlock(&dev_priv->sb_lock);
}
+
+void vlv_phy_read_dividers(struct drm_i915_private *dev_priv,
+ enum pipe pipe, struct intel_dpll *clock)
+{
+ u32 mdiv;
+
+ mutex_lock(&dev_priv->sb_lock);
+ mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
+ mutex_unlock(&dev_priv->sb_lock);
+
+ clock->m1 = (mdiv >> DPIO_M1DIV_SHIFT) & 7;
+ clock->m2 = mdiv & DPIO_M2DIV_MASK;
+ clock->n = (mdiv >> DPIO_N_SHIFT) & 0xf;
+ clock->p1 = (mdiv >> DPIO_P1_SHIFT) & 7;
+ clock->p2 = (mdiv >> DPIO_P2_SHIFT) & 0x1f;
+}
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Move dpio code of VLV/CHV dpll enabling to intel_dpio_phy.c
Hide the dpio details of setting up the dplls on VLV/CHV to
intel_dpio_phy.c. This will allow the prepare and enable pll functions
to be merged in a follow up. It also creates a better split of the code
where most of the dpio access are concentrated in one place.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/intel_display.c | 207 ++
drivers/gpu/drm/i915/intel_dpio_phy.c | 202 +
3 files changed, 217 insertions(+), 198 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5f9dda2..99dfacd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3627,6 +3627,9 @@ void chv_phy_pre_pll_enable(struct intel_encoder
*encoder);
void chv_phy_pre_encoder_enable(struct intel_encoder *encoder);
void chv_phy_release_cl2_override(struct intel_encoder *encoder);
void chv_phy_post_pll_disable(struct intel_encoder *encoder);
+void chv_phy_prepare_pll(struct intel_crtc *crtc, u32 bestn,
+u32 bestm1, u32 bestm2, u32 bestp1, u32 bestp2,
+int vco);
void vlv_set_phy_signal_level(struct intel_encoder *encoder,
u32 demph_reg_value, u32 preemph_reg_value,
@@ -3634,6 +3637,9 @@ void vlv_set_phy_signal_level(struct intel_encoder
*encoder,
void vlv_phy_pre_pll_enable(struct intel_encoder *encoder);
void vlv_phy_pre_encoder_enable(struct intel_encoder *encoder);
void vlv_phy_reset_lanes(struct intel_encoder *encoder);
+void vlv_phy_prepare_pll(struct intel_crtc *crtc, u32 bestn,
+u32 bestm1, u32 bestm2, u32 bestp1, u32 bestp2,
+int port_clock, bool dp);
int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 048a5bf..06d9b96 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7080,35 +7080,6 @@ static void i9xx_update_pll_dividers(struct intel_crtc
*crtc,
}
}
-static void vlv_pllb_recal_opamp(struct drm_i915_private *dev_priv, enum pipe
- pipe)
-{
- u32 reg_val;
-
- /*
-* PLLB opamp always calibrates to max value of 0x3f, force enable it
-* and set it to a reasonable value instead.
-*/
- reg_val = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW9(1));
- reg_val &= 0xff00;
- reg_val |= 0x0030;
- vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW9(1), reg_val);
-
- reg_val = vlv_dpio_read(dev_priv, pipe, VLV_REF_DW13);
- reg_val &= 0x8cff;
- reg_val = 0x8c00;
- vlv_dpio_write(dev_priv, pipe, VLV_REF_DW13, reg_val);
-
- reg_val = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW9(1));
- reg_val &= 0xff00;
- vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW9(1), reg_val);
-
- reg_val = vlv_dpio_read(dev_priv, pipe, VLV_REF_DW13);
- reg_val &= 0x00ff;
- reg_val |= 0xb000;
- vlv_dpio_write(dev_priv, pipe, VLV_REF_DW13, reg_val);
-}
-
static void intel_pch_transcoder_set_m_n(struct intel_crtc *crtc,
struct intel_link_m_n *m_n)
{
@@ -7220,9 +7191,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe = crtc->pipe;
- u32 mdiv;
- u32 bestn, bestm1, bestm2, bestp1, bestp2;
- u32 coreclk, reg_val;
/* Enable Refclk */
I915_WRITE(DPLL(pipe),
@@ -7233,85 +7201,12 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
return;
- mutex_lock(&dev_priv->sb_lock);
-
- bestn = pipe_config->dpll.n;
- bestm1 = pipe_config->dpll.m1;
- bestm2 = pipe_config->dpll.m2;
- bestp1 = pipe_config->dpll.p1;
- bestp2 = pipe_config->dpll.p2;
-
- /* See eDP HDMI DPIO driver vbios notes doc */
-
- /* PLL B needs special handling */
- if (pipe == PIPE_B)
- vlv_pllb_recal_opamp(dev_priv, pipe);
-
- /* Set up Tx target for periodic Rcomp update */
- vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW9_BCAST, 0x010f);
+ vlv_phy_prepare_pll(crtc, pipe_config->dpll.n,
+ pipe_config->dpll.m1, pipe_config->dpll.m2,
+ pipe_config->dpll.p1, pipe_config->dpll.p2,
+ pipe_config->port_clock,
+ pipe_config->has_dp_encoder);
- /* Disable target IRef on PLL */
- reg_val = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW8(pipe));
- reg_val &= 0x00ff;
- vlv_dpio_write(dev_priv, pipe, VL
[Intel-gfx] [PATCH 1/6] drm/i915: Rename struct dpll to struct intel_dpll
Prefix struct dpll with intel_ to follow the convention in the driver.
Cc: Ville Syrjälä
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 76 +--
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 10 ++---
drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
7 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a0b513..5f9dda2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -577,7 +577,7 @@ struct intel_crtc_state;
struct intel_initial_plane_config;
struct intel_crtc;
struct intel_limit;
-struct dpll;
+struct intel_dpll;
struct drm_i915_display_funcs {
int (*get_display_clock_speed)(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c454744..1387acd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -948,7 +948,7 @@ static int bxt_calc_pll_link(struct drm_i915_private
*dev_priv,
{
struct intel_shared_dpll *pll;
struct intel_dpll_hw_state *state;
- struct dpll clock;
+ struct intel_dpll clock;
/* For DDI ports we always use a shared PLL. */
if (WARN_ON(dpll == DPLL_ID_PRIVATE))
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 05c7533..048a5bf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -578,7 +578,7 @@ static bool intel_pipe_will_have_type(const struct
intel_crtc_state *crtc_state,
* divided-down version of it.
*/
/* m1 is reserved as 0 in Pineview, n is a ring counter */
-static int pnv_calc_dpll_params(int refclk, struct dpll *clock)
+static int pnv_calc_dpll_params(int refclk, struct intel_dpll *clock)
{
clock->m = clock->m2 + 2;
clock->p = clock->p1 * clock->p2;
@@ -590,12 +590,12 @@ static int pnv_calc_dpll_params(int refclk, struct dpll
*clock)
return clock->dot;
}
-static uint32_t i9xx_dpll_compute_m(struct dpll *dpll)
+static uint32_t i9xx_dpll_compute_m(struct intel_dpll *dpll)
{
return 5 * (dpll->m1 + 2) + (dpll->m2 + 2);
}
-static int i9xx_calc_dpll_params(int refclk, struct dpll *clock)
+static int i9xx_calc_dpll_params(int refclk, struct intel_dpll *clock)
{
clock->m = i9xx_dpll_compute_m(clock);
clock->p = clock->p1 * clock->p2;
@@ -607,7 +607,7 @@ static int i9xx_calc_dpll_params(int refclk, struct dpll
*clock)
return clock->dot;
}
-static int vlv_calc_dpll_params(int refclk, struct dpll *clock)
+static int vlv_calc_dpll_params(int refclk, struct intel_dpll *clock)
{
clock->m = clock->m1 * clock->m2;
clock->p = clock->p1 * clock->p2;
@@ -619,7 +619,7 @@ static int vlv_calc_dpll_params(int refclk, struct dpll
*clock)
return clock->dot / 5;
}
-int chv_calc_dpll_params(int refclk, struct dpll *clock)
+int chv_calc_dpll_params(int refclk, struct intel_dpll *clock)
{
clock->m = clock->m1 * clock->m2;
clock->p = clock->p1 * clock->p2;
@@ -640,7 +640,7 @@ int chv_calc_dpll_params(int refclk, struct dpll *clock)
static bool intel_PLL_is_valid(struct drm_device *dev,
const struct intel_limit *limit,
- const struct dpll *clock)
+ const struct intel_dpll *clock)
{
if (clock->n < limit->n.min || limit->n.max < clock->n)
INTELPllInvalid("n out of range\n");
@@ -712,11 +712,11 @@ i9xx_select_p2_div(const struct intel_limit *limit,
static bool
i9xx_find_best_dpll(const struct intel_limit *limit,
struct intel_crtc_state *crtc_state,
- int target, int refclk, struct dpll *match_clock,
- struct dpll *best_clock)
+ int target, int refclk, struct intel_dpll *match_clock,
+ struct intel_dpll *best_clock)
{
struct drm_device *dev = crtc_state->base.crtc->dev;
- struct dpll clock;
+ struct intel_dpll clock;
int err = target;
memset(best_clock, 0, sizeof(*best_clock));
@@ -769,11 +769,11 @@ i9xx_find_best_dpll(const struct intel_limit *limit,
static bool
pnv_find_best_dpll(const struct intel_limit *limit,
struct intel_crtc_state *crtc_state,
- int target, int refclk, struct dpll *match_clock,
- struct dpll *best_clock)
+ int target, int refclk, struct intel_dpll *match_clock,
+ struct intel_dpll *best_clock)
{
struct drm_device *dev = crtc_state->base.crtc->dev;
- struct dpll clock;
+ struct intel_dpll clock;
int
[Intel-gfx] [PATCH 0/6] Move dpio access out of intel_display.c
Hi,
This series moves all of the calls to vlv_dpio_{read,write} to
intel_dpio_phy.c. I think it simplifies the surrounding code a bit.
Thanks,
Ander
Ander Conselvan de Oliveira (6):
drm/i915: Rename struct dpll to struct intel_dpll
drm/i915: Move dpio code of VLV/CHV dpll enabling to intel_dpio_phy.c
drm/i915: Merge vlv/chv _prepare_pll() with their enable counterpart
drm/i915: Move VLV divider readout to intel_dpio_phy.c
drm/i915: Move CHV divider readout to intel_dpio_phy.c
drm/i915: Move toggling of CHV DPIO_DCLKP_EN to intel_dpio_phy.c
drivers/gpu/drm/i915/i915_drv.h | 14 +-
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 395 ++
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_dpio_phy.c | 260 ++
drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
8 files changed, 350 insertions(+), 337 deletions(-)
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b70f05c..bb0b6f64000e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -752,7 +752,7 @@ struct intel_csr {
func(has_ddi) sep \
func(has_fpga_dbg)
-#define DEFINE_FLAG(name) u8 name:1
+#define DEFINE_FLAG(name) bool name:1
#define SEP_SEMICOLON ;
struct intel_device_info {
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 2/2] drm/i915: don't mix bitwise and logical operations for has_snoop
Also make the code more readable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 547100fa3122..a8c79f6512a4 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -954,9 +954,11 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 9)
gen9_sseu_info_init(dev);
- /* Snooping is broken on BXT A stepping. */
info->has_snoop = !info->has_llc;
- info->has_snoop &= !IS_BXT_REVID(dev, 0, BXT_REVID_A1);
+
+ /* Snooping is broken on BXT A stepping. */
+ if (IS_BXT_REVID(dev, 0, BXT_REVID_A1))
+ info->has_snoop = false;
DRM_DEBUG_DRIVER("slice total: %u\n", info->slice_total);
DRM_DEBUG_DRIVER("subslice total: %u\n", info->subslice_total);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/3] tools/intel_bios_reader: abstract header information dumping
Fairly simple stuff, pushed the series to igt.
BR,
Jani.
On Thu, 12 May 2016, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> tools/intel_bios_reader.c | 52
> +++
> 1 file changed, 30 insertions(+), 22 deletions(-)
>
> diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
> index 5bad3f49690d..25460cacd84c 100644
> --- a/tools/intel_bios_reader.c
> +++ b/tools/intel_bios_reader.c
> @@ -62,6 +62,7 @@ struct bdb_block {
> };
>
> struct context {
> + const struct vbt_header *vbt;
> const struct bdb_header *bdb;
> int size;
>
> @@ -1405,6 +1406,32 @@ static bool dump_section(struct context *context, int
> section_id)
> return true;
> }
>
> +static void dump_headers(struct context *context)
> +{
> + char signature[17];
> + int i;
> +
> + printf("VBT vers: %d.%d\n",
> +context->vbt->version / 100, context->vbt->version % 100);
> +
> + strncpy(signature, (char *)context->bdb->signature, 16);
> + signature[16] = 0;
> + printf("BDB sig: %s\n", signature);
> + printf("BDB vers: %d\n", context->bdb->version);
> +
> + printf("Available sections: ");
> + for (i = 0; i < 256; i++) {
> + struct bdb_block *block;
> +
> + block = find_section(context, i);
> + if (!block)
> + continue;
> + printf("%d ", i);
> + free(block);
> + }
> + printf("\n");
> +}
> +
> enum opt {
> OPT_UNKNOWN = '?',
> OPT_END = -1,
> @@ -1441,11 +1468,9 @@ int main(int argc, char **argv)
> const char *toolname = argv[0];
> struct stat finfo;
> int size;
> - struct bdb_header *bdb;
> struct context context = {
> .panel_type = -1,
> };
> - char signature[17];
> char *endp;
> int block_number = -1;
>
> @@ -1570,34 +1595,17 @@ int main(int argc, char **argv)
> return 1;
> }
>
> - printf("VBT vers: %d.%d\n", vbt->version / 100, vbt->version % 100);
> -
> bdb_off = vbt_off + vbt->bdb_offset;
> if (bdb_off >= size - sizeof(struct bdb_header)) {
> printf("Invalid VBT found, BDB points beyond end of data
> block\n");
> return 1;
> }
>
> - bdb = (struct bdb_header *)(VBIOS + bdb_off);
> - strncpy(signature, (char *)bdb->signature, 16);
> - signature[16] = 0;
> - printf("BDB sig: %s\n", signature);
> - printf("BDB vers: %d\n", bdb->version);
> -
> - context.bdb = bdb;
> + context.vbt = vbt;
> + context.bdb = (const struct bdb_header *)(VBIOS + bdb_off);
> context.size = size;
>
> - printf("Available sections: ");
> - for (i = 0; i < 256; i++) {
> - struct bdb_block *block;
> -
> - block = find_section(&context, i);
> - if (!block)
> - continue;
> - printf("%d ", i);
> - free(block);
> - }
> - printf("\n");
> + dump_headers(&context);
>
> if (!context.devid) {
> const char *devid_string = getenv("DEVICE");
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm: Add aux plane verification in addFB2 (rev3)
== Series Details == Series: series starting with [1/2] drm: Add aux plane verification in addFB2 (rev3) URL : https://patchwork.freedesktop.org/series/4641/ State : failure == Summary == Applying: drm: Add aux plane verification in addFB2 Applying: drm/i915: Render decompression support for Gen9 and above Patch failed at 0002 drm/i915: Render decompression support for Gen9 and above The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915: Render decompression support for Gen9 and above
This patch includes enabling render decompression (RC) after checking
all the requirements (format, tiling, rotation etc.).
TODO:
1. Disable stereo 3D when render decomp is enabled (bit 7:6)
2. Render decompression must not be used in VTd pass-through mode
3. Program hashing select CHICKEN_MISC1 bit 15
4. For Gen10, add support for RGB 1010102
5. RC-FBC workaround
6. RC watermark calculation
The reason for using a plane property instead of fb modifier:-
In Android, OGL passes a render compressed buffer to hardware composer
(HWC), which would then request a flip on that buffer after checking if
the target can support render compressed buffer. For example, only planes
1 and 2 on pipes 1 and 2 can support RC. In case the target cannot
support it, HWC will revert back to OGL requesting for uncompressed
buffer.
Here,
if plane property is used, OGL would send back the buffer (same ID) after
decompression, marked uncompressed. If fb modifier was used, a different
version of the buffer would have to be maintained for different
combinations - in the simple case of render compressed vs uncompressed
buffer, there would be 2 fbs with 2 IDs. So, in this case, OGL would give
a reference to a fb with a different ID.
To avoid the difficulty of keeping track of multiple fbs and the subsequent
complexity in debug, the architecture forum decided to go ahead with a
plane property for RC.
[Mayuresh] Added the plane check in skl_check_compression()
v2: Ville's review comments addressed
- Removed WAs specific to SKL-C and BXT-A
- Assign capabilities according to pipe and plane during property creation
- in skl_check_compression(), check for conditions that must be satisifed
Maintaining the check for pixel format, even though compressed fb of format
other RGB should not have been created, to be on the safer side.
Added checks for BGR too.
Bitmask is being used for the property to accommodate 2 more options
expected to be added in future.
v3: This patch has been implemented on top of Ville's patch series on
fb->offsets.
(Ref: git://github.com/vsyrjala/linux.git fb_offsets_15)
- Userspace is expected to pass aux offset through fb->offsets[1].
Testing is in progress for v3 of the patch.
Signed-off-by: Vandana Kannan
Cc: Ville Syrjälä
Cc: Smith, Gary K
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 22 ++
drivers/gpu/drm/i915/intel_atomic_plane.c | 24 +--
drivers/gpu/drm/i915/intel_display.c | 111 ++
drivers/gpu/drm/i915/intel_drv.h | 10 +++
drivers/gpu/drm/i915/intel_sprite.c | 13
6 files changed, 177 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a0b513..0465e0f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1915,6 +1915,7 @@ struct drm_i915_private {
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+ struct drm_property *render_comp_property;
/* hda/i915 audio component */
struct i915_audio_component *audio_component;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 54ce0b1..9d008e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5818,6 +5818,28 @@ enum skl_disp_power_wells {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+ _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+ _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A 0x701c4
+#define PLANE_AUX_OFFSET_2_A 0x702c4
+#define PLANE_AUX_OFFSET_1_B 0x711c4
+#define PLANE_AUX_OFFSET_2_B 0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe) \
+ _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe) \
+ _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7de7721..2617b75 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -228,8 +228,16 @@ intel_pla
Re: [Intel-gfx] FreeBSD i915 driver update
On Thu, 12 May 2016, Scott Long wrote: > I'd like to offer a heads-up on the ongoing work in the FreeBSD project > to update to a contemporary version of the i915 driver. I inadvertently let this through the moderation while Scott had reposted as subscriber. Please ignore this one and keep the conversation in the other thread [1]. Sorry for the noise. BR, Jani. [1] http://mid.gmane.org/946f24c0-6419-4c15-acab-0cd6e247d...@netflix.com -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Skip clearing the GGTT on full-ppgtt systems
On Thu, May 12, 2016 at 03:28:16PM +0100, Chris Wilson wrote:
> Under full-ppgtt, access to the global GTT is carefully regulated
> through hardware functions (i.e. userspace cannot read and write to
> arbitrary locations in the GGTT via the GPU). With this restriction in
> place, we can forgo clearing stale entries from the GGTT as they will
> not be accessed.
>
> For aliasing-ppgtt, we could almost do the same except that we do allow
> userspace access to the global-GTT via execbuf in order to workraound
> some quirks of certain instructions. (This execbuf path is filtered out
> with EINVAL on full-ppgtt.)
>
> The most dramatic effect this will have will be during resume, as with
> full-ppgtt the GGTT is only used sparingly.
>
> Signed-off-by: Chris Wilson
> Cc: David Weinehall
I've tested patch 3 + 4 with SuspendResume
(analyze_suspend.py -config suspend-callgraph.cfg).
The takeaway is that restore_gtt (almost) disappears
in the noise. Nice improvement.
I've also confirmed that hibernate works properly.
Tested-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 319f3b459b3e..7eab619a3eb2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2477,6 +2477,13 @@ static void gen6_ggtt_insert_entries(struct
> i915_address_space *vm,
> assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
> }
>
> +static void nop_clear_range(struct i915_address_space *vm,
> + uint64_t start,
> + uint64_t length,
> + bool use_scratch)
> +{
> +}
> +
> static void gen8_ggtt_clear_range(struct i915_address_space *vm,
> uint64_t start,
> uint64_t length,
> @@ -3072,14 +3079,17 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>
> ret = ggtt_probe_common(dev, ggtt->size);
>
> - ggtt->base.clear_range = gen8_ggtt_clear_range;
> - if (IS_CHERRYVIEW(dev_priv))
> - ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
> - else
> - ggtt->base.insert_entries = gen8_ggtt_insert_entries;
> ggtt->base.bind_vma = ggtt_bind_vma;
> ggtt->base.unbind_vma = ggtt_unbind_vma;
>
> + ggtt->base.clear_range = nop_clear_range;
> + if (!USES_FULL_PPGTT(dev_priv))
> + ggtt->base.clear_range = gen8_ggtt_clear_range;
> +
> + ggtt->base.insert_entries = gen8_ggtt_insert_entries;
> + if (IS_CHERRYVIEW(dev_priv))
> + ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
> +
> return ret;
> }
>
> --
> 2.8.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Lazily migrate the objects after hibernation
On Thu, May 12, 2016 at 03:28:15PM +0100, Chris Wilson wrote:
> Now that we mark the object domains for having been restored from the
> hibernation image, we not need to flush everything during resume and
> can instead rely on the normal domain tracking to flush only when
> required. The only caveat here are objects that are pinned for use by
> the hardware, whose contents must be coherent for when the device
> resumes reading from then (shortly afterwards with the driver assuming
> the objects are in the correct domain).
>
> Signed-off-by: Chris Wilson
> Cc: Imre Deak
> Cc: David Weinehall
I've tested patch 3 + 4 with SuspendResume
(analyze_suspend.py -config suspend-callgraph.cfg).
The takeaway is that restore_gtt (almost) disappears
in the noise. Nice improvement.
I've also confirmed that hibernate works properly.
Tested-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 5fb14c835543..319f3b459b3e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3245,7 +3245,6 @@ void i915_gem_restore_gtt_mappings(struct drm_device
> *dev)
> struct i915_ggtt *ggtt = &dev_priv->ggtt;
> struct drm_i915_gem_object *obj;
> struct i915_vma *vma;
> - bool flush;
>
> i915_check_and_clear_faults(dev_priv);
>
> @@ -3255,19 +3254,16 @@ void i915_gem_restore_gtt_mappings(struct drm_device
> *dev)
>
> /* Cache flush objects bound into GGTT and rebind them. */
> list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
> - flush = false;
> list_for_each_entry(vma, &obj->vma_list, obj_link) {
> if (vma->vm != &ggtt->base)
> continue;
>
> WARN_ON(i915_vma_bind(vma, obj->cache_level,
> PIN_UPDATE));
> -
> - flush = true;
> }
>
> - if (flush)
> - i915_gem_clflush_object(obj, obj->pin_display);
> + if (obj->pin_display)
> + WARN_ON(i915_gem_object_set_to_gtt_domain(obj, false));
> }
>
> if (INTEL_INFO(dev)->gen >= 8) {
> --
> 2.8.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix a few code checker errors
On Fri, May 13, 2016 at 03:24:32PM +0300, Imre Deak wrote: > On Thu, 2016-05-12 at 15:31 +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Fix a few code checker errors > > URL : https://patchwork.freedesktop.org/series/7071/ > > State : failure > > > > == Summary == > > > > Series 7071v1 drm/i915: Fix a few code checker errors > > http://patchwork.freedesktop.org/api/1.0/series/7071/revisions/1/mbox > > > > Test drv_hangman: > > Subgroup error-state-basic: > > fail -> PASS (ro-ilk1-i5-650) > > Test gem_exec_flush: > > Subgroup basic-batch-kernel-default-cmd: > > pass -> FAIL (fi-byt-n2820) > > Unrelated, pre-existing issue: > https://bugs.freedesktop.org/show_bug.cgi?id=95372 Fwiw, there are at least a coupleo of issues in gem_exec_flush for byt that require different fixes (the cmdparser is a different synchronisation issue). And has been accumulating the occasional intel_do_flush_locked EINVAL bug report. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3] tests/kms_flip: Adjust tolerance when counting frames
On 13.05.2016 15:00, Chris Wilson wrote:
On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote:
basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to
be aproximately equal with the estimated number.
This is a false negative, one of the reasons being the precision lost when
truncating a fractional number.
Fixed this by using floating point arithmetic.
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Gabriel Feceoru
---
tests/kms_flip.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index eda2fcc..6ec97d0 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1182,13 +1182,13 @@ static void check_final_state(struct test_output *o,
struct event_state *es,
/* Verify we drop no frames, but only if it's not a TV encoder, since
* those use some funny fake timings behind userspace's back. */
if (o->flags & TEST_CHECK_TS && !analog_tv_connector(o)) {
- int expected;
+ double expected;
int count = es->count;
count *= o->seq_step;
- expected = elapsed / frame_time(o);
int expected = count * frame_time(o);
igt_assert_f(100 * expected >= elasped * 99 && 100 * count <= expected * 101,
"dropped frames, expected %d, counted %d, encoder type %d\n",
elapsed / frame_time(o), count, o->kencoder[0]->encoder_type);
if I understood your concern correctly, as the only loss of precison
there would be from calculating 'expected'.
That would also do it, but with care where to use the cast:
int expected = (int)((double)count * frame_time(o));
vs
int expected = count * (int)frame_time(o);
Gabriel.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] FreeBSD i915 driver update
Hello intel-gfx, I'd like to offer a heads-up on the ongoing work in the FreeBSD project to update to a contemporary version of the i915 driver. For context, some background information on the earlier approaches we've taken to import the i915 driver in FreeBSD. In the past, developers often reworked the imported driver to conform to FreeBSD coding and even style conventions. Needless to say, this divergence from the upstream driver caused an ever-increasing maintenance burden, and proved to be a large impediment to updating the driver. In May 2012 we updated to migrate to the KMS driver and bring compat up to SandyBridge / IvyBridge hardware. We remained on this version for several years. In March 2016 Jean-Sébastien Pédron updated to the i915 driver from Linux 3.8.13, bringing in initial support for Haswell GPUs. A lot of effort went into reducing gratuituous differences versus the upstream driver, but the delta to the Linux verison is still significant. This is what we have in FreeBSD HEAD right now, and represents about 17KLOC of diffs against Linux. FreeBSD HEAD source reference: https://svnweb.freebsd.org/base/head/sys/dev/drm2/i915/ Jean-Sébastien and other developers have been discussing a new approach for post-3.8.13 updates. Instead of maintaining a large set of changes, the plan is to keep the driver as close as possible to the upstream Linux version, and use straightforward shims to adapt to interfaces provided by FreeBSD where possible. We took an initial step on that path with an update to the Linux 3.9 driver, and have reduced the diffs to about 9KLOC. https://github.com/freebsd/freebsd-base-graphics/tree/drm-next-3.9 Current work in progress is targeting an update to Linux 4.6, and the driver currently attaches and basic functionality works (e.g., xterms and glxgears). A demonstration screen shot is at https://plus.google.com/114029301710423058970/posts/485LyZegC9B The delta to Linux is about 4KLOC right now. https://github.com/iotamudelta/freebsd-base-graphics/tree/drm-next-4.6 The diffs against the upstream linux code have roughly halfed with each porting effort. The focus is on creating a linux KPI compatiblity layer for FreeBSD that will allow the DRM and KMS drivers to work with minimal changes. The goal is to get it under 1KLOC and to the point where its feasible to follow the upstream development on a change-by-change basis. Our ultimate goal is to align closely with the Linux graphics development community and collaborate with Intel, ATI, and others on keeping FreeBSD up to date in their product development efforts. The Linux KPI module code and DRM modules will be put into the FreeBSD ports tree to make them more modular and sharable between different branches and forks of FreeBSD. We're hoping to get a BETA level release into the ports tree in time for the FreeBSD 11.0 launch this summer. However, the effort is still very much ALPHA quality right now and will stay in github as it matures. Even though the code is still ALPHA, we're looking for any feedback on the approach we're taking, as well as any reports of successes and failures on a variety of hardware. Feel free to follow up on this mailing list, or to join the freebsd-x11 mailing list on freebsd.org. We're also doing a bi-weekly community conference call to discuss this and other topics in graphics on FreeBSD, and we welcome others to join the discussion. As we continue the progress on getting the code fleshed out and matured, we expect that we'll collaborate on this list and in the IRC channel. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] FreeBSD i915 driver update
> I don't have any FreeBSD experience and I don't know what kind of team > of developers you have, but it is my educated guess that you'll have > plenty of more productive things to do than trying to maintain a > significant amount of delta with upstream while also trying to stay > up-to-date. I agree 100%. FreeBSD's DRM support has lagged further and further behind every year. Linux 3.8 was releases 39 months ago, but support for it just went in to FreeBSD in March of this year. By working on the linuxkpi side of things I was able to get the 4.6-rc5 i915 up and running with at least glxgears working in under three weeks. It's really hard to argue for making the driver "native" any more. >> Our ultimate goal is to align closely with the Linux graphics >> development community and collaborate with Intel, ATI, and others on >> keeping FreeBSD up to date in their product development efforts. > > The focus and priority of the i915 driver is obviously Linux, but I > don't see us rejecting patches that help FreeBSD if the patches > generally make sense and don't interfere with the main priority. That would be much appreciated. I have the diff with upstream down to ~450 lines, so there likely isn't a whole lot that needs to change. However, there may be small things that are easier to do in the driver than in the linuxkpi. Thanks in advance. -M ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
