Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

[Zhang, Xiong Y]

> On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote:
> > >
> > > >
> > > > + David and Jon
> > > >
> > > > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
> > > >
> > > > The blocking issue I see is that bisecting is still not pointing at
> > > > relevant commits. Both bisected commits from Bugzilla are not related
> > > > to changes in stolen memory usage behavior. I'd assume a successful
> > > > bisect to land at the patches where we start creating kernel internal
> > > > objects from stolen memory. Otherwise we could be ignoring a bug
> > > > elsewhere. If it consistently lands on those patches, then there might
> > > > be something wrong with them, in addition to stolen memory problems.
> > > [Zhang, Xiong Y] I only try kernel 4.8 and 4.9 above, as the bugzilla
> descripted,
> > > guest 4.8 kernel doesn't see gpu hang in guest dmesg, 4.9 kernel has gpu
> hang
> > > in guest dmesg. From this point, we could do git bisect.
> > > But tons of IOMMU DMA R/W exception to stolen memory exist in host
> dmesg
> > > when guest kernel is 4.8 and 4.9. This means guest domain iommu table
> > > doesn't
> > > have mapping for stolen memory and IGD fail in accessing stolen memory
> > > from guest kernel 4.8 and 4.9. From this point, this issue isn't a 
> > > regression
> and
> > > shouldn't go git bisect. You could check this host error message from the
> > > bugzilla
> > > attachment. And this should be fixed first.
> > > Anyway, I will try my best to get the ideal commit through git bisect, but
> I'm
> > > afraid
> > > the result is the same as past because we don't have a stable good point 
> > > to
> > > start git
> > > bisect.
> > [Zhang, Xiong Y] hi, Joonas:
> > As you said, the gpu hang exist because i915 create ring buffer from stolen
> memory.
> > I did git bisect again, and the following commit is the first bad commit:
> > commit c58b735fc762e891481e92af7124b85cb0a51fce
> > Author: Chris Wilson 
> > Date:   Thu Aug 18 17:16:57 2016 +0100
> >
> > drm/i915: Allocate rings from stolen
> >
> > If we have stolen available, make use of it for ringbuffer allocation.
> > Previously this was restricted to !llc platforms, as writing to stolen
> > requires a GGTT mapping - but now that we have partial mappable
> support,
> > the mappable aperture isn't quite so precious so we can use it more
> > freely and ringbuffers are a good user for the otherwise wasted stolen.
> >
> > After reverting this patch from drm-intel-nightly, I didn't see gpu hang 
> > during
> guest boot process.
> > So what's our next step ?
> 
> An appropriate next step would be to evaluate how much work it is to
> support the RMRR passthrough David mentioned about in his commit.
[Zhang, Xiong Y] As Kevin explained, KVM community found the disadvantage
Of RMRR and have decided to not support RMRR passthrough, so it is really hard
for us to push such solution and isn't related to the workload.
Except usb and graphic card, all other devices with RMRR couldn't passthrough
to guest. But the driver of usb and graphic card couldn't access RMRR in such
environment.
https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf

> I'd also go talk with the IGD team, why they refuse to load the driver
> when stolen memory is correctly reported as zero, and insist on being
> lied to.
[Zhang, Xiong Y] thanks a lot for doing so.
> 
> While doing that, please update the freedesktop.org bugs.
[Zhang, Xiong Y] sure, I will update bugzilla once we have further
finding and make a decision.
> 
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: capture GuC logs if FW fails to load (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: capture GuC logs if FW fails to load (rev3)
URL   : https://patchwork.freedesktop.org/series/23982/
State : success

== Summary ==

Series 23982v3 drm/i915/guc: capture GuC logs if FW fails to load
https://patchwork.freedesktop.org/api/1.0/series/23982/revisions/3/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:425s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:547s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:401s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:563s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:453s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:566s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:455s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:492s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:406s

fb550f86433515f36a0de161631541ec114581e3 drm-tip: 2017y-05m-05d-18h-33m-52s UTC 
integration manifest
553d025 drm/i915/guc: capture GuC logs if FW fails to load

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4635/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915/guc: capture GuC logs if FW fails to load

[Daniele Ceraolo Spurio]

We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Keeping the
object around allows us to access them after driver load is completed.

v2: keep the object around instead of using kernel memory (chris)
don't store the logs in the gpu_error struct (Chris)
add a check on guc_log_level to avoid snapshotting empty logs

v3: use separate debugfs for error log (Chris)

Cc: Chris Wilson 
Cc: Oscar Mateo 
Cc: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 35 ++-
 drivers/gpu/drm/i915/i915_drv.c  |  3 +++
 drivers/gpu/drm/i915/intel_guc_log.c | 17 +
 drivers/gpu/drm/i915/intel_uc.c  |  7 +--
 drivers/gpu/drm/i915/intel_uc.h  |  5 +
 5 files changed, 52 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470..4d39e08d3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2542,27 +2542,35 @@ static int i915_guc_info(struct seq_file *m, void *data)
 
 static int i915_guc_log_dump(struct seq_file *m, void *data)
 {
-   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct drm_info_node *node = m->private;
+   struct drm_i915_private *dev_priv = node_to_i915(node);
+   bool dump_err_log = !!node->info_ent->data;
struct drm_i915_gem_object *obj;
-   int i = 0, pg;
+   u32 *log;
+   int i = 0;
 
-   if (!dev_priv->guc.log.vma)
+   if (!dump_err_log && dev_priv->guc.log.vma)
+   obj = dev_priv->guc.log.vma->obj;
+   else if (dump_err_log && dev_priv->guc.err_load_log)
+   obj = dev_priv->guc.err_load_log;
+   else
return 0;
 
-   obj = dev_priv->guc.log.vma->obj;
-   for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
-   u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));
-
-   for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
-   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
-  *(log + i), *(log + i + 1),
-  *(log + i + 2), *(log + i + 3));
-
-   kunmap_atomic(log);
+   log = i915_gem_object_pin_map(obj, I915_MAP_WC);
+   if (IS_ERR(log)) {
+   DRM_ERROR("Failed to pin guc_log object\n");
+   return PTR_ERR(log);
}
 
+   for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
+   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+  *(log + i), *(log + i + 1),
+  *(log + i + 2), *(log + i + 3));
+
seq_putc(m, '\n');
 
+   i915_gem_object_unpin_map(obj);
+
return 0;
 }
 
@@ -4774,6 +4782,7 @@ static int i915_hpd_storm_ctl_open(struct inode *inode, 
struct file *file)
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+   {"i915_guc_err_load_log_dump", i915_guc_log_dump, 0, (void *)1},
{"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 452c265..d8c82ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1354,6 +1354,9 @@ void i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
i915_reset_error_state(dev_priv);
 
+   /* release GuC error log (if any) */
+   i915_guc_load_error_log_free(_priv->guc);
+
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
 
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 16d3b87..691da42 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -660,3 +660,20 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
guc_log_runtime_destroy(_priv->guc);
mutex_unlock(_priv->drm.struct_mutex);
 }
+
+void i915_guc_load_error_log_capture(struct intel_guc *guc)
+{
+   if (!guc->log.vma || i915.guc_log_level < 0)
+   return;
+
+   if (!guc->err_load_log)
+   guc->err_load_log = i915_gem_object_get(guc->log.vma->obj);
+
+   return;
+}
+
+void i915_guc_load_error_log_free(struct intel_guc *guc)
+{
+   if (guc->err_load_log)
+   i915_gem_object_put(guc->err_load_log);
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 7fd75ca..d66ffab 100644
--- 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Dump the GuC stage descriptor pool in debugfs

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Dump the GuC stage descriptor pool in debugfs
URL   : https://patchwork.freedesktop.org/series/24051/
State : success

== Summary ==

Series 24051v1 drm/i915/guc: Dump the GuC stage descriptor pool in debugfs
https://patchwork.freedesktop.org/api/1.0/series/24051/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:438s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:578s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:555s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:402s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:422s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:489s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:481s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:451s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:558s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:455s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:506s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:426s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:405s
fi-skl-6260u failed to collect. IGT log at Patchwork_4634/fi-skl-6260u/igt.log

fb550f86433515f36a0de161631541ec114581e3 drm-tip: 2017y-05m-05d-18h-33m-52s UTC 
integration manifest
413cbcc drm/i915/guc: Dump the GuC stage descriptor pool in debugfs

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4634/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Matthias Kaehlcke]

Hi,

El Fri, May 05, 2017 at 01:29:32PM -0700 Grant Grundler ha dit:

> On Fri, May 5, 2017 at 1:08 PM, Ville Syrjälä
>  wrote:
> ...
> >> > I'm not convinced the patch is making things any better really. To
> >> > fix this really properly, I think we'd need to introduce a new enum
> >> > pch_transcoder and thus avoid the confusion of which type of
> >> > transcoder we're talking about.

I agree, the patch certainly doesn't improve the confusing use of the enums.

> >> Is an enum better than coding an explicit conversion in an inline function?
> >
> > The point of the enum would be to make it more clear which piece of
> > hardware we're talking to in each case.
> 
> Ah ok - I misunderstood - I thought this was already the case.
> 
> > But this would require going
> > through the entire PCH code and changing things to use the right type
> > in each case. Quite a bit of work with little measurable gain I'd say.
> 
> IMHO, one of the best things that happened to C standard was addition
> of strong type checking. It's helped prevent developers from making
> one class of "stupid mistakes". So while this change wouldn't improve
> performance, it would allow a form of automated correctness checking
> that can be enforced with every patch you get (every time the code
> base is compiled).
> 
> In other words, the gain isn't currently measurable the same way
> performance is but I believe it's worth doing.  Given the number of
> typedefs and enums in kernel code, I suspect most kernel developers
> would agree.

I also think that proper use of enums is an additional line of defense
against "stupid mistakes". While weeding out these warnings in
different drivers I came across a few cases were the code was working
out of sheer luck because the (unintentionally) mismatched enums
resolved to the same value.

Cheers

Matthias

> >> Then the code can do some sanity checking as well. Something like:
> >>
> >> enum transcoder pch_to_cpu_enum(enum pipe)
> >> {
> >> WARN_ON(pipe > FOO);
> >> return (enum transcoder) pipe;
> >> }
> >
> > That would have to be called pipe_to_pch_transcoder() or something like
> > that.
> >
> >>
> >> > Currently most places expect an
> >> > enum pipe when dealing with PCH transcoders, and enum transcoder
> >> > when dealing with CPU transcoders. But there are some exceptions
> >> > of course.
> >>
> >> cheers,
> >> grant
> >> >
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc: Dump the GuC stage descriptor pool in debugfs

[Oscar Mateo]

We are missing pieces of information that could be useful for GuC
debugging.

Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 61 +
 1 file changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470..a05a67d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2540,6 +2540,66 @@ static int i915_guc_info(struct seq_file *m, void *data)
return 0;
 }
 
+static int i915_guc_stage_pool(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   const struct intel_guc *guc = _priv->guc;
+   struct guc_stage_desc *desc = guc->stage_desc_pool_vaddr;
+   struct i915_guc_client *client = guc->execbuf_client;
+   unsigned int tmp;
+   int index;
+
+   if (!client) {
+   seq_printf(m, "GuC submission %s\n",
+  HAS_GUC(dev_priv) ?
+  "disabled" :
+  "not supported");
+   return 0;
+   }
+
+   for (index = 0; index < GUC_MAX_STAGE_DESCRIPTORS; index++, desc++) {
+   struct intel_engine_cs *engine;
+
+   if (!(desc->attribute & GUC_STAGE_DESC_ATTR_ACTIVE))
+   continue;
+
+   seq_printf(m, "GuC stage descriptor %u:\n", index);
+   seq_printf(m, "\tIndex: %u\n", desc->stage_id);
+   seq_printf(m, "\tAttribute: 0x%x\n", desc->attribute);
+   seq_printf(m, "\tPriority: %d\n", desc->priority);
+   seq_printf(m, "\tDoorbell id: %d\n", desc->db_id);
+   seq_printf(m, "\tEngines used: 0x%x\n",
+  desc->engines_used);
+   seq_printf(m, "\tDoorbell trigger phy: 0x%llx, cpu: 0x%llx, uK: 
0x%x\n",
+  desc->db_trigger_phy,
+  desc->db_trigger_cpu,
+  desc->db_trigger_uk);
+   seq_printf(m, "\tProcess descriptor: 0x%x\n",
+  desc->process_desc);
+   seq_printf(m, "\tWorkqueue adddress: 0x%x, size: 0x%x\n",
+  desc->wq_addr, desc->wq_size);
+   seq_putc(m, '\n');
+
+   for_each_engine_masked(engine, dev_priv, client->engines, tmp) {
+   uint32_t guc_engine_id = engine->guc_id;
+   struct guc_execlist_context *lrc =
+   >lrc[guc_engine_id];
+
+   seq_printf(m, "\t%s LRC:\n", engine->name);
+   seq_printf(m, "\t\tContext desc: 0x%x\n",
+  lrc->context_desc);
+   seq_printf(m, "\t\tContext id: 0x%x\n", 
lrc->context_id);
+   seq_printf(m, "\t\tLRCA: 0x%x\n", lrc->ring_lrca);
+   seq_printf(m, "\t\tRing begin: 0x%x\n", 
lrc->ring_begin);
+   seq_printf(m, "\t\tRing end: 0x%x\n", lrc->ring_end);
+   seq_putc(m, '\n');
+
+   }
+   }
+
+   return 0;
+}
+
 static int i915_guc_log_dump(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4774,6 +4834,7 @@ static int i915_hpd_storm_ctl_open(struct inode *inode, 
struct file *file)
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+   {"i915_guc_stage_pool", i915_guc_stage_pool, 0},
{"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/15] drm/i915: Simplify cursor register write sequence

[Imre Deak]

On Mon, Mar 27, 2017 at 09:55:46PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> It looks like simply writing all the cursor register every single
> time might be slightly faster than checking to see of each of
> them need to be written. So if any other register apart from
> CURPOS needs to be written let's just write all the registers.
> 
> CURPOS is left as a special case mainly for 845/865 where we have to
> disable the cursor to change many of the cursor parameters. This
> introduces a slight chance of the cursor flickering when things get
> updated (since we're not currently doing the vblank evade for cursor
> updates). If we write CURPOS alone then that obviously can't happen.
> And let's follow the same pattern in the i9xx code just for symmetry.
> I wasn't able to see a singificant performance difference between
> this and just writing all the registers unconditionally.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 69 
> ++--
>  1 file changed, 34 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d78ab0d35274..40ac0f938a4e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9323,36 +9323,28 @@ static void i845_update_cursor(struct intel_plane 
> *plane,
>  
>   spin_lock_irqsave(_priv->uncore.lock, irqflags);
>  
> - if (plane->cursor.cntl != 0 &&
> - (plane->cursor.base != base ||
> -  plane->cursor.size != size ||
> -  plane->cursor.cntl != cntl)) {
> - /* On these chipsets we can only modify the base/size/stride
> -  * whilst the cursor is disabled.
> -  */
> + /* On these chipsets we can only modify the base/size/stride
> +  * whilst the cursor is disabled.
> +  */
> + if (plane->cursor.base != base ||
> + plane->cursor.size != size ||
> + plane->cursor.cntl != cntl) {
>   I915_WRITE_FW(CURCNTR(PIPE_A), 0);
> - plane->cursor.cntl = 0;
> - }
> -
> - if (plane->cursor.base != base)
>   I915_WRITE_FW(CURBASE(PIPE_A), base);
> -
> - if (plane->cursor.size != size)
>   I915_WRITE_FW(CURSIZE, size);
> -
> - if (cntl)
>   I915_WRITE_FW(CURPOS(PIPE_A), pos);
> -
> - if (plane->cursor.cntl != cntl)
>   I915_WRITE_FW(CURCNTR(PIPE_A), cntl);
>  
> + plane->cursor.base = base;
> + plane->cursor.size = size;
> + plane->cursor.cntl = cntl;
> + } else {
> + I915_WRITE_FW(CURPOS(PIPE_A), pos);
> + }
> +
>   POSTING_READ_FW(CURCNTR(PIPE_A));
>  
>   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> -
> - plane->cursor.cntl = cntl;
> - plane->cursor.base = base;
> - plane->cursor.size = size;
>  }
>  
>  static void i845_disable_cursor(struct intel_plane *plane,
> @@ -9508,27 +9500,34 @@ static void i9xx_update_cursor(struct intel_plane 
> *plane,
>  
>   spin_lock_irqsave(_priv->uncore.lock, irqflags);
>  
> - if (plane->cursor.cntl != cntl)
> + /*
> +  * On some platforms writing CURCNTR first will also
> +  * cause CURPOS to be armed by the CURBASE write.
> +  * Without the CURCNTR write the CURPOS write would
> +  * arm itself.
> +  *
> +  * CURCNTR and CUR_FBC_CTL are always
> +  * armed by the CURBASE write only.
> +  */
> + if (plane->cursor.base != base ||
> + plane->cursor.size != fbc_ctl ||
> + plane->cursor.cntl != cntl) {
>   I915_WRITE_FW(CURCNTR(pipe), cntl);
> -
> - if (plane->cursor.size != fbc_ctl)
> - I915_WRITE_FW(CUR_FBC_CTL(pipe), fbc_ctl);
> -
> - if (cntl)
> + if (HAS_CUR_FBC(dev_priv))
> + I915_WRITE_FW(CUR_FBC_CTL(pipe), fbc_ctl);
>   I915_WRITE_FW(CURPOS(pipe), pos);
> -
> - if (plane->cursor.cntl != cntl ||
> - plane->cursor.size != fbc_ctl ||
> - plane->cursor.base != base)
>   I915_WRITE_FW(CURBASE(pipe), base);
>  
> + plane->cursor.base = base;
> + plane->cursor.size = fbc_ctl;
> + plane->cursor.cntl = cntl;
> + } else {
> + I915_WRITE_FW(CURPOS(pipe), pos);
> + }
> +
>   POSTING_READ_FW(CURBASE(pipe));
>  
>   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> -
> - plane->cursor.cntl = cntl;
> - plane->cursor.base = base;
> - plane->cursor.size = fbc_ctl;
>  }
>  
>  static void i9xx_disable_cursor(struct intel_plane *plane,
> -- 
> 2.10.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Kernel PSR Fix-ups

[Patchwork]

== Series Details ==

Series: Kernel PSR Fix-ups
URL   : https://patchwork.freedesktop.org/series/24049/
State : success

== Summary ==

Series 24049v1 Kernel PSR Fix-ups
https://patchwork.freedesktop.org/api/1.0/series/24049/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:432s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:531s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:456s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:577s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:456s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:456s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:489s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:428s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:527s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:402s
fi-bsw-n3050 failed to collect. IGT log at Patchwork_4633/fi-bsw-n3050/igt.log

fb550f86433515f36a0de161631541ec114581e3 drm-tip: 2017y-05m-05d-18h-33m-52s UTC 
integration manifest
46a8d3e drm/i915/psr: Account for sink CRC raciness on some panels
829bb88 drm/i915/edp: Be less aggressive about changing link config on eDP
a1d3407 drm/i915/psr: Clean-up intel_enable_source_psr1()
b74b07c drm/i915/edp: Allow alternate fixed mode for eDP if available.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4633/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Relax 845/865 CURBASE alignemnt requirement to 32 bytes

[Imre Deak]

On Mon, Mar 27, 2017 at 09:55:45PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Supposedly 845/865 require only 32 byte alignment for CURBASE. Let's
> relax the checks to allow that instead of demanding 4KiB alignment.
> This will allow cursor panning in 8 pixel units.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 420d306e31c9..d78ab0d35274 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2090,6 +2090,8 @@ static unsigned int intel_cursor_alignment(const struct 
> drm_i915_private *dev_pr
>   return 16 * 1024;
>   else if (IS_I85X(dev_priv))
>   return 256;
> + else if (IS_I845G(dev_priv) || IS_I865G(dev_priv))
> + return 32;
>   else
>   return 4 * 1024;
>  }
> -- 
> 2.10.2
> 
> ___
> 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

[Intel-gfx] [PATCH IGT 4/5] tests/kms_frontbuffer_tracking: Refactor to use IGT PSR library functions

[Jim Bride]

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Signed-off-by: Jim Bride 
---
 tests/kms_frontbuffer_tracking.c | 95 +---
 1 file changed, 10 insertions(+), 85 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index c24e4a8..839d296 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -327,28 +327,6 @@ drmModeModeInfo std_1024_mode = {
.name = "Custom 1024x768",
 };
 
-static drmModeModeInfoPtr get_connector_smallest_mode(drmModeConnectorPtr c)
-{
-   int i;
-   drmModeModeInfoPtr smallest = NULL;
-
-   for (i = 0; i < c->count_modes; i++) {
-   drmModeModeInfoPtr mode = >modes[i];
-
-   if (!smallest)
-   smallest = mode;
-
-   if (mode->hdisplay * mode->vdisplay <
-   smallest->hdisplay * smallest->vdisplay)
-   smallest = mode;
-   }
-
-   if (c->connector_type == DRM_MODE_CONNECTOR_eDP)
-   smallest = _1024_mode;
-
-   return smallest;
-}
-
 static drmModeConnectorPtr get_connector(uint32_t id)
 {
int i;
@@ -421,30 +399,6 @@ static void init_mode_params(struct modeset_params 
*params, uint32_t crtc_id,
params->sprite.h = 64;
 }
 
-static bool connector_get_mode(drmModeConnectorPtr c, drmModeModeInfoPtr *mode)
-{
-   *mode = NULL;
-
-   if (c->connection != DRM_MODE_CONNECTED || !c->count_modes)
-   return false;
-
-   if (c->connector_type == DRM_MODE_CONNECTOR_eDP && opt.no_edp)
-   return false;
-
-   if (opt.small_modes)
-   *mode = get_connector_smallest_mode(c);
-   else
-   *mode = >modes[0];
-
-/* On HSW the CRC WA is so awful that it makes you think everything is
- * bugged. */
-   if (IS_HASWELL(intel_get_drm_devid(drm.fd)) &&
-   c->connector_type == DRM_MODE_CONNECTOR_eDP)
-   *mode = _1024_mode;
-
-   return true;
-}
-
 static bool connector_supports_pipe_a(drmModeConnectorPtr connector)
 {
int i;
@@ -473,7 +427,7 @@ static bool find_connector(bool edp_only, bool pipe_a, 
uint32_t forbidden_id,
continue;
if (c->connector_id == forbidden_id)
continue;
-   if (!connector_get_mode(c, ))
+   if (!igt_psr_find_good_mode(c, ))
continue;
 
*ret_connector = c;
@@ -804,23 +758,6 @@ static void fbc_print_status(void)
igt_info("FBC status:\n%s\n", buf);
 }
 
-static bool psr_is_enabled(void)
-{
-   char buf[256];
-
-   debugfs_read("i915_edp_psr_status", buf);
-   return strstr(buf, "\nActive: yes\n") &&
-  strstr(buf, "\nHW Enabled & Active bit: yes\n");
-}
-
-static void psr_print_status(void)
-{
-   char buf[256];
-
-   debugfs_read("i915_edp_psr_status", buf);
-   igt_info("PSR status:\n%s\n", buf);
-}
-
 static struct timespec fbc_get_last_action(void)
 {
struct timespec ret = { 0, 0 };
@@ -926,15 +863,8 @@ static bool fbc_wait_until_enabled(void)
return igt_wait(fbc_is_enabled(), 2000, 1);
 }
 
-static bool psr_wait_until_enabled(void)
-{
-   return igt_wait(psr_is_enabled(), 5000, 1);
-}
-
 #define fbc_enable() igt_set_module_param_int("enable_fbc", 1)
 #define fbc_disable() igt_set_module_param_int("enable_fbc", 0)
-#define psr_enable() igt_set_module_param_int("enable_psr", 1)
-#define psr_disable() igt_set_module_param_int("enable_psr", 0)
 
 static void get_sink_crc(sink_crc_t *crc, bool mandatory)
 {
@@ -1180,7 +1110,7 @@ static void disable_features(const struct test_mode *t)
return;
 
fbc_disable();
-   psr_disable();
+   igt_psr_disable();
 }
 
 static void *busy_thread_func(void *data)
@@ -1547,14 +1477,6 @@ static void teardown_fbc(void)
 {
 }
 
-static bool psr_sink_has_support(void)
-{
-   char buf[256];
-
-   debugfs_read("i915_edp_psr_status", buf);
-   return strstr(buf, "Sink_Support: yes\n");
-}
-
 static void setup_psr(void)
 {
if (get_connector(prim_mode_params.connector_id)->connector_type !=
@@ -1563,7 +1485,7 @@ static void setup_psr(void)
return;
}
 
-   if (!psr_sink_has_support()) {
+   if (!igt_psr_sink_support(drm.fd)) {
igt_info("Can't test PSR: not supported by sink.\n");
return;
}
@@ -1717,12 +1639,15 @@ static int adjust_assertion_flags(const struct 
test_mode *t, int flags)
}   \
\
if (flags_ & ASSERT_PSR_ENABLED) {  \
-   if (!psr_wait_until_enabled()) {\
-   psr_print_status();  

[Intel-gfx] [PATCH IGT 5/5] tests/kms_fbcon_fbt: Refactor to use IGT PSR library functions

[Jim Bride]

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Signed-off-by: Jim Bride 
---
 tests/kms_fbcon_fbt.c| 56 
 tests/kms_psr_sink_crc.c | 36 +--
 2 files changed, 49 insertions(+), 43 deletions(-)

diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
index d009091..a45a528 100644
--- a/tests/kms_fbcon_fbt.c
+++ b/tests/kms_fbcon_fbt.c
@@ -103,8 +103,9 @@ static bool fbc_is_enabled(int fd)
return strstr(buf, "FBC enabled\n");
 }
 
-static bool fbc_wait_until_enabled(int fd)
+static bool fbc_wait_until_enabled(int fd, bool enabled)
 {
+   enabled = enabled;
return igt_wait(fbc_is_enabled(fd), 5000, 1);
 }
 
@@ -124,6 +125,13 @@ static void set_mode_for_one_screen(struct drm_info *drm, 
struct igt_fb *fb,
 
if (c->connection == DRM_MODE_CONNECTED && c->count_modes &&
connector_possible(c)) {
+   if (c->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   bool bret;
+
+   bret = igt_psr_find_good_mode(c, );
+   if (bret)
+   break;
+   }
mode = >modes[0];
break;
}
@@ -147,35 +155,9 @@ static void set_mode_for_one_screen(struct drm_info *drm, 
struct igt_fb *fb,
igt_assert_eq(rc, 0);
 }
 
-static bool psr_supported_on_chipset(int fd)
-{
-   char buf[256];
-
-   igt_debugfs_read(fd, "i915_edp_psr_status", buf);
-   return strstr(buf, "Sink_Support: yes\n");
-}
-
-static bool connector_can_psr(drmModeConnectorPtr connector)
-{
-   return (connector->connector_type == DRM_MODE_CONNECTOR_eDP);
-}
-
-static bool psr_is_enabled(int fd)
-{
-   char buf[256];
-
-   igt_debugfs_read(fd, "i915_edp_psr_status", buf);
-   return strstr(buf, "\nActive: yes\n");
-}
-
-static bool psr_wait_until_enabled(int fd)
-{
-   return igt_wait(psr_is_enabled(fd), 5000, 1);
-}
-
 struct feature {
bool (*supported_on_chipset)(int fd);
-   bool (*wait_until_enabled)(int fd);
+   bool (*wait_until_enabled)(int fd, bool status);
bool (*connector_possible_fn)(drmModeConnectorPtr connector);
const char *param_name;
 } fbc = {
@@ -184,9 +166,9 @@ struct feature {
.connector_possible_fn = connector_can_fbc,
.param_name = "enable_fbc",
 }, psr = {
-   .supported_on_chipset = psr_supported_on_chipset,
-   .wait_until_enabled = psr_wait_until_enabled,
-   .connector_possible_fn = connector_can_psr,
+   .supported_on_chipset = igt_psr_sink_support,
+   .wait_until_enabled = igt_psr_await_status,
+   .connector_possible_fn = igt_psr_valid_connector,
.param_name = "enable_psr",
 };
 
@@ -210,17 +192,17 @@ static void subtest(struct feature *feature, bool suspend)
 
kmstest_unset_all_crtcs(drm.fd, drm.res);
wait_user("Modes unset.");
-   igt_assert(!feature->wait_until_enabled(drm.fd));
+   igt_assert(!feature->wait_until_enabled(drm.fd, true));
 
set_mode_for_one_screen(, , feature->connector_possible_fn);
wait_user("Screen set.");
-   igt_assert(feature->wait_until_enabled(drm.fd));
+   igt_assert(feature->wait_until_enabled(drm.fd, true));
 
if (suspend) {
igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
  SUSPEND_TEST_NONE);
sleep(5);
-   igt_assert(feature->wait_until_enabled(drm.fd));
+   igt_assert(feature->wait_until_enabled(drm.fd, true));
}
 
igt_remove_fb(drm.fd, );
@@ -230,13 +212,13 @@ static void subtest(struct feature *feature, bool suspend)
sleep(3);
 
wait_user("Back to fbcon.");
-   igt_assert(!feature->wait_until_enabled(drm.fd));
+   igt_assert(!feature->wait_until_enabled(drm.fd, true));
 
if (suspend) {
igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
  SUSPEND_TEST_NONE);
sleep(5);
-   igt_assert(!feature->wait_until_enabled(drm.fd));
+   igt_assert(!feature->wait_until_enabled(drm.fd, true));
}
 }
 
@@ -266,7 +248,7 @@ igt_main
subtest(, true);
igt_subtest("psr-suspend")
subtest(, true);
-
+   
igt_fixture
teardown_environment();
 }
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 8d26b68..233cf60 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -70,7 +70,7 @@ typedef struct {
uint32_t crtc_id;
igt_display_t display;
drm_intel_bufmgr *bufmgr;
-   struct igt_fb fb_green, fb_white;
+   struct igt_fb fb_green, fb_white, fb_blue;;
igt_plane_t 

[Intel-gfx] [PATCH IGT 1/5] tests/kms_psr_sink_crc: Change assert_or_manual() to a macro

[Jim Bride]

Make assert_or_manual() a macro so that we get accurate line number
information when this assertion fails.

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Signed-off-by: Jim Bride 
---
 tests/kms_psr_sink_crc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index bd3fa5e..1a03719 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -278,11 +278,11 @@ static bool is_green(char *crc)
(bh & mask) == 0);
 }
 
-static void assert_or_manual(bool condition, const char *expected)
-{
-   igt_debug_manual_check("no-crc", expected);
-   igt_assert(igt_interactive_debug || condition);
-}
+#define assert_or_manual(condition, expected) \
+do {  \
+   igt_debug_manual_check("no-crc", expected);   \
+   igt_assert(igt_interactive_debug || condition);   \
+} while (0)
 
 static void run_test(data_t *data)
 {
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH IGT 3/5] tests/kms_psr_sink_crc: Refactor to use new PSR library primitives

[Jim Bride]

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Signed-off-by: Jim Bride 
---
 tests/kms_psr_sink_crc.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 1a03719..8d26b68 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -192,35 +192,22 @@ static void fill_render(data_t *data, uint32_t handle, 
unsigned char color)
gem_bo_busy(data->drm_fd, handle);
 }
 
-static bool psr_possible(data_t *data)
+static inline bool psr_possible(data_t *data)
 {
-   char buf[512];
-
-   igt_debugfs_read(data->drm_fd, "i915_edp_psr_status", buf);
-
return running_with_psr_disabled ||
-   strstr(buf, "Sink_Support: yes\n");
+   igt_psr_sink_support(data->drm_fd);
 }
 
-static bool psr_active(data_t *data)
+static inline bool psr_active(data_t *data)
 {
-   char buf[512];
-
-   igt_debugfs_read(data->drm_fd, "i915_edp_psr_status", buf);
-
return running_with_psr_disabled ||
-   strstr(buf, "HW Enabled & Active bit: yes\n");
+   igt_psr_active(data->drm_fd);
 }
 
-static bool wait_psr_entry(data_t *data)
+static inline bool wait_psr_entry(data_t *data)
 {
-   int timeout = 5;
-   while (timeout--) {
-   if (psr_active(data))
-   return true;
-   sleep(1);
-   }
-   return false;
+   return running_with_psr_disabled ||
+   igt_psr_await_status(data->drm_fd, true);
 }
 
 static void get_sink_crc(data_t *data, char *crc) {
@@ -517,6 +504,7 @@ int main(int argc, char *argv[])
drm_intel_bufmgr_gem_enable_reuse(data.bufmgr);
 
display_init();
+   igt_skip_on(!psr_possible());
}
 
igt_subtest("psr_basic") {
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH IGT 0/5] PSR IGT Test Fix-ups

[Jim Bride]

These patches, along with the kernel series at
https://patchwork.freedesktop.org/series/24049/ allow our PSR
IGT tests to run more predictably on HSW, SKL, and KBL.  These
patches depend on the kernel series in order to run properly.  On
the systems I have available the following sets of tests run and pass.
I expect that tests would also pass on BDW, but I don't have access to
a BDW system with a PSR panel.  I still see some very sporadic (every
few hundred tests executions or so) failures to read the sink CRC on
KBL, but it is much less common than what we were seeing in the past.

HSW:
* kms_psr_sink_crc (all)
* kms_frontbuffer_tracking (subtests psr-1p*, my system doesn't
have a FBC panel or a DP port)
* kms_fbcon_fbt (subtests psr*)

SKL and KBL:
* kms_psr_sink_crc (all)
* kms_frontbuffer_tracking (subtests psr* and fbcpsr*)
* kms_fbcon_fbt (all)

Jim Bride (5):
  tests/kms_psr_sink_crc: Change assert_or_manual() to a macro
  lib: Add PSR utility functions to igt library.
  tests/kms_psr_sink_crc: Refactor to use new PSR library primitives
  tests/kms_frontbuffer_tracking: Refactor to use IGT PSR library
functions
  tests/kms_fbcon_fbt: Refactor to use IGT PSR library functions

 lib/Makefile.sources |   2 +
 lib/igt.h|   1 +
 lib/igt_psr.c| 195 +++
 lib/igt_psr.h|  40 
 tests/kms_fbcon_fbt.c|  56 ---
 tests/kms_frontbuffer_tracking.c |  95 ++-
 tests/kms_psr_sink_crc.c |  74 ---
 7 files changed, 310 insertions(+), 153 deletions(-)
 create mode 100644 lib/igt_psr.c
 create mode 100644 lib/igt_psr.h

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH IGT 2/5] lib: Add PSR utility functions to igt library.

[Jim Bride]

Factor out some code that was replicated in three test utilities into
some new IGT library functions so that we are checking PSR status in
a consistent fashion across all of our PSR tests.

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Signed-off-by: Jim Bride 
---
 lib/Makefile.sources |   2 +
 lib/igt.h|   1 +
 lib/igt_psr.c| 195 +++
 lib/igt_psr.h|  40 +++
 4 files changed, 238 insertions(+)
 create mode 100644 lib/igt_psr.c
 create mode 100644 lib/igt_psr.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 6348487..0a8835b 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -83,6 +83,8 @@ lib_source_list = \
uwildmat/uwildmat.c \
igt_kmod.c  \
igt_kmod.h  \
+   igt_psr.c   \
+   igt_psr.h   \
$(NULL)
 
 if HAVE_CHAMELIUM
diff --git a/lib/igt.h b/lib/igt.h
index a97923e..7f52d6c 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -37,6 +37,7 @@
 #include "igt_gt.h"
 #include "igt_kms.h"
 #include "igt_pm.h"
+#include "igt_psr.h"
 #include "igt_stats.h"
 #include "igt_chamelium.h"
 #include "instdone.h"
diff --git a/lib/igt_psr.c b/lib/igt_psr.c
new file mode 100644
index 000..cfbd139
--- /dev/null
+++ b/lib/igt_psr.c
@@ -0,0 +1,195 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * SECTION:igt_psr
+ * @short_description: Panel Self Refresh helpers
+ * @title: Panel Self Refresh
+ * @include: igt.h
+ *
+ * This library provides various helpers to enable Panel Self Refresh,
+ * as well as to check the state of PSR on the system (enabled vs.
+ * disabled, active vs. inactive) or to wait for PSR to be active
+ * or inactive.
+ */
+
+/**
+ * igt_psr_source_support:
+ *
+ * Returns true if the source supports PSR.
+ */
+bool igt_psr_source_support(int fd)
+{
+   char buf[512];
+
+   igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+
+   return strstr(buf, "Source_OK: yes\n");
+}
+
+
+/**
+ * igt_psr_sink_support:
+ *
+ * Returns true if the current eDP panel supports PSR.
+ */
+bool igt_psr_sink_support(int fd)
+{
+   char buf[256];
+
+   igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+   return strstr(buf, "Sink_Support: yes\n");
+}
+
+/**
+ * igt_psr_possible:
+ *
+ * Returns true if both the source and sink support PSR.
+ */
+bool igt_psr_possible(int fd)
+{
+   char buf[512];
+
+   igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+
+   return igt_psr_source_support(fd) && igt_psr_sink_support(fd);
+}
+
+/**
+ * igt_psr_active:
+ *
+ * Returns true if PSR is active on the panel.
+ */
+bool igt_psr_active(int fd)
+{
+   char buf[512];
+   bool actret = false;
+   bool hwactret = false;
+
+   igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+   hwactret = (strstr(buf, "HW Enabled & Active bit: yes\n") != NULL);
+   actret = (strstr(buf, "Active: yes\n") != NULL);
+   igt_debug("hwactret: %s actret: %s\n", hwactret ? "true" : "false",
+actret ? "true" : "false");
+   return hwactret && actret;
+}
+
+/**
+ * igt_psr_await_status:
+ * @active: A boolean that causes the function to wait for PSR to activate
+ *  if set to true, or to wait for PSR to deactivate if false.
+ *
+ * Returns true if the requested condition is met.
+ */
+bool igt_psr_await_status(int fd, bool active)
+{
+   const int timeout = 10;
+   int count = 0;
+   while (count < timeout) {
+   if (igt_psr_active(fd) == active) {
+   igt_debug("PSR %s after %d seconds.\n",
+ active ? "Active" : "Inactive", count);
+

[Intel-gfx] [PATCH 4/4] drm/i915/psr: Account for sink CRC raciness on some panels

[Jim Bride]

According to the eDP spec, when the count field in TEST_SINK_MISC
increments then the six bytes of sink CRC information in the DPCD
should be valid.  Unfortunately, this doesn't seem to be the case
on some panels, and as a result we get some incorrect and inconsistent
values from the sink CRC DPCD locations at times.  This problem exhibits
itself more on faster processors (relative failure rates HSW < SKL < KBL.)
In order to try and account for this, we try a lot harder to read the sink
CRC until we get consistent values twice in a row before returning what we
read and delay for a time before trying to read.  We still see some
occasional failures, but reading the sink CRC is much more reliable,
particularly on SKL and KBL, with these changes than without.

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 14 +++--
 drivers/gpu/drm/i915/intel_dp.c | 57 -
 2 files changed, 61 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470..4902473 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2718,7 +2718,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
struct intel_dp *intel_dp = NULL;
-   int ret;
+   int ret, tries = 6;
u8 crc[6];
 
drm_modeset_lock_all(dev);
@@ -2738,9 +2738,17 @@ static int i915_sink_crc(struct seq_file *m, void *data)
 
intel_dp = enc_to_intel_dp(connector->base.state->best_encoder);
 
-   ret = intel_dp_sink_crc(intel_dp, crc);
-   if (ret)
+   memset(crc, 0, 6);
+   do {
+   ret = intel_dp_sink_crc(intel_dp, crc);
+   if (ret == -ETIMEDOUT)
+   usleep_range(500, 700);
+   } while ((ret == -ETIMEDOUT) && --tries);
+
+   if (ret != 0) {
+   seq_printf(m, "\n");
goto out;
+   }
 
seq_printf(m, "%02x%02x%02x%02x%02x%02x\n",
   crc[0], crc[1], crc[2],
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 06b8bd4..217bc06 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3877,13 +3877,15 @@ static int intel_dp_sink_crc_stop(struct intel_dp 
*intel_dp)
 
do {
intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
-
+   usleep_range(16700, 17000);
if (drm_dp_dpcd_readb(_dp->aux,
  DP_TEST_SINK_MISC, ) < 0) {
+   DRM_DEBUG_KMS("Could not read TEST_SINK_MISC\n");
ret = -EIO;
goto out;
}
count = buf & DP_TEST_COUNT_MASK;
+   DRM_DEBUG_KMS("PSR count is %d\n", count);
} while (--attempts && count);
 
if (attempts == 0) {
@@ -3928,6 +3930,8 @@ static int intel_dp_sink_crc_start(struct intel_dp 
*intel_dp)
}
 
intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+   usleep_range(16700, 17000);
+   DRM_DEBUG_KMS("PSR Successfully started sink CRC\n");
return 0;
 }
 
@@ -3939,21 +3943,30 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
*crc)
u8 buf;
int count, ret;
int attempts = 6;
+   u8 old_crc[6];
+
+   if (crc != NULL)
+   memset(crc, 0, 6);
+   else
+   return -ENOMEM;
 
ret = intel_dp_sink_crc_start(intel_dp);
-   if (ret)
+   if (ret) {
+   DRM_DEBUG_KMS("Could not start sink crc; ret %d\n", ret);
return ret;
+   }
 
do {
intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+   usleep_range(16700, 17000);
 
if (drm_dp_dpcd_readb(_dp->aux,
  DP_TEST_SINK_MISC, ) < 0) {
+   DRM_DEBUG_KMS("Cound not read TEST_SINK_MISC\n");
ret = -EIO;
goto stop;
}
count = buf & DP_TEST_COUNT_MASK;
-
} while (--attempts && count == 0);
 
if (attempts == 0) {
@@ -3962,11 +3975,41 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
*crc)
goto stop;
}
 
-   if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
-   ret = -EIO;
-   goto stop;
-   }
+   attempts = 6;
+   memset(old_crc, 0xFF, 6);
+   do {
+   intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+   usleep_range(16500, 17000);
+   if 

[Intel-gfx] [PATCH 2/4] drm/i915/psr: Clean-up intel_enable_source_psr1()

[Jim Bride]

On SKL+ there is a bit in SRD_CTL that software is not supposed to
modify, but we currently clobber that bit when we enable PSR.  In
order to preserve the value of that bit, go ahead and read SRD_CTL and
do a field-wise setting of the various bits that we need to initialize
before writing the register back out.  Additionally, go ahead and
explicitly disable single-frame update since we aren't currently
supporting it.

v2: Do a field-wise init on EDP_PSR_MAX_SLEEP_TIME even though we
always set it to the max value. (Rodrigo)

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Cc: Wayne Boyer 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 
 drivers/gpu/drm/i915/intel_psr.c | 21 +++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee8170c..3a63555 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3584,18 +3584,22 @@ enum {
 #define   EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES  (1<<25)
 #define   EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES  (2<<25)
 #define   EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES  (3<<25)
+#define   EDP_PSR_MAX_SLEEP_TIME_MASK   (0x1f<<20)
 #define   EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
 #define   EDP_PSR_SKIP_AUX_EXIT(1<<12)
 #define   EDP_PSR_TP1_TP2_SEL  (0<<11)
 #define   EDP_PSR_TP1_TP3_SEL  (1<<11)
+#define   EDP_PSR_TP2_TP3_TIME_MASK (3<<8)
 #define   EDP_PSR_TP2_TP3_TIME_500us   (0<<8)
 #define   EDP_PSR_TP2_TP3_TIME_100us   (1<<8)
 #define   EDP_PSR_TP2_TP3_TIME_2500us  (2<<8)
 #define   EDP_PSR_TP2_TP3_TIME_0us (3<<8)
+#define   EDP_PSR_TP1_TIME_MASK (0x3<<4)
 #define   EDP_PSR_TP1_TIME_500us   (0<<4)
 #define   EDP_PSR_TP1_TIME_100us   (1<<4)
 #define   EDP_PSR_TP1_TIME_2500us  (2<<4)
 #define   EDP_PSR_TP1_TIME_0us (3<<4)
+#define   EDP_PSR_IDLE_FRAME_MASK   (0xf<<0)
 #define   EDP_PSR_IDLE_FRAME_SHIFT 0
 
 #define EDP_PSR_AUX_CTL
_MMIO(dev_priv->psr_mmio_base + 0x10)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3780d0..068c382 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -280,17 +280,32 @@ static void intel_enable_source_psr1(struct intel_dp 
*intel_dp)
 * with the 5 or 6 idle patterns.
 */
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
-   uint32_t val = EDP_PSR_ENABLE;
+   uint32_t val = I915_READ(EDP_PSR_CTL);
 
+   val |= EDP_PSR_ENABLE;
+
+   val &= ~EDP_PSR_MAX_SLEEP_TIME_MASK;
val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
+
+   val &= ~EDP_PSR_IDLE_FRAME_MASK;
val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
 
+   val &= ~EDP_PSR_MIN_LINK_ENTRY_TIME_MASK;
if (IS_HASWELL(dev_priv))
val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
 
-   if (dev_priv->psr.link_standby)
+   if (dev_priv->psr.link_standby) {
val |= EDP_PSR_LINK_STANDBY;
 
+   /* SFU should only be enabled with link standby, but for
+* now we do not support it. */
+   val &= ~BDW_PSR_SINGLE_FRAME;
+   } else {
+   val &= ~EDP_PSR_LINK_STANDBY;
+   val &= ~BDW_PSR_SINGLE_FRAME;
+   }
+
+   val &= ~EDP_PSR_TP1_TIME_MASK;
if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
val |= EDP_PSR_TP1_TIME_2500us;
else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
@@ -300,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp 
*intel_dp)
else
val |= EDP_PSR_TP1_TIME_0us;
 
+   val &= ~EDP_PSR_TP2_TP3_TIME_MASK;
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR_TP2_TP3_TIME_2500us;
else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
@@ -309,6 +325,7 @@ static void intel_enable_source_psr1(struct intel_dp 
*intel_dp)
else
val |= EDP_PSR_TP2_TP3_TIME_0us;
 
+   val &= ~EDP_PSR_TP1_TP3_SEL;
if (intel_dp_source_supports_hbr2(intel_dp) &&
drm_dp_tps3_supported(intel_dp->dpcd))
val |= EDP_PSR_TP1_TP3_SEL;
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP

[Jim Bride]

This set of changes has some history to them.  There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec.  These changes were

5fa836a9d859 ("drm/i915: DP link training optimization")
4e96c97742f4 ("drm/i915: eDP link training optimization")

which were eventually hand-reverted by

34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")

in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915.  There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation.  The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes.  This patch, largely
based on

commit 4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
Author: Mika Kahola 
Date:   Wed Apr 29 09:17:39 2015 +0300
drm/i915: eDP link training optimization

puts the eDP portions of this patch back in place.  None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Cc: Manasi D Navare 
Cc: Mika Kahola 
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_dp.c   |  4 +++-
 drivers/gpu/drm/i915/intel_dp_link_training.c | 11 ++-
 drivers/gpu/drm/i915/intel_drv.h  |  2 ++
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d46f72d..06b8bd4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 27, 54 
};
  * If a CPU or PCH DP output is attached to an eDP panel, this function
  * will return true, and false otherwise.
  */
-static bool is_edp(struct intel_dp *intel_dp)
+bool is_edp(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 
@@ -4690,6 +4690,7 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
 
intel_dp->reset_link_params = false;
+   intel_dp->train_set_valid = false;
}
 
intel_dp_print_rates(intel_dp);
@@ -6052,6 +6053,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_dp_set_source_rates(intel_dp);
 
intel_dp->reset_link_params = true;
+   intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index b79c1c0..60233e2 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
 {
-   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+   if (!intel_dp->train_set_valid)
+   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
 }
@@ -162,6 +163,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
   DP_TRAINING_PATTERN_1 |
   DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+   intel_dp->train_set_valid = false;
return false;
}
 
@@ -174,21 +176,25 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
 
if (!intel_dp_get_link_status(intel_dp, link_status)) {
DRM_ERROR("failed to get link status\n");
+   intel_dp->train_set_valid = false;
return false;
}
 
if (drm_dp_clock_recovery_ok(link_status, 
intel_dp->lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
+   intel_dp->train_set_valid = is_edp(intel_dp);
return true;
}
 
  

[Intel-gfx] [PATCH 1/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.

[Jim Bride]

Some fixed resolution panels actually support more than one mode,
with the only thing different being the refresh rate.  Having this
alternate mode available to us is desirable, because it allows us to
test PSR on panels whose setup time at the preferred mode is too long.
With this patch we allow the use of the alternate mode if it's
available and it was specifically requested.

Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_dp.c| 34 +-
 drivers/gpu/drm/i915/intel_drv.h   |  2 ++
 drivers/gpu/drm/i915/intel_dsi.c   |  2 +-
 drivers/gpu/drm/i915/intel_dvo.c   |  2 +-
 drivers/gpu/drm/i915/intel_lvds.c  |  3 ++-
 drivers/gpu/drm/i915/intel_panel.c |  2 ++
 6 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 08834f7..d46f72d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1637,6 +1637,19 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
return bpp;
 }
 
+static bool intel_edp_compare_alt_mode(struct drm_display_mode *m1,
+  struct drm_display_mode *m2)
+{
+   return (m1->hdisplay == m2->hdisplay &&
+   m1->hsync_start == m2->hsync_start &&
+   m1->hsync_end == m2->hsync_end &&
+   m1->htotal == m2->htotal &&
+   m1->vdisplay == m2->vdisplay &&
+   m1->vsync_start == m2->vsync_start &&
+   m1->vsync_end == m2->vsync_end &&
+   m1->vtotal == m2->vtotal);
+}
+
 bool
 intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -1674,8 +1687,16 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_audio = intel_dp->has_audio && port != PORT_A;
 
if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
-   intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
-  adjusted_mode);
+   struct drm_display_mode *panel_mode =
+   intel_connector->panel.alt_fixed_mode;
+   struct drm_display_mode *req_mode = _config->base.mode;
+
+   if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
+   panel_mode = intel_connector->panel.fixed_mode;
+
+   drm_mode_debug_printmodeline(panel_mode);
+
+   intel_fixed_panel_mode(panel_mode, adjusted_mode);
 
if (INTEL_GEN(dev_priv) >= 9) {
int ret;
@@ -5829,6 +5850,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_display_mode *fixed_mode = NULL;
+   struct drm_display_mode *alt_fixed_mode = NULL;
struct drm_display_mode *downclock_mode = NULL;
bool has_dpcd;
struct drm_display_mode *scan;
@@ -5884,13 +5906,14 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
}
intel_connector->edid = edid;
 
-   /* prefer fixed mode from EDID if available */
+   /* prefer fixed mode from EDID if available, save an alt mode also */
list_for_each_entry(scan, >probed_modes, head) {
if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
fixed_mode = drm_mode_duplicate(dev, scan);
downclock_mode = intel_dp_drrs_init(
intel_connector, fixed_mode);
-   break;
+   } else {
+   alt_fixed_mode = drm_mode_duplicate(dev, scan);
}
}
 
@@ -5927,7 +5950,8 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
  pipe_name(pipe));
}
 
-   intel_panel_init(_connector->panel, fixed_mode, downclock_mode);
+   intel_panel_init(_connector->panel, fixed_mode, alt_fixed_mode,
+downclock_mode);
intel_connector->panel.backlight.power = intel_edp_backlight_power;
intel_panel_setup_backlight(connector, pipe);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 54f3ff8..19d0c8f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -265,6 +265,7 @@ struct intel_encoder {
 
 struct intel_panel {
struct drm_display_mode *fixed_mode;
+   struct drm_display_mode *alt_fixed_mode;
struct drm_display_mode *downclock_mode;
int fitting_mode;
 
@@ -1676,6 +1677,7 @@ void intel_overlay_reset(struct drm_i915_private 
*dev_priv);
 /* intel_panel.c */
 int intel_panel_init(struct intel_panel *panel,
 struct 

[Intel-gfx] [PATCH 0/4] Kernel PSR Fix-ups

[Jim Bride]

These patches, along with an upcoming series for IGT, enable our
PSR IGT tests to run reliably once again.  The first change
enables us to run the PSR tests on SKL and KBL RVP platforms,
whose panels have too slow of a setup time when running in their
preferred mode.  The second fixes a minor problem with the way that
we were initializing SRD_CTL that caused us to clobber a bit that we
are not supposed to change in that register on SKL and KBL.  The third
change re-introduces some changes to our link training code to be less
aggressive about changing link state for eDP, because PSR depends on
the link state being the same at PSR exit as it was at PSR entry.
The fourth change greatly increases the reliability of reading the
sink CRC generated by the eDP panel.  

Jim Bride (4):
  drm/i915/edp: Allow alternate fixed mode for eDP if available.
  drm/i915/psr: Clean-up intel_enable_source_psr1()
  drm/i915/edp: Be less aggressive about changing link config on eDP
  drm/i915/psr: Account for sink CRC raciness on some panels

 drivers/gpu/drm/i915/i915_debugfs.c   | 14 +++-
 drivers/gpu/drm/i915/i915_reg.h   |  4 ++
 drivers/gpu/drm/i915/intel_dp.c   | 95 +++
 drivers/gpu/drm/i915/intel_dp_link_training.c | 11 +++-
 drivers/gpu/drm/i915/intel_drv.h  |  4 ++
 drivers/gpu/drm/i915/intel_dsi.c  |  2 +-
 drivers/gpu/drm/i915/intel_dvo.c  |  2 +-
 drivers/gpu/drm/i915/intel_lvds.c |  3 +-
 drivers/gpu/drm/i915/intel_panel.c|  2 +
 drivers/gpu/drm/i915/intel_psr.c  | 21 +-
 10 files changed, 136 insertions(+), 22 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 13/15] drm/i915: Handle fb offset and src coordinates for cursors

[Imre Deak]

On Mon, Mar 27, 2017 at 09:55:44PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The cursor plane doesn't have any kind of source offset register, so
> the only form of panning possible is via a the base address register.
> The alignment required by CURBASE ranges from 32B to 16KiB depending
> on the platform. Let's make sure the user didn't ask for something
> we can't do.
> 
> Obviously this is impossible to hit via the legacy cursor ioctl since
> the src offsets are always 0, but via the plane/atomic ioctls the user
> can ask for pretty much anything so we have to deal with this.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 27 +--
>  1 file changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 3a1d7d6530ec..420d306e31c9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2396,11 +2396,17 @@ u32 intel_compute_tile_offset(int *x, int *y,
> const struct intel_plane_state *state,
> int plane)
>  {
> - const struct drm_i915_private *dev_priv = 
> to_i915(state->base.plane->dev);
> + struct intel_plane *intel_plane = to_intel_plane(state->base.plane);
> + struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
>   const struct drm_framebuffer *fb = state->base.fb;
>   unsigned int rotation = state->base.rotation;
>   int pitch = intel_fb_pitch(fb, plane, rotation);
> - u32 alignment = intel_surf_alignment(fb, plane);
> + u32 alignment;
> +
> + if (intel_plane->id == PLANE_CURSOR)
> + alignment = intel_cursor_alignment(dev_priv);
> + else
> + alignment = intel_surf_alignment(fb, plane);
>  
>   return _intel_compute_tile_offset(dev_priv, x, y, fb, plane, pitch,
> rotation, alignment);
> @@ -9149,6 +9155,8 @@ static u32 intel_cursor_base(const struct 
> intel_plane_state *plane_state)
>   else
>   base = intel_plane_ggtt_offset(plane_state);
>  
> + base += plane_state->main.offset;
> +
>   /* ILK+ do this automagically */
>   if (HAS_GMCH_DISPLAY(dev_priv) &&
>   plane_state->base.rotation & DRM_ROTATE_180)
> @@ -9194,6 +9202,8 @@ static int intel_check_cursor(struct intel_crtc_state 
> *crtc_state,
> struct intel_plane_state *plane_state)
>  {
>   const struct drm_framebuffer *fb = plane_state->base.fb;
> + int src_x, src_y;
> + u32 offset;
>   int ret;
>  
>   ret = drm_plane_helper_check_state(_state->base,
> @@ -9212,6 +9222,19 @@ static int intel_check_cursor(struct intel_crtc_state 
> *crtc_state,
>   return -EINVAL;
>   }
>  
> + src_x = plane_state->base.src_x >> 16;
> + src_y = plane_state->base.src_y >> 16;
> +
> + intel_add_fb_offsets(_x, _y, plane_state, 0);
> + offset = intel_compute_tile_offset(_x, _y, plane_state, 0);
> +
> + if (src_x != 0 || src_y != 0) {
> + DRM_DEBUG_KMS("Arbitrary cursor panning not supported\n");
> + return -EINVAL;
> + }
> +
> + plane_state->main.offset = offset;
> +
>   return 0;
>  }
>  
> -- 
> 2.10.2
> 
> ___
> 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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/guc: Get rid of the enable_guc_loading module parameter

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/guc: Get rid of the 
enable_guc_loading module parameter
URL   : https://patchwork.freedesktop.org/series/24048/
State : success

== Summary ==

Series 24048v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/24048/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:426s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:582s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:557s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:478s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:413s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:502s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:487s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:454s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:495s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:410s

fb550f86433515f36a0de161631541ec114581e3 drm-tip: 2017y-05m-05d-18h-33m-52s UTC 
integration manifest
90ca756 drm/i915/guc: Rename has_guc to has_uc
8b1782e drm/i915/guc: Get rid of the enable_guc_loading module parameter

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4632/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.

[Srivatsa, Anusha]

>-Original Message-
>From: Pandiyan, Dhinakaran
>Sent: Friday, May 5, 2017 1:35 PM
>To: Nikula, Jani 
>Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
>Taylor, Clinton A ; Srivatsa, Anusha
>
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.
>
>On Fri, 2017-05-05 at 19:50 +0300, Jani Nikula wrote:
>> On Fri, 05 May 2017, "Srivatsa, Anusha"  wrote:
>> >>-Original Message-
>> >>From: Nikula, Jani
>> >>Sent: Thursday, May 4, 2017 2:25 AM
>> >>To: Srivatsa, Anusha ; intel-
>> >>g...@lists.freedesktop.org
>> >>Cc: Vivi, Rodrigo ; Ville Syrjala
>> >>; Srivatsa, Anusha
>> >>
>> >>Subject: Re: [PATCH] drm/i915/cnp: Backlight support for CNP.
>> >>
>> >>On Wed, 03 May 2017, Anusha Srivatsa  wrote:
>> >>> From: Rodrigo Vivi 
>> >>>
>> >>> Split out BXT and CNP's setup_backlight(),enable_backlight(),
>> >>> disable_backlight() and hz_to_pwm() into two separate functions
>> >>> instead of reusing BXT function.
>> >>>
>> >>> Reuse set_backlight() and get_backlight() since they have no
>> >>> reference to the utility pin.
>> >>>
>> >>> v2: Reuse BXT functions with controller 0 instead of
>> >>> redefining it. (Jani).
>> >>> Use dev_priv->rawclk_freq instead of getting the value
>> >>> from SFUSE_STRAP.
>> >>> v3: Avoid setup backligh controller along with hooks and
>> >>> fully reuse hooks setup as suggested by Jani.
>> >>> v4: Clean up commit message.
>> >>> v5: Implement per PCH instead per platform.
>> >>>
>> >>> v6: Introduce a new function for CNP.(Jani and Ville)
>> >>>
>> >>> v7: Squash the all CNP Backlight support patches into a single patch.
>> >>> (Jani)
>> >>>
>> >>> v8: Correct indentation, remove unneeded blank lines and correct
>> >>> mail address (Jani).
>> >>>
>> >>> Reviewed-by: Jani Nikula 
>> >>
>> >>Yup. What's the plan for merging the series, incl. this patch?
>> >
>> > Yes. This will be merged as part of CNP series.
>>
>> Of course, but what's the plan for merging the series?
>>
>> BR,
>> Jani.
>>
>
>This patch is 4/67 in Rodrigo's series. It makes sense to merge the top six 
>(CNP
>PCH) patches in Rodrigo's series and then focus on the rest after that. Out of 
>the
>top six, 6/67 still needs a R-B.
>
>Anusha, can you please rebase and submit Rodrigo's first six patches (replacing
>4/67 with this) ?
>
Will do.

Anusha
>-DK
>
>
>>
>> >
>> > Anusha
>> >>BR,
>> >>Jani.
>> >>
>> >>
>> >>> Suggested-by: Jani Nikula 
>> >>> Suggested-by: Ville Syrjala 
>> >>> Cc: Ville Syrjala 
>> >>> Cc: Jani Nikula 
>> >>> Signed-off-by: Anusha Srivatsa 
>> >>> Signed-off-by: Rodrigo Vivi 
>> >>> ---
>> >>>  drivers/gpu/drm/i915/intel_panel.c | 88
>> >>> +++---
>> >>>  1 file changed, 83 insertions(+), 5 deletions(-)
>> >>>
>> >>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> >>> b/drivers/gpu/drm/i915/intel_panel.c
>> >>> index 1978bec..8ee61c1 100644
>> >>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> >>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> >>> @@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct
>> >>intel_connector *connector)
>> >>>  }
>> >>>  }
>> >>>
>> >>> +static void cnp_disable_backlight(struct intel_connector
>> >>> +*connector) {
>> >>> +struct drm_i915_private *dev_priv = 
>> >>> to_i915(connector->base.dev);
>> >>> +struct intel_panel *panel = >panel;
>> >>> +u32 tmp, val;
>> >>> +
>> >>> +intel_panel_actually_set_backlight(connector, 0);
>> >>> +
>> >>> +tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>> >>> +I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
>> >>> +   tmp & ~BXT_BLC_PWM_ENABLE);
>> >>> +}
>> >>> +
>> >>>  static void pwm_disable_backlight(struct intel_connector
>> >>> *connector) {
>> >>>  struct intel_panel *panel = >panel; @@ -1076,6
>> >>> +1089,36 @@ static void bxt_enable_backlight(struct intel_connector
>*connector)
>> >>>  pwm_ctl | BXT_BLC_PWM_ENABLE);  }
>> >>>
>> >>> +static void cnp_enable_backlight(struct intel_connector *connector) {
>> >>> +struct drm_i915_private *dev_priv = 
>> >>> to_i915(connector->base.dev);
>> >>> +struct intel_panel *panel = >panel;
>> >>> +enum pipe pipe = intel_get_pipe_from_connector(connector);
>> >>> +u32 pwm_ctl, val;
>> >>> +
>> >>> +pwm_ctl = 
>> >>> I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>> >>> +if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
>> >>> +DRM_DEBUG_KMS("backlight 

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.

[Pandiyan, Dhinakaran]

On Fri, 2017-05-05 at 19:50 +0300, Jani Nikula wrote:
> On Fri, 05 May 2017, "Srivatsa, Anusha"  wrote:
> >>-Original Message-
> >>From: Nikula, Jani
> >>Sent: Thursday, May 4, 2017 2:25 AM
> >>To: Srivatsa, Anusha ; intel-
> >>g...@lists.freedesktop.org
> >>Cc: Vivi, Rodrigo ; Ville Syrjala
> >>; Srivatsa, Anusha 
> >>
> >>Subject: Re: [PATCH] drm/i915/cnp: Backlight support for CNP.
> >>
> >>On Wed, 03 May 2017, Anusha Srivatsa  wrote:
> >>> From: Rodrigo Vivi 
> >>>
> >>> Split out BXT and CNP's setup_backlight(),enable_backlight(),
> >>> disable_backlight() and hz_to_pwm() into two separate functions
> >>> instead of reusing BXT function.
> >>>
> >>> Reuse set_backlight() and get_backlight() since they have no reference
> >>> to the utility pin.
> >>>
> >>> v2: Reuse BXT functions with controller 0 instead of
> >>> redefining it. (Jani).
> >>> Use dev_priv->rawclk_freq instead of getting the value
> >>> from SFUSE_STRAP.
> >>> v3: Avoid setup backligh controller along with hooks and
> >>> fully reuse hooks setup as suggested by Jani.
> >>> v4: Clean up commit message.
> >>> v5: Implement per PCH instead per platform.
> >>>
> >>> v6: Introduce a new function for CNP.(Jani and Ville)
> >>>
> >>> v7: Squash the all CNP Backlight support patches into a single patch.
> >>> (Jani)
> >>>
> >>> v8: Correct indentation, remove unneeded blank lines and correct mail
> >>> address (Jani).
> >>>
> >>> Reviewed-by: Jani Nikula 
> >>
> >>Yup. What's the plan for merging the series, incl. this patch?
> >
> > Yes. This will be merged as part of CNP series.
> 
> Of course, but what's the plan for merging the series?
> 
> BR,
> Jani.
> 

This patch is 4/67 in Rodrigo's series. It makes sense to merge the top
six (CNP PCH) patches in Rodrigo's series and then focus on the rest
after that. Out of the top six, 6/67 still needs a R-B.

Anusha, can you please rebase and submit Rodrigo's first six patches
(replacing 4/67 with this) ? 


-DK


> 
> >
> > Anusha
> >>BR,
> >>Jani.
> >>
> >>
> >>> Suggested-by: Jani Nikula 
> >>> Suggested-by: Ville Syrjala 
> >>> Cc: Ville Syrjala 
> >>> Cc: Jani Nikula 
> >>> Signed-off-by: Anusha Srivatsa 
> >>> Signed-off-by: Rodrigo Vivi 
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_panel.c | 88
> >>> +++---
> >>>  1 file changed, 83 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> >>> b/drivers/gpu/drm/i915/intel_panel.c
> >>> index 1978bec..8ee61c1 100644
> >>> --- a/drivers/gpu/drm/i915/intel_panel.c
> >>> +++ b/drivers/gpu/drm/i915/intel_panel.c
> >>> @@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct
> >>intel_connector *connector)
> >>>   }
> >>>  }
> >>>
> >>> +static void cnp_disable_backlight(struct intel_connector *connector)
> >>> +{
> >>> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> >>> + struct intel_panel *panel = >panel;
> >>> + u32 tmp, val;
> >>> +
> >>> + intel_panel_actually_set_backlight(connector, 0);
> >>> +
> >>> + tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
> >>> + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
> >>> +tmp & ~BXT_BLC_PWM_ENABLE);
> >>> +}
> >>> +
> >>>  static void pwm_disable_backlight(struct intel_connector *connector)
> >>> {
> >>>   struct intel_panel *panel = >panel; @@ -1076,6 +1089,36
> >>> @@ static void bxt_enable_backlight(struct intel_connector *connector)
> >>>   pwm_ctl | BXT_BLC_PWM_ENABLE);
> >>>  }
> >>>
> >>> +static void cnp_enable_backlight(struct intel_connector *connector) {
> >>> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> >>> + struct intel_panel *panel = >panel;
> >>> + enum pipe pipe = intel_get_pipe_from_connector(connector);
> >>> + u32 pwm_ctl, val;
> >>> +
> >>> + pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
> >>> + if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
> >>> + DRM_DEBUG_KMS("backlight already enabled\n");
> >>> + pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
> >>> + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
> >>> +pwm_ctl);
> >>> + }
> >>> +
> >>> + I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
> >>> +panel->backlight.max);
> >>> +
> >>> + intel_panel_actually_set_backlight(connector,
> >>> +panel->backlight.level);
> >>> +
> >>> + pwm_ctl = 0;
> >>> + if (panel->backlight.active_low_pwm)
> >>> + pwm_ctl |= BXT_BLC_PWM_POLARITY;
> >>> +
> >>> + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
> >>> + 

Re: [Intel-gfx] [PATCH RFC 2/2] drm/i915/guc: Rename has_guc to has_uc

[Srivatsa, Anusha]

>-Original Message-
>From: Mateo Lozano, Oscar
>Sent: Friday, May 5, 2017 6:23 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Mateo Lozano, Oscar ; Srivatsa, Anusha
>; Ceraolo Spurio, Daniele
>; Chris Wilson ;
>Hiler, Arkadiusz 
>Subject: [PATCH RFC 2/2] drm/i915/guc: Rename has_guc to has_uc
>
>AFAIK, every platform with a HuC has a GuC and viceversa, so make it explicit.

I personally  like the  has_guc more than has_uc. It makes it easier while 
reading the code. But that my opinion. It is not a strong negation. If majority 
folks feel this is a cleaner approach then we can go ahead and change. 

Anusha 

>Cc: Anusha Srivatsa 
>Cc: Daniele Ceraolo Spurio 
>Cc: Chris Wilson 
>CC: Arkadiusz Hiler 
>Signed-off-by: Oscar Mateo 
>---
> drivers/gpu/drm/i915/i915_debugfs.c |  6 +++---
> drivers/gpu/drm/i915/i915_drv.h |  6 +++---
> drivers/gpu/drm/i915/i915_pci.c | 10 +-
> drivers/gpu/drm/i915/intel_guc_loader.c |  4 ++--
> drivers/gpu/drm/i915/intel_huc.c|  3 +--
> drivers/gpu/drm/i915/intel_pm.c |  2 +-
> drivers/gpu/drm/i915/intel_uc.c |  2 +-
> 7 files changed, 16 insertions(+), 17 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>b/drivers/gpu/drm/i915/i915_debugfs.c
>index e030b41..4538a5b 100644
>--- a/drivers/gpu/drm/i915/i915_debugfs.c
>+++ b/drivers/gpu/drm/i915/i915_debugfs.c
>@@ -2366,7 +2366,7 @@ static int i915_huc_load_status_info(struct seq_file
>*m, void *data)
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
>   struct intel_uc_fw *huc_fw = _priv->huc.fw;
>
>-  if (!HAS_GUC(dev_priv)) {
>+  if (!HAS_UC(dev_priv)) {
>   seq_puts(m, "No HuC support in HW\n");
>   return 0;
>   }
>@@ -2401,7 +2401,7 @@ static int i915_guc_load_status_info(struct seq_file
>*m, void *data)
>   struct intel_uc_fw *guc_fw = _priv->guc.fw;
>   u32 tmp, i;
>
>-  if (!HAS_GUC(dev_priv)) {
>+  if (!HAS_UC(dev_priv)) {
>   seq_puts(m, "No GuC support in HW\n");
>   return 0;
>   }
>@@ -2508,7 +2508,7 @@ static int i915_guc_info(struct seq_file *m, void *data)
>
>   if (!guc->execbuf_client) {
>   seq_printf(m, "GuC submission %s\n",
>- HAS_GUC(dev_priv) ?
>+ HAS_UC(dev_priv) ?
>  "disabled" :
>  "not supported");
>   return 0;
>diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index 5d00120..a4d4ac6 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -820,7 +820,7 @@ struct intel_csr {
>   func(has_full_48bit_ppgtt); \
>   func(has_gmbus_irq); \
>   func(has_gmch_display); \
>-  func(has_guc); \
>+  func(has_uc); \
>   func(has_hotplug); \
>   func(has_l3_dpf); \
>   func(has_llc); \
>@@ -2921,7 +2921,7 @@ static inline struct scatterlist *__sg_next(struct
>scatterlist *sg)  #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)-
>>info.has_runtime_pm)  #define HAS_64BIT_RELOC(dev_priv) ((dev_priv)-
>>info.has_64bit_reloc)
>
>-#define HAS_GUC(dev_priv) ((dev_priv)->info.has_guc)
>+#define HAS_UC(dev_priv)  ((dev_priv)->info.has_uc)
> #define HAS_GUC_UCODE(dev_priv)   ((dev_priv)->guc.fw.path != NULL)
> #define HAS_HUC_UCODE(dev_priv)   ((dev_priv)->huc.fw.path != NULL)
>
>@@ -2930,7 +2930,7 @@ static inline struct scatterlist *__sg_next(struct
>scatterlist *sg)
>  * to enable GuC submission or we need it to to validate a HuC firmware
>  */
> #define NEEDS_GUC_LOADING(dev_priv) \
>-  (HAS_GUC(dev_priv) && \
>+  (HAS_UC(dev_priv) && \
>   (i915.enable_guc_submission || HAS_HUC_UCODE(dev_priv)))
>
> #define HAS_RESOURCE_STREAMER(dev_priv) ((dev_priv)-
>>info.has_resource_streamer)
>diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
>index f80db2c..261ed3a 100644
>--- a/drivers/gpu/drm/i915/i915_pci.c
>+++ b/drivers/gpu/drm/i915/i915_pci.c
>@@ -352,7 +352,7 @@
>   .platform = INTEL_SKYLAKE,
>   .gen = 9,
>   .has_csr = 1,
>-  .has_guc = 1,
>+  .has_uc = 1,
>   .ddb_size = 896,
> };
>
>@@ -361,7 +361,7 @@
>   .platform = INTEL_SKYLAKE,
>   .gen = 9,
>   .has_csr = 1,
>-  .has_guc = 1,
>+  .has_uc = 1,
>   .ddb_size = 896,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING |
>BSD2_RING,  }; @@ -384,7 +384,7 @@
>   .has_dp_mst = 1, \
>   .has_gmbus_irq = 1, \
>   .has_logical_ring_contexts = 1, \
>-  .has_guc = 1, \
>+  .has_uc = 1, \
>   .has_decoupled_mmio = 1, \
>   .has_aliasing_ppgtt = 1, \
>   .has_full_ppgtt = 1, \

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Grant Grundler]

On Fri, May 5, 2017 at 1:08 PM, Ville Syrjälä
 wrote:
...
>> > I'm not convinced the patch is making things any better really. To
>> > fix this really properly, I think we'd need to introduce a new enum
>> > pch_transcoder and thus avoid the confusion of which type of
>> > transcoder we're talking about.
>>
>> Is an enum better than coding an explicit conversion in an inline function?
>
> The point of the enum would be to make it more clear which piece of
> hardware we're talking to in each case.

Ah ok - I misunderstood - I thought this was already the case.

> But this would require going
> through the entire PCH code and changing things to use the right type
> in each case. Quite a bit of work with little measurable gain I'd say.

IMHO, one of the best things that happened to C standard was addition
of strong type checking. It's helped prevent developers from making
one class of "stupid mistakes". So while this change wouldn't improve
performance, it would allow a form of automated correctness checking
that can be enforced with every patch you get (every time the code
base is compiled).

In other words, the gain isn't currently measurable the same way
performance is but I believe it's worth doing.  Given the number of
typedefs and enums in kernel code, I suspect most kernel developers
would agree.

cheers,
grant



>
>> Then the code can do some sanity checking as well. Something like:
>>
>> enum transcoder pch_to_cpu_enum(enum pipe)
>> {
>> WARN_ON(pipe > FOO);
>> return (enum transcoder) pipe;
>> }
>
> That would have to be called pipe_to_pch_transcoder() or something like
> that.
>
>>
>> > Currently most places expect an
>> > enum pipe when dealing with PCH transcoders, and enum transcoder
>> > when dealing with CPU transcoders. But there are some exceptions
>> > of course.
>>
>> cheers,
>> grant
>> >
>> > --
>> > Ville Syrjälä
>> > Intel OTC
>
> --
> 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] i915 I2C failures with recent chips and docking stations

[Ville Syrjälä]

On Fri, May 05, 2017 at 03:53:39AM -0400, Sanford Rockowitz wrote:
> I am the author of ddcutil (www.ddcutil.com), a Linux utility that
> manages monitor settings using DDC/CI. I am seeing a pattern of user
> error reports in which I2C communication is not working when a system
> with a recent Intel chip, using the i915 driver, is plugged into a
> docking station.  Communication works when the video cable is plugged
> directly into the laptop.   There also seems to be a correlation with
> whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is
> being executed), though this correlation is not as clear.

Apart from the MST issues already mentioned, I have noticed (at least
with some displays) that the DDC/CI slaves don't seem to do clock
stretching properly, and that the default 100kHz clock tends to be
too much for them. A while ago I tried to cook up some hacks to work
around these issues both in our i2c and i2c-over-aux code. The idea
was to just reduce the bus speed whenever DDC/CI is being attempted.

My hacks are here:
git://github.com/vsyrjala/linux.git i2c_bus_speed

But do note that I've not seem many DP dongles that actually support
the i2c bus speed control, so the usefulness of the i2c-over-aux
part of that code might be a little questionable. I also didn't
implement anything for the MST case, so those would still be using
whatever is the default bus speed.

-- 
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 RFC 2/2] drm/i915/guc: Rename has_guc to has_uc

[Oscar Mateo]

AFAIK, every platform with a HuC has a GuC and viceversa, so
make it explicit.

Cc: Anusha Srivatsa 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
CC: Arkadiusz Hiler 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  6 +++---
 drivers/gpu/drm/i915/i915_drv.h |  6 +++---
 drivers/gpu/drm/i915/i915_pci.c | 10 +-
 drivers/gpu/drm/i915/intel_guc_loader.c |  4 ++--
 drivers/gpu/drm/i915/intel_huc.c|  3 +--
 drivers/gpu/drm/i915/intel_pm.c |  2 +-
 drivers/gpu/drm/i915/intel_uc.c |  2 +-
 7 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e030b41..4538a5b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2366,7 +2366,7 @@ static int i915_huc_load_status_info(struct seq_file *m, 
void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_uc_fw *huc_fw = _priv->huc.fw;
 
-   if (!HAS_GUC(dev_priv)) {
+   if (!HAS_UC(dev_priv)) {
seq_puts(m, "No HuC support in HW\n");
return 0;
}
@@ -2401,7 +2401,7 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
struct intel_uc_fw *guc_fw = _priv->guc.fw;
u32 tmp, i;
 
-   if (!HAS_GUC(dev_priv)) {
+   if (!HAS_UC(dev_priv)) {
seq_puts(m, "No GuC support in HW\n");
return 0;
}
@@ -2508,7 +2508,7 @@ static int i915_guc_info(struct seq_file *m, void *data)
 
if (!guc->execbuf_client) {
seq_printf(m, "GuC submission %s\n",
-  HAS_GUC(dev_priv) ?
+  HAS_UC(dev_priv) ?
   "disabled" :
   "not supported");
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5d00120..a4d4ac6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -820,7 +820,7 @@ struct intel_csr {
func(has_full_48bit_ppgtt); \
func(has_gmbus_irq); \
func(has_gmch_display); \
-   func(has_guc); \
+   func(has_uc); \
func(has_hotplug); \
func(has_l3_dpf); \
func(has_llc); \
@@ -2921,7 +2921,7 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
 #define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
 
-#define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
+#define HAS_UC(dev_priv)   ((dev_priv)->info.has_uc)
 #define HAS_GUC_UCODE(dev_priv)((dev_priv)->guc.fw.path != NULL)
 #define HAS_HUC_UCODE(dev_priv)((dev_priv)->huc.fw.path != NULL)
 
@@ -2930,7 +2930,7 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
  * to enable GuC submission or we need it to to validate a HuC firmware
  */
 #define NEEDS_GUC_LOADING(dev_priv) \
-   (HAS_GUC(dev_priv) && \
+   (HAS_UC(dev_priv) && \
(i915.enable_guc_submission || HAS_HUC_UCODE(dev_priv)))
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f80db2c..261ed3a 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -352,7 +352,7 @@
.platform = INTEL_SKYLAKE,
.gen = 9,
.has_csr = 1,
-   .has_guc = 1,
+   .has_uc = 1,
.ddb_size = 896,
 };
 
@@ -361,7 +361,7 @@
.platform = INTEL_SKYLAKE,
.gen = 9,
.has_csr = 1,
-   .has_guc = 1,
+   .has_uc = 1,
.ddb_size = 896,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
@@ -384,7 +384,7 @@
.has_dp_mst = 1, \
.has_gmbus_irq = 1, \
.has_logical_ring_contexts = 1, \
-   .has_guc = 1, \
+   .has_uc = 1, \
.has_decoupled_mmio = 1, \
.has_aliasing_ppgtt = 1, \
.has_full_ppgtt = 1, \
@@ -412,7 +412,7 @@
.platform = INTEL_KABYLAKE,
.gen = 9,
.has_csr = 1,
-   .has_guc = 1,
+   .has_uc = 1,
.ddb_size = 896,
 };
 
@@ -421,7 +421,7 @@
.platform = INTEL_KABYLAKE,
.gen = 9,
.has_csr = 1,
-   .has_guc = 1,
+   .has_uc = 1,
.ddb_size = 896,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 762f0f2..ffe7fb5a 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -378,7 +378,7 @@ int intel_guc_init_hw(struct intel_guc *guc)
 void 

[Intel-gfx] [PATCH 1/2] drm/i915/guc: Get rid of the enable_guc_loading module parameter

[Oscar Mateo]

The decission to enable GuC loading shouldn't be left to the user.
Provided the HW supports the GuC, there are only two reasons to load it:

- The user has requested GuC submission.
- We have a HuC firmware available (so we need the GuC to validate it).

We leave the enable_guc_submission parameter untouched ("auto", "never",
"if supported", "required") but make its behavior a little bit more
consistent. Also, if not really required, we do not try to fetch any
firmware.

Cc: Anusha Srivatsa 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 10 --
 drivers/gpu/drm/i915/i915_drv.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h | 16 +
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  6 
 drivers/gpu/drm/i915/i915_params.h  |  2 --
 drivers/gpu/drm/i915/intel_guc_loader.c | 48 +++
 drivers/gpu/drm/i915/intel_huc.c|  5 +--
 drivers/gpu/drm/i915/intel_uc.c | 58 +
 drivers/gpu/drm/i915/intel_uc.h |  4 +--
 drivers/gpu/drm/i915/intel_uncore.c |  3 +-
 13 files changed, 82 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470..e030b41 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2366,8 +2366,10 @@ static int i915_huc_load_status_info(struct seq_file *m, 
void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_uc_fw *huc_fw = _priv->huc.fw;
 
-   if (!HAS_HUC_UCODE(dev_priv))
+   if (!HAS_GUC(dev_priv)) {
+   seq_puts(m, "No HuC support in HW\n");
return 0;
+   }
 
seq_puts(m, "HuC firmware status:\n");
seq_printf(m, "\tpath: %s\n", huc_fw->path);
@@ -2399,8 +2401,10 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
struct intel_uc_fw *guc_fw = _priv->guc.fw;
u32 tmp, i;
 
-   if (!HAS_GUC_UCODE(dev_priv))
+   if (!HAS_GUC(dev_priv)) {
+   seq_puts(m, "No GuC support in HW\n");
return 0;
+   }
 
seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
@@ -2504,7 +2508,7 @@ static int i915_guc_info(struct seq_file *m, void *data)
 
if (!guc->execbuf_client) {
seq_printf(m, "GuC submission %s\n",
-  HAS_GUC_SCHED(dev_priv) ?
+  HAS_GUC(dev_priv) ?
   "disabled" :
   "not supported");
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72fb47a..006ed91 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -996,7 +996,7 @@ static void intel_sanitize_options(struct drm_i915_private 
*dev_priv)
i915.semaphores = intel_sanitize_semaphores(dev_priv, i915.semaphores);
DRM_DEBUG_DRIVER("use GPU semaphores? %s\n", yesno(i915.semaphores));
 
-   intel_uc_sanitize_options(dev_priv);
+   intel_guc_sanitize_submission(dev_priv);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b20ed16..5d00120 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2921,15 +2921,17 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
 #define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
 
+#define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
+#define HAS_GUC_UCODE(dev_priv)((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv)((dev_priv)->huc.fw.path != NULL)
+
 /*
- * 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.
+ * Only two things require us to load the GuC firmware: either we want
+ * to enable GuC submission or we need it to to validate a HuC firmware
  */
-#define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
-#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
+#define NEEDS_GUC_LOADING(dev_priv) \
+   (HAS_GUC(dev_priv) && \
+   (i915.enable_guc_submission || HAS_HUC_UCODE(dev_priv)))
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

[Jani Nikula]

On Fri, 05 May 2017, Sanford Rockowitz  wrote:
> Last question (I think).   You wrote:
>
>> You'll want the DP MST I2C code fixed. Well, at least it's my *guess*
> that's where the problem is.
>
> Where do I go to post this problem?

Sorry, I could have added that in my previous reply!

https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and/or
dri-de...@lists.freedesktop.org. Please Cc me in either.

BR,
Jani.


>
> Thanks,
> Sanford
>
>
> On 05/05/2017 12:49 PM, Jani Nikula wrote:
>> On Fri, 05 May 2017, Sanford Rockowitz  wrote:
>>> Jani,
>>>
>>> Thanks for your quick and detailed response. 
>>>
>>> You wrote:
>>>
 The single DP link is divided to several logical links to sink devices.
>>> Suppose the dock has a DVI and/or HDMI connector.  Are those connectors
>>> logical sinks to a master DisplayPort connection, or do they have their
>>> own connection through the dock to the laptop?  If the former, then
>>> telling people to use a DVI or HDMI connection on the dock would not be
>>> a workaround.
>> If I understand you right, the former. The connections look like
>> independent DP sinks. (Even for DVI/HDMI; the conversion is in the dock
>> in DP MST based docks.)
>>
>>> ddcutil looks for displays by examining all non-SMBus /dev/i2c devices
>>> on the system.  If checks for the presence of slave address x50 and
>>> x37.  If they exist it tries to read the EDID on x50 and a Virtual
>>> Control Panel feature value on x37.
>> Seems like this should work.
>>
>>> Looking at one of the user logs, I see that a couple /dev/i2c-n
>>> devices have udev sysattr name DPMST.  When ddcutil probes those
>>> /dev/i2c devices, slave addresses x50 and x37 appear active, but
>>> reading the EDID fails. So it would seem that the i2c-dev driver is
>>> not properly handling DP-MST.  Does that interpretation seem correct?
>>> If so, I'll bounce the issue over to the I2C folks.
>> I think it's more likely the issue is in core drm DP MST code, and
>> nobody ever tried the I2C interface for them. The core I2C code should
>> be completely ignorant about DP MST, or even DP for that matter.
>>
>>> Alternatively, do the DP-MST devices present as some other userspace
>>> device that I can program to?  I imagine that searching udev for sysattr
>>> name DPMST would find any place in the /dev tree besides /dev/i2c where
>>> the devices are surfaced.   Would this be a bit-banging interface, or
>>> something at a higher level?  Or would I need to write a device driver?
>> You'll want the DP MST I2C code fixed. Well, at least it's my *guess*
>> that's where the problem is.
>>
>> BR,
>> Jani.
>>
>>>
>>> On 05/05/2017 05:59 AM, Jani Nikula wrote:
 On Fri, 05 May 2017, Sanford Rockowitz  wrote:
> I am the author of ddcutil (www.ddcutil.com), a Linux utility that
> manages monitor settings using DDC/CI. I am seeing a pattern of user
> error reports in which I2C communication is not working when a system
> with a recent Intel chip, using the i915 driver, is plugged into a
> docking station.  Communication works when the video cable is plugged
> directly into the laptop.   There also seems to be a correlation with
> whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is
> being executed), though this correlation is not as clear.
>
> I'm not sure how best to go about reporting these issues.  The usual bug
> reporting mechanism asks for detailed information about a specific
> system, which I don't have.   What I do have is the ability to see a
> pattern.
>
> Because I2C communication is so fragile (dependencies on hardware
> quirks, drivers, etc), ddcutil (which is written in C) has an extensive
> subsystem devoted to remotely diagnosing user configurations.  It
> already reports DDC (i.e. I2C) communication errors, and has interfaces
> to udev, libdrm, and x11 libraries.  If there is some i915 specific code
> I could add to refine the diagnosis, I would be happy to add that. 
> (Note: ddcutil is entirely a user space program, using the i2c-dev
> interface.)
>
> Suggestions on how to proceed appreciated.
 The issues are related to DP MST (Multi-Stream Transport) that the docks
 use nowadays. The single DP link is divided to several logical links to
 sink devices. The I2C communication needs to be encapsulated to remote
 I2C-over-AUX reads and writes, with the logical DP MST addresses, to
 route them to the correct sinks. In kernel, this is handled by the MST
 topology manager.

 Instead of using the I2C device directly for, say, card0-DP-1 or
 DPDDC-A, you need to be using the dynamically created and removed DP MST
 I2C devices that wrap the communications to remote I2C-over-AUX. Frankly
 I am not sure if the naming or parent/child relationships of the devices
 are quite right (based on looking at the code), 

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Ville Syrjälä]

On Fri, May 05, 2017 at 12:12:49PM -0700, Grant Grundler wrote:
> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
>  wrote:
> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> >> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> >>
> >> > In several instances the driver passes an 'enum pipe' value to a
> >> > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> >> > TRANSCODER_x have the same values this doesn't cause functional
> >> > problems. Still it is incorrect and causes clang to generate warnings
> >> > like this:
> >> >
> >> > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
> >> >   conversion from enumeration type 'enum transcoder' to different
> >> >   enumeration type 'enum pipe' [-Wenum-conversion]
> >> > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> >> >
> >> > Change the code to pass values of the type expected by the callee.
> >> >
> >> > Signed-off-by: Matthias Kaehlcke 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> >> >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
> >> >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
> >> >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
> >> >  4 files changed, 14 insertions(+), 8 deletions(-)
> >>
> >> Ping, any comments on this patch?
> >
> > I'm not convinced the patch is making things any better really. To
> > fix this really properly, I think we'd need to introduce a new enum
> > pch_transcoder and thus avoid the confusion of which type of
> > transcoder we're talking about.
> 
> Is an enum better than coding an explicit conversion in an inline function?

The point of the enum would be to make it more clear which piece of
hardware we're talking to in each case. But this would require going
through the entire PCH code and changing things to use the right type
in each case. Quite a bit of work with little measurable gain I'd say.

> Then the code can do some sanity checking as well. Something like:
> 
> enum transcoder pch_to_cpu_enum(enum pipe)
> {
> WARN_ON(pipe > FOO);
> return (enum transcoder) pipe;
> }

That would have to be called pipe_to_pch_transcoder() or something like
that.

> 
> > Currently most places expect an
> > enum pipe when dealing with PCH transcoders, and enum transcoder
> > when dealing with CPU transcoders. But there are some exceptions
> > of course.
> 
> cheers,
> grant
> >
> > --
> > Ville Syrjälä
> > Intel OTC

-- 
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] i915 I2C failures with recent chips and docking stations

[Sanford Rockowitz]

Last question (I think).   You wrote:

> You'll want the DP MST I2C code fixed. Well, at least it's my *guess*
that's where the problem is.

Where do I go to post this problem?

Thanks,
Sanford


On 05/05/2017 12:49 PM, Jani Nikula wrote:
> On Fri, 05 May 2017, Sanford Rockowitz  wrote:
>> Jani,
>>
>> Thanks for your quick and detailed response. 
>>
>> You wrote:
>>
>>> The single DP link is divided to several logical links to sink devices.
>> Suppose the dock has a DVI and/or HDMI connector.  Are those connectors
>> logical sinks to a master DisplayPort connection, or do they have their
>> own connection through the dock to the laptop?  If the former, then
>> telling people to use a DVI or HDMI connection on the dock would not be
>> a workaround.
> If I understand you right, the former. The connections look like
> independent DP sinks. (Even for DVI/HDMI; the conversion is in the dock
> in DP MST based docks.)
>
>> ddcutil looks for displays by examining all non-SMBus /dev/i2c devices
>> on the system.  If checks for the presence of slave address x50 and
>> x37.  If they exist it tries to read the EDID on x50 and a Virtual
>> Control Panel feature value on x37.
> Seems like this should work.
>
>> Looking at one of the user logs, I see that a couple /dev/i2c-n
>> devices have udev sysattr name DPMST.  When ddcutil probes those
>> /dev/i2c devices, slave addresses x50 and x37 appear active, but
>> reading the EDID fails. So it would seem that the i2c-dev driver is
>> not properly handling DP-MST.  Does that interpretation seem correct?
>> If so, I'll bounce the issue over to the I2C folks.
> I think it's more likely the issue is in core drm DP MST code, and
> nobody ever tried the I2C interface for them. The core I2C code should
> be completely ignorant about DP MST, or even DP for that matter.
>
>> Alternatively, do the DP-MST devices present as some other userspace
>> device that I can program to?  I imagine that searching udev for sysattr
>> name DPMST would find any place in the /dev tree besides /dev/i2c where
>> the devices are surfaced.   Would this be a bit-banging interface, or
>> something at a higher level?  Or would I need to write a device driver?
> You'll want the DP MST I2C code fixed. Well, at least it's my *guess*
> that's where the problem is.
>
> BR,
> Jani.
>
>>
>> On 05/05/2017 05:59 AM, Jani Nikula wrote:
>>> On Fri, 05 May 2017, Sanford Rockowitz  wrote:
 I am the author of ddcutil (www.ddcutil.com), a Linux utility that
 manages monitor settings using DDC/CI. I am seeing a pattern of user
 error reports in which I2C communication is not working when a system
 with a recent Intel chip, using the i915 driver, is plugged into a
 docking station.  Communication works when the video cable is plugged
 directly into the laptop.   There also seems to be a correlation with
 whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is
 being executed), though this correlation is not as clear.

 I'm not sure how best to go about reporting these issues.  The usual bug
 reporting mechanism asks for detailed information about a specific
 system, which I don't have.   What I do have is the ability to see a
 pattern.

 Because I2C communication is so fragile (dependencies on hardware
 quirks, drivers, etc), ddcutil (which is written in C) has an extensive
 subsystem devoted to remotely diagnosing user configurations.  It
 already reports DDC (i.e. I2C) communication errors, and has interfaces
 to udev, libdrm, and x11 libraries.  If there is some i915 specific code
 I could add to refine the diagnosis, I would be happy to add that. 
 (Note: ddcutil is entirely a user space program, using the i2c-dev
 interface.)

 Suggestions on how to proceed appreciated.
>>> The issues are related to DP MST (Multi-Stream Transport) that the docks
>>> use nowadays. The single DP link is divided to several logical links to
>>> sink devices. The I2C communication needs to be encapsulated to remote
>>> I2C-over-AUX reads and writes, with the logical DP MST addresses, to
>>> route them to the correct sinks. In kernel, this is handled by the MST
>>> topology manager.
>>>
>>> Instead of using the I2C device directly for, say, card0-DP-1 or
>>> DPDDC-A, you need to be using the dynamically created and removed DP MST
>>> I2C devices that wrap the communications to remote I2C-over-AUX. Frankly
>>> I am not sure if the naming or parent/child relationships of the devices
>>> are quite right (based on looking at the code), but you should find the
>>> sysfs name attribute will be DPMST. I'm also not sure how you can
>>> associate those with the physical devices you have.
>>>
>>> If you have an option to tell your tool which I2C device to use, that
>>> should get you started and debugging. If there are issues with that,
>>> please let us know.
>>>
>>> In the long run, we 

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

[Kenneth Graunke]

On Friday, May 5, 2017 9:21:54 AM PDT Dmitry Rogozhkin wrote:
> > My point largely stands, when redirected - someone is developing a
> > broken closed source userspace driver and is apparently unwilling to
> > change it.  That's the real problem.
> Broken? Have you ever attempted to run functional and performance 
> competitive between closed source and open source user space drivers? I 
> attempted and a number of others have attempted that. Result is that 
> open source driver has significantly worse encoding quality, worse to 
> the degree that any performance comparisons start to make no sense. 
> (Yep, work in progress to try to fix that, I know.) Decoding quality is 
> on par, but I saw cases when performance is 5-10% worse (and that's when 
> both drivers work on their presumably optimal settings). So, "broken" 
> closed source driver is in use for the _reason_. And which driver could 
> be considered "broken" after that: closed source one or open source one?

I'm not in any way arguing that one driver is superior to the other,
nor that anyone should do performance comparisons between the two.

> So, why you are addressing that closed source driver is broken? If it 
> will be put in the environment with the upstream kernel, then it will 
> eventually be broken and that's what we are trying to fix here. But do 
> you realize that in the production environment where the driver is 
> intended to work there is a patched kernel mode driver in place with the 
> MOCS settings to satisfy the need of the driver? Or you naively think we 
> use non-modified KMD from the upstream or previously released versions 
> from kernel.org. Bad guess! In the production environment driver is not 
> broken.

Yes, I'm aware that the closed source userspace relies on a patched
non-upstream kernel, and that it's being used in some environments.
Presumably it works just fine there.

Isn't the goal to make that userspace driver run on the upstream Linux
kernel, so people can use it in places other than the environment where
it currently exists?  Would it not make sense to have it run reasonably
well on upstream kernels that are currently shipping?

On released upstream kernels, there are only three MOCS entries: UC,
PTE, and WB.  Using any other entries is ill-advised (even broken),
not only because they currently correspond to UC (leading to poor
performance), but because they may change meaning in the future.

Future upstream kernels may add new entries, and presumably would
advertise that via a getparam (i.e. I915_PARAM_MOCS_TABLE_VERSION).

The suggestion is to make your userspace driver use entry 2 (WB)
for anything you want cached, when running on an upstream kernel
(but keep using the existing entries on the patched kernel).  That
would perform much better than it currently does.  You probably won't
get the full 60%, but perhaps you'll get 50%.

Then, add any additional entries you want to the kernel, advertise
it via a GETPARAM, and make your driver use those new entries when
they are supported.  Benchmark.  See how much faster your workload
is with the new entries (compared to WB-for-everything).  That's the
number everyone here wants to see.

This should be a trivial amount of work - nobody's asking for any
combinatorial explosion of testing.  Doing this exercise also means
that your software would perform better on currently shipping upstream
kernels (arguably improving the driver) - and once you have the full set
of entries, it will perform even better.

Does that make sense?

--Ken


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: capture GuC logs if FW fails to load (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: capture GuC logs if FW fails to load (rev2)
URL   : https://patchwork.freedesktop.org/series/23982/
State : success

== Summary ==

Series 23982v2 drm/i915/guc: capture GuC logs if FW fails to load
https://patchwork.freedesktop.org/api/1.0/series/23982/revisions/2/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:423s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:513s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:540s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:487s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:453s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:462s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:492s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:403s

fb550f86433515f36a0de161631541ec114581e3 drm-tip: 2017y-05m-05d-18h-33m-52s UTC 
integration manifest
b54719f drm/i915/guc: capture GuC logs if FW fails to load

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4631/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: capture GuC logs if FW fails to load

[Chris Wilson]

On Fri, May 05, 2017 at 10:45:47AM -0700, Daniele Ceraolo Spurio wrote:
> We're currently deleting the GuC logs if the FW fails to load, but those
> are still useful to understand why the loading failed. Keeping the
> object around allows us to access them after driver load is completed.
> 
> v2: keep the object around instead of using kernel memory (chris)
> don't store the logs in the gpu_error struct (Chris)
> add a check on guc_log_level to avoid snapshotting empty logs
> 
> Cc: Chris Wilson 
> Cc: Oscar Mateo 
> Cc: Michal Wajdeczko 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  | 30 ++
>  drivers/gpu/drm/i915/i915_drv.c  |  3 +++
>  drivers/gpu/drm/i915/intel_guc_log.c | 17 +
>  drivers/gpu/drm/i915/intel_uc.c  |  7 +--
>  drivers/gpu/drm/i915/intel_uc.h  |  5 +
>  5 files changed, 48 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 870c470..a37ab3b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2544,25 +2544,31 @@ static int i915_guc_log_dump(struct seq_file *m, void 
> *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
>   struct drm_i915_gem_object *obj;
> - int i = 0, pg;
> + u32 *log;
> + int i = 0;
>  
> - if (!dev_priv->guc.log.vma)
> + if (dev_priv->guc.log.vma)
> + obj = dev_priv->guc.log.vma->obj;
> + else if (dev_priv->guc.err_load_log)
> + obj = dev_priv->guc.err_load_log;
> + else
>   return 0;

Since both could be available at the same time, and to be clear which you
are reporting, I think you want a new debugfs entry.
-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 RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Grant Grundler]

On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
 wrote:
> On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>>
>> > In several instances the driver passes an 'enum pipe' value to a
>> > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
>> > TRANSCODER_x have the same values this doesn't cause functional
>> > problems. Still it is incorrect and causes clang to generate warnings
>> > like this:
>> >
>> > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
>> >   conversion from enumeration type 'enum transcoder' to different
>> >   enumeration type 'enum pipe' [-Wenum-conversion]
>> > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
>> >
>> > Change the code to pass values of the type expected by the callee.
>> >
>> > Signed-off-by: Matthias Kaehlcke 
>> > ---
>> >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>> >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
>> >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
>> >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
>> >  4 files changed, 14 insertions(+), 8 deletions(-)
>>
>> Ping, any comments on this patch?
>
> I'm not convinced the patch is making things any better really. To
> fix this really properly, I think we'd need to introduce a new enum
> pch_transcoder and thus avoid the confusion of which type of
> transcoder we're talking about.

Is an enum better than coding an explicit conversion in an inline function?
Then the code can do some sanity checking as well. Something like:

enum transcoder pch_to_cpu_enum(enum pipe)
{
WARN_ON(pipe > FOO);
return (enum transcoder) pipe;
}

> Currently most places expect an
> enum pipe when dealing with PCH transcoders, and enum transcoder
> when dealing with CPU transcoders. But there are some exceptions
> of course.

cheers,
grant
>
> --
> 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 12/15] drm/i915: Fix gen3 physical cursor alignment requirements

[Imre Deak]

On Mon, Mar 27, 2017 at 09:55:43PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Bspec tells us that gen3 platforms need 4KiB alignment for CURBASE
> rather than the 256 byte alignment required by i85x. Let's fix that
> and pull the code to determine the correct alignment to a helper
> function.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 53ec9d30437e..3a1d7d6530ec 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2084,6 +2084,16 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
>   }
>  }
>  
> +static unsigned int intel_cursor_alignment(const struct drm_i915_private 
> *dev_priv)
> +{
> + if (IS_I830(dev_priv))
> + return 16 * 1024;
> + else if (IS_I85X(dev_priv))
> + return 256;
> + else
> + return 4 * 1024;
> +}
> +
>  static unsigned int intel_linear_alignment(const struct drm_i915_private 
> *dev_priv)
>  {
>   if (INTEL_INFO(dev_priv)->gen >= 9)
> @@ -13329,7 +13339,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
>   if (obj) {
>   if (plane->type == DRM_PLANE_TYPE_CURSOR &&
>   INTEL_INFO(dev_priv)->cursor_needs_physical) {
> - const int align = IS_I830(dev_priv) ? 16 * 1024 : 256;
> + const int align = intel_cursor_alignment(dev_priv);
>  
>   ret = i915_gem_object_attach_phys(obj, align);
>   if (ret) {
> @@ -13641,7 +13651,7 @@ intel_legacy_cursor_update(struct drm_plane *plane,
>   goto out_free;
>  
>   if (INTEL_INFO(dev_priv)->cursor_needs_physical) {
> - int align = IS_I830(dev_priv) ? 16 * 1024 : 256;
> + int align = intel_cursor_alignment(dev_priv);
>  
>   ret = i915_gem_object_attach_phys(intel_fb_obj(fb), align);
>   if (ret) {
> -- 
> 2.10.2
> 
> ___
> 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

[Intel-gfx] [PATCH v6 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

[Puthikorn Voravootivat]

Add option to allow choosing how to adjust brightness if
panel supports both PWM pin and AUX channel.

Signed-off-by: Puthikorn Voravootivat 
---
Fix compile error in v5

 drivers/gpu/drm/i915/i915_params.c|  8 +---
 drivers/gpu/drm/i915/i915_params.h|  2 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 17 -
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..13cf3f1572ab 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
-   .enable_dpcd_backlight = false,
+   .enable_dpcd_backlight = -1,
.enable_gvt = false,
 };
 
@@ -246,9 +246,11 @@ MODULE_PARM_DESC(enable_dp_mst,
 module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint, 
0400);
 MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
-module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
0600);
 MODULE_PARM_DESC(enable_dpcd_backlight,
-   "Enable support for DPCD backlight control (default:false)");
+   "Enable support for DPCD backlight control "
+   "(-1:disable (default), 0:Use PWM pin if both supported, "
+   "1:Use DPCD if both supported");
 
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..ac02efce6e22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
-   func(bool, enable_dpcd_backlight); \
+   func(int, enable_dpcd_backlight); \
func(bool, enable_gvt)
 
 #define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 5b83c9737644..e82f7cb9a7af 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -175,11 +175,26 @@ intel_dp_aux_display_control_capable(struct 
intel_connector *connector)
return false;
 }
 
+static bool
+intel_dp_pwm_pin_display_control_capable(struct intel_connector *connector)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
+
+   /* Check the  eDP Display control capabilities registers to determine if
+* the panel can support backlight control via BL_PWM_DIM eDP pin
+*/
+   return intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP;
+}
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
 {
struct intel_panel *panel = _connector->panel;
 
-   if (!i915.enable_dpcd_backlight)
+   if (i915.enable_dpcd_backlight == -1)
+   return -ENODEV;
+
+   if (i915.enable_dpcd_backlight == 0 &&
+   intel_dp_pwm_pin_display_control_capable(intel_connector))
return -ENODEV;
 
if (!intel_dp_aux_display_control_capable(intel_connector))
-- 
2.13.0.rc1.294.g07d810a77f-goog

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/guc: capture GuC logs if FW fails to load

[Daniele Ceraolo Spurio]

We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Keeping the
object around allows us to access them after driver load is completed.

v2: keep the object around instead of using kernel memory (chris)
don't store the logs in the gpu_error struct (Chris)
add a check on guc_log_level to avoid snapshotting empty logs

Cc: Chris Wilson 
Cc: Oscar Mateo 
Cc: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 30 ++
 drivers/gpu/drm/i915/i915_drv.c  |  3 +++
 drivers/gpu/drm/i915/intel_guc_log.c | 17 +
 drivers/gpu/drm/i915/intel_uc.c  |  7 +--
 drivers/gpu/drm/i915/intel_uc.h  |  5 +
 5 files changed, 48 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470..a37ab3b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2544,25 +2544,31 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct drm_i915_gem_object *obj;
-   int i = 0, pg;
+   u32 *log;
+   int i = 0;
 
-   if (!dev_priv->guc.log.vma)
+   if (dev_priv->guc.log.vma)
+   obj = dev_priv->guc.log.vma->obj;
+   else if (dev_priv->guc.err_load_log)
+   obj = dev_priv->guc.err_load_log;
+   else
return 0;
 
-   obj = dev_priv->guc.log.vma->obj;
-   for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
-   u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));
-
-   for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
-   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
-  *(log + i), *(log + i + 1),
-  *(log + i + 2), *(log + i + 3));
-
-   kunmap_atomic(log);
+   log = i915_gem_object_pin_map(obj, I915_MAP_WC);
+   if (IS_ERR(log)) {
+   DRM_ERROR("Failed to pin guc_log object\n");
+   return PTR_ERR(log);
}
 
+   for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
+   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+  *(log + i), *(log + i + 1),
+  *(log + i + 2), *(log + i + 3));
+
seq_putc(m, '\n');
 
+   i915_gem_object_unpin_map(obj);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 452c265..d8c82ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1354,6 +1354,9 @@ void i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
i915_reset_error_state(dev_priv);
 
+   /* release GuC error log (if any) */
+   i915_guc_load_error_log_free(_priv->guc);
+
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
 
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 16d3b87..691da42 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -660,3 +660,20 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
guc_log_runtime_destroy(_priv->guc);
mutex_unlock(_priv->drm.struct_mutex);
 }
+
+void i915_guc_load_error_log_capture(struct intel_guc *guc)
+{
+   if (!guc->log.vma || i915.guc_log_level < 0)
+   return;
+
+   if (!guc->err_load_log)
+   guc->err_load_log = i915_gem_object_get(guc->log.vma->obj);
+
+   return;
+}
+
+void i915_guc_load_error_log_free(struct intel_guc *guc)
+{
+   if (guc->err_load_log)
+   i915_gem_object_put(guc->err_load_log);
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 7fd75ca..d66ffab 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -274,6 +274,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 
guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
+   i915_guc_load_error_log_free(guc);
 
/* We need to notify the guc whenever we change the GGTT */
i915_ggtt_enable_guc(dev_priv);
@@ -320,11 +321,11 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 
/* Did we succeded or run out of retries? */
if (ret)
-   goto err_submission;
+   goto err_log_capture;
 
ret = guc_enable_communication(guc);
if (ret)
-   goto err_submission;
+   goto err_log_capture;
 
intel_guc_auth_huc(dev_priv);
if (i915.enable_guc_submission) {

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Ville Syrjälä]

On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> 
> > In several instances the driver passes an 'enum pipe' value to a
> > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> > TRANSCODER_x have the same values this doesn't cause functional
> > problems. Still it is incorrect and causes clang to generate warnings
> > like this:
> > 
> > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
> >   conversion from enumeration type 'enum transcoder' to different
> >   enumeration type 'enum pipe' [-Wenum-conversion]
> > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> > 
> > Change the code to pass values of the type expected by the callee.
> > 
> > Signed-off-by: Matthias Kaehlcke 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
> >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
> >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
> >  4 files changed, 14 insertions(+), 8 deletions(-)
> 
> Ping, any comments on this patch?

I'm not convinced the patch is making things any better really. To
fix this really properly, I think we'd need to introduce a new enum 
pch_transcoder and thus avoid the confusion of which type of
transcoder we're talking about. Currently most places expect an 
enum pipe when dealing with PCH transcoders, and enum transcoder
when dealing with CPU transcoders. But there are some exceptions
of course.

-- 
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] drm/i915: Fix pipe/transcoder enum mismatches

[Matthias Kaehlcke]

El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:

> In several instances the driver passes an 'enum pipe' value to a
> function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> TRANSCODER_x have the same values this doesn't cause functional
> problems. Still it is incorrect and causes clang to generate warnings
> like this:
> 
> drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
>   conversion from enumeration type 'enum transcoder' to different
>   enumeration type 'enum pipe' [-Wenum-conversion]
> assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> 
> Change the code to pass values of the type expected by the callee.
> 
> Signed-off-by: Matthias Kaehlcke 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>  drivers/gpu/drm/i915/intel_dp.c  | 6 --
>  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
>  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
>  4 files changed, 14 insertions(+), 8 deletions(-)

Ping, any comments on this patch?

(also excuses for the unintended use of the RESEND tag)

Cheers

Matthias
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.

[Jani Nikula]

On Fri, 05 May 2017, "Srivatsa, Anusha"  wrote:
>>-Original Message-
>>From: Nikula, Jani
>>Sent: Thursday, May 4, 2017 2:25 AM
>>To: Srivatsa, Anusha ; intel-
>>g...@lists.freedesktop.org
>>Cc: Vivi, Rodrigo ; Ville Syrjala
>>; Srivatsa, Anusha 
>>Subject: Re: [PATCH] drm/i915/cnp: Backlight support for CNP.
>>
>>On Wed, 03 May 2017, Anusha Srivatsa  wrote:
>>> From: Rodrigo Vivi 
>>>
>>> Split out BXT and CNP's setup_backlight(),enable_backlight(),
>>> disable_backlight() and hz_to_pwm() into two separate functions
>>> instead of reusing BXT function.
>>>
>>> Reuse set_backlight() and get_backlight() since they have no reference
>>> to the utility pin.
>>>
>>> v2: Reuse BXT functions with controller 0 instead of
>>> redefining it. (Jani).
>>> Use dev_priv->rawclk_freq instead of getting the value
>>> from SFUSE_STRAP.
>>> v3: Avoid setup backligh controller along with hooks and
>>> fully reuse hooks setup as suggested by Jani.
>>> v4: Clean up commit message.
>>> v5: Implement per PCH instead per platform.
>>>
>>> v6: Introduce a new function for CNP.(Jani and Ville)
>>>
>>> v7: Squash the all CNP Backlight support patches into a single patch.
>>> (Jani)
>>>
>>> v8: Correct indentation, remove unneeded blank lines and correct mail
>>> address (Jani).
>>>
>>> Reviewed-by: Jani Nikula 
>>
>>Yup. What's the plan for merging the series, incl. this patch?
>
> Yes. This will be merged as part of CNP series.

Of course, but what's the plan for merging the series?

BR,
Jani.


>
> Anusha
>>BR,
>>Jani.
>>
>>
>>> Suggested-by: Jani Nikula 
>>> Suggested-by: Ville Syrjala 
>>> Cc: Ville Syrjala 
>>> Cc: Jani Nikula 
>>> Signed-off-by: Anusha Srivatsa 
>>> Signed-off-by: Rodrigo Vivi 
>>> ---
>>>  drivers/gpu/drm/i915/intel_panel.c | 88
>>> +++---
>>>  1 file changed, 83 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
>>> b/drivers/gpu/drm/i915/intel_panel.c
>>> index 1978bec..8ee61c1 100644
>>> --- a/drivers/gpu/drm/i915/intel_panel.c
>>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>>> @@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct
>>intel_connector *connector)
>>> }
>>>  }
>>>
>>> +static void cnp_disable_backlight(struct intel_connector *connector)
>>> +{
>>> +   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>>> +   struct intel_panel *panel = >panel;
>>> +   u32 tmp, val;
>>> +
>>> +   intel_panel_actually_set_backlight(connector, 0);
>>> +
>>> +   tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>>> +   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
>>> +  tmp & ~BXT_BLC_PWM_ENABLE);
>>> +}
>>> +
>>>  static void pwm_disable_backlight(struct intel_connector *connector)
>>> {
>>> struct intel_panel *panel = >panel; @@ -1076,6 +1089,36
>>> @@ static void bxt_enable_backlight(struct intel_connector *connector)
>>> pwm_ctl | BXT_BLC_PWM_ENABLE);
>>>  }
>>>
>>> +static void cnp_enable_backlight(struct intel_connector *connector) {
>>> +   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>>> +   struct intel_panel *panel = >panel;
>>> +   enum pipe pipe = intel_get_pipe_from_connector(connector);
>>> +   u32 pwm_ctl, val;
>>> +
>>> +   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>>> +   if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
>>> +   DRM_DEBUG_KMS("backlight already enabled\n");
>>> +   pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
>>> +   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
>>> +  pwm_ctl);
>>> +   }
>>> +
>>> +   I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
>>> +  panel->backlight.max);
>>> +
>>> +   intel_panel_actually_set_backlight(connector,
>>> +panel->backlight.level);
>>> +
>>> +   pwm_ctl = 0;
>>> +   if (panel->backlight.active_low_pwm)
>>> +   pwm_ctl |= BXT_BLC_PWM_POLARITY;
>>> +
>>> +   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
>>> +   POSTING_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>>> +   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
>>> +  pwm_ctl | BXT_BLC_PWM_ENABLE);
>>> +}
>>> +
>>>  static void pwm_enable_backlight(struct intel_connector *connector)
>>> {
>>> struct intel_panel *panel = >panel; @@ -1645,6 +1688,37
>>> @@ bxt_setup_backlight(struct intel_connector *connector, enum pipe
>>unused)
>>> return 0;
>>>  }
>>>
>>> +static int
>>> +cnp_setup_backlight(struct intel_connector *connector, enum pipe
>>> +unused) {
>>> +   struct drm_i915_private *dev_priv = 

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

[Jani Nikula]

On Fri, 05 May 2017, Sanford Rockowitz  wrote:
> Jani,
>
> Thanks for your quick and detailed response. 
>
> You wrote:
>
>> The single DP link is divided to several logical links to sink devices.
>
> Suppose the dock has a DVI and/or HDMI connector.  Are those connectors
> logical sinks to a master DisplayPort connection, or do they have their
> own connection through the dock to the laptop?  If the former, then
> telling people to use a DVI or HDMI connection on the dock would not be
> a workaround.

If I understand you right, the former. The connections look like
independent DP sinks. (Even for DVI/HDMI; the conversion is in the dock
in DP MST based docks.)

> ddcutil looks for displays by examining all non-SMBus /dev/i2c devices
> on the system.  If checks for the presence of slave address x50 and
> x37.  If they exist it tries to read the EDID on x50 and a Virtual
> Control Panel feature value on x37.

Seems like this should work.

> Looking at one of the user logs, I see that a couple /dev/i2c-n
> devices have udev sysattr name DPMST.  When ddcutil probes those
> /dev/i2c devices, slave addresses x50 and x37 appear active, but
> reading the EDID fails. So it would seem that the i2c-dev driver is
> not properly handling DP-MST.  Does that interpretation seem correct?
> If so, I'll bounce the issue over to the I2C folks.

I think it's more likely the issue is in core drm DP MST code, and
nobody ever tried the I2C interface for them. The core I2C code should
be completely ignorant about DP MST, or even DP for that matter.

> Alternatively, do the DP-MST devices present as some other userspace
> device that I can program to?  I imagine that searching udev for sysattr
> name DPMST would find any place in the /dev tree besides /dev/i2c where
> the devices are surfaced.   Would this be a bit-banging interface, or
> something at a higher level?  Or would I need to write a device driver?

You'll want the DP MST I2C code fixed. Well, at least it's my *guess*
that's where the problem is.

BR,
Jani.

>
>
> On 05/05/2017 05:59 AM, Jani Nikula wrote:
>> On Fri, 05 May 2017, Sanford Rockowitz  wrote:
>>> I am the author of ddcutil (www.ddcutil.com), a Linux utility that
>>> manages monitor settings using DDC/CI. I am seeing a pattern of user
>>> error reports in which I2C communication is not working when a system
>>> with a recent Intel chip, using the i915 driver, is plugged into a
>>> docking station.  Communication works when the video cable is plugged
>>> directly into the laptop.   There also seems to be a correlation with
>>> whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is
>>> being executed), though this correlation is not as clear.
>>>
>>> I'm not sure how best to go about reporting these issues.  The usual bug
>>> reporting mechanism asks for detailed information about a specific
>>> system, which I don't have.   What I do have is the ability to see a
>>> pattern.
>>>
>>> Because I2C communication is so fragile (dependencies on hardware
>>> quirks, drivers, etc), ddcutil (which is written in C) has an extensive
>>> subsystem devoted to remotely diagnosing user configurations.  It
>>> already reports DDC (i.e. I2C) communication errors, and has interfaces
>>> to udev, libdrm, and x11 libraries.  If there is some i915 specific code
>>> I could add to refine the diagnosis, I would be happy to add that. 
>>> (Note: ddcutil is entirely a user space program, using the i2c-dev
>>> interface.)
>>>
>>> Suggestions on how to proceed appreciated.
>> The issues are related to DP MST (Multi-Stream Transport) that the docks
>> use nowadays. The single DP link is divided to several logical links to
>> sink devices. The I2C communication needs to be encapsulated to remote
>> I2C-over-AUX reads and writes, with the logical DP MST addresses, to
>> route them to the correct sinks. In kernel, this is handled by the MST
>> topology manager.
>>
>> Instead of using the I2C device directly for, say, card0-DP-1 or
>> DPDDC-A, you need to be using the dynamically created and removed DP MST
>> I2C devices that wrap the communications to remote I2C-over-AUX. Frankly
>> I am not sure if the naming or parent/child relationships of the devices
>> are quite right (based on looking at the code), but you should find the
>> sysfs name attribute will be DPMST. I'm also not sure how you can
>> associate those with the physical devices you have.
>>
>> If you have an option to tell your tool which I2C device to use, that
>> should get you started and debugging. If there are issues with that,
>> please let us know.
>>
>> In the long run, we should probably do something to make the discovery
>> of the DP MST I2C devices easier, with naming and/or better parent/child
>> relationships of the devices. It's just that the userspace I2C interface
>> was probably pretty far down on the list of priorities when writing DP
>> MST.
>>
>>
>> BR,
>> Jani.
>>
>>
>
>

-- 
Jani Nikula, 

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.

[Srivatsa, Anusha]

>-Original Message-
>From: Nikula, Jani
>Sent: Thursday, May 4, 2017 2:25 AM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Cc: Vivi, Rodrigo ; Ville Syrjala
>; Srivatsa, Anusha 
>Subject: Re: [PATCH] drm/i915/cnp: Backlight support for CNP.
>
>On Wed, 03 May 2017, Anusha Srivatsa  wrote:
>> From: Rodrigo Vivi 
>>
>> Split out BXT and CNP's setup_backlight(),enable_backlight(),
>> disable_backlight() and hz_to_pwm() into two separate functions
>> instead of reusing BXT function.
>>
>> Reuse set_backlight() and get_backlight() since they have no reference
>> to the utility pin.
>>
>> v2: Reuse BXT functions with controller 0 instead of
>> redefining it. (Jani).
>> Use dev_priv->rawclk_freq instead of getting the value
>> from SFUSE_STRAP.
>> v3: Avoid setup backligh controller along with hooks and
>> fully reuse hooks setup as suggested by Jani.
>> v4: Clean up commit message.
>> v5: Implement per PCH instead per platform.
>>
>> v6: Introduce a new function for CNP.(Jani and Ville)
>>
>> v7: Squash the all CNP Backlight support patches into a single patch.
>> (Jani)
>>
>> v8: Correct indentation, remove unneeded blank lines and correct mail
>> address (Jani).
>>
>> Reviewed-by: Jani Nikula 
>
>Yup. What's the plan for merging the series, incl. this patch?

Yes. This will be merged as part of CNP series.

Anusha
>BR,
>Jani.
>
>
>> Suggested-by: Jani Nikula 
>> Suggested-by: Ville Syrjala 
>> Cc: Ville Syrjala 
>> Cc: Jani Nikula 
>> Signed-off-by: Anusha Srivatsa 
>> Signed-off-by: Rodrigo Vivi 
>> ---
>>  drivers/gpu/drm/i915/intel_panel.c | 88
>> +++---
>>  1 file changed, 83 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index 1978bec..8ee61c1 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct
>intel_connector *connector)
>>  }
>>  }
>>
>> +static void cnp_disable_backlight(struct intel_connector *connector)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>> +struct intel_panel *panel = >panel;
>> +u32 tmp, val;
>> +
>> +intel_panel_actually_set_backlight(connector, 0);
>> +
>> +tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>> +I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
>> +   tmp & ~BXT_BLC_PWM_ENABLE);
>> +}
>> +
>>  static void pwm_disable_backlight(struct intel_connector *connector)
>> {
>>  struct intel_panel *panel = >panel; @@ -1076,6 +1089,36
>> @@ static void bxt_enable_backlight(struct intel_connector *connector)
>>  pwm_ctl | BXT_BLC_PWM_ENABLE);
>>  }
>>
>> +static void cnp_enable_backlight(struct intel_connector *connector) {
>> +struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>> +struct intel_panel *panel = >panel;
>> +enum pipe pipe = intel_get_pipe_from_connector(connector);
>> +u32 pwm_ctl, val;
>> +
>> +pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>> +if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
>> +DRM_DEBUG_KMS("backlight already enabled\n");
>> +pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
>> +I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
>> +   pwm_ctl);
>> +}
>> +
>> +I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
>> +   panel->backlight.max);
>> +
>> +intel_panel_actually_set_backlight(connector,
>> +panel->backlight.level);
>> +
>> +pwm_ctl = 0;
>> +if (panel->backlight.active_low_pwm)
>> +pwm_ctl |= BXT_BLC_PWM_POLARITY;
>> +
>> +I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
>> +POSTING_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>> +I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
>> +   pwm_ctl | BXT_BLC_PWM_ENABLE);
>> +}
>> +
>>  static void pwm_enable_backlight(struct intel_connector *connector)
>> {
>>  struct intel_panel *panel = >panel; @@ -1645,6 +1688,37
>> @@ bxt_setup_backlight(struct intel_connector *connector, enum pipe
>unused)
>>  return 0;
>>  }
>>
>> +static int
>> +cnp_setup_backlight(struct intel_connector *connector, enum pipe
>> +unused) {
>> +struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>> +struct intel_panel *panel = >panel;
>> +u32 pwm_ctl, val;
>> +
>> +panel->backlight.controller = dev_priv->vbt.backlight.controller;
>> +
>> +pwm_ctl = 

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

[Ville Syrjälä]

On Fri, May 05, 2017 at 05:13:58PM +0100, Tvrtko Ursulin wrote:
> 
> On 05/05/2017 15:49, Ville Syrjälä wrote:
> > On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin 
> >>
> >> It seems that the DMC likes to transition between the DC states
> >> a lot when there are no connected displays (no active power
> >> domains) during simple command submission.
> >
> > Is it trapping on some interrupt register accesses or what? And
> > if so which registers are affected?
> 
> It looks like GT IIR or something along those lines it but I couldn't 
> say with total confidence.


for i in `seq 1 100` ; do IGT_NO_FORCEWAKE=1 intel_reg read  ; done


Should be a pretty trivial to run that against the suspect
registers.

> It is just a guess. Firmware binary 
> definitely "mentions" those registers as can be seen by inspecting it 
> with a hex editor.
> 
> The data I collected at least seems to present a correlation between the 
> batch frequency and DC state transition frequency:
> 
> tgt   DC  irqsirqs/s  irq batch/s DC/sDC/batch
> submittransitions /
> freq  batch
> 
> 1 2   78300   7830.00 1.964000.00 2000.00 0.50
> 9901  14000   52855   7550.71 1.325714.29 2000.00 0.35
> 9524  13500   49100   7328.36 1.235970.15 2014.93 0.34
> 9091  13500   49200   7235.29 1.235882.35 1985.29 0.34
> 5000  16900   33290   3916.47 0.834705.88 1988.24 0.42
>   27800   69550   4932.62 1.742836.88 1971.63 0.70
> 1667  57200   80200   2655.63 2.011324.50 1894.04 1.43
> 909   8   80034   1482.11 2.00740.74  1481.48 2.00
> 476   87000   80039   820.91  2.00410.26  892.31  2.18
> 196   16  80055   334.40  2.00167.08  668.34  4.00
> 
> Submitted batches were ~100us long in all cases. So with low batch 
> frequency it looks pretty believable. For example when we have 167.08 
> batches/s, we have 334.40 irq/s - which is double - as expected for 
> execlists. And we get again double that in terms of DC transitions per 
> second. Each irq is one GT IIR write from the GPU side, and another from 
> the CPU side.

GPU doesn't actually write the IIRs. It's just latching stuff from the
ISR. Whether the ISR edge or some higher level interrupt event actually
causes the DMC to kick into action isn't clear at all. My original
impressions was that it just traps the register accesses.

-- 
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] drm/i915: Update MOCS settings for gen 9

[Dmitry Rogozhkin]

On 5/5/2017 8:44 AM, Kenneth Graunke wrote:

On Thursday, May 4, 2017 7:46:34 PM PDT Dmitry Rogozhkin wrote:

On 5/4/2017 9:51 AM, Kenneth Graunke wrote:

MediaSDK is not a benchmark.  If I'm not mistaken, it's a userspace
driver produced by Intel engineers, one which Intel has the full
capability to change.  What you're saying is that Intel's MediaSDK
engineers are unwilling to change their software to provide better
performance for their Linux users.

That's pretty mental.

You are mistaken. Media SDK is not a driver. It is a user space library
which talks to the user space driver. And Media SDK does not set _any_
caching policies you are discussing here. That's the driver who sets
these policies. I don't want to go further here who supports this
driver, Intel or not, but there are mediasdk engineers whom you blame to
not willing to do something and who actually only indirectly are related
to this topic. Please, if you mean driver, say a driver.

Sorry, that's my mistake - and I think a number of other people in the
thread were similarly confused.  So, the suggestion isn't to change
MediaSDK at all - it's to change the closed-source libva driver that's
setting MOCS values that aren't supported by the upstream kernel.  IIRC
the upstream libva-intel-driver does not have this bug.

Mistakes happen. I hope this is clarified now.


My point largely stands, when redirected - someone is developing a
broken closed source userspace driver and is apparently unwilling to
change it.  That's the real problem.
Broken? Have you ever attempted to run functional and performance 
competitive between closed source and open source user space drivers? I 
attempted and a number of others have attempted that. Result is that 
open source driver has significantly worse encoding quality, worse to 
the degree that any performance comparisons start to make no sense. 
(Yep, work in progress to try to fix that, I know.) Decoding quality is 
on par, but I saw cases when performance is 5-10% worse (and that's when 
both drivers work on their presumably optimal settings). So, "broken" 
closed source driver is in use for the _reason_. And which driver could 
be considered "broken" after that: closed source one or open source one?


So, why you are addressing that closed source driver is broken? If it 
will be put in the environment with the upstream kernel, then it will 
eventually be broken and that's what we are trying to fix here. But do 
you realize that in the production environment where the driver is 
intended to work there is a patched kernel mode driver in place with the 
MOCS settings to satisfy the need of the driver? Or you naively think we 
use non-modified KMD from the upstream or previously released versions 
from kernel.org. Bad guess! In the production environment driver is not 
broken.


MY ADVICE to everyone on the thread: topic is really hot, no clear path 
to deal with the problem is seen. Please, try to avoid addressing work 
done by others in the words: "unwilling", "broken", etc. This bothers 
people... Be easy...


There were suggestions in the thread to apply existing settings to the 
closed source driver and see how cool things will be. Well, we applied 
this settings: not cache anything policy and performance is worse 
comparing to the closed source solution. We have 3 other policies to 
try. Which one you want to try? Or you want to try combination? For 
which objects you suggest to try these combinations? If I recall 
correctly closed source driver has dozens, maybe close to hundred 
objects of different kind with different caching policies. You want to 
try all combinations? That's out of reality per my opinion... At least 
that can't happen within few days.


So, closed source driver _has_ settings it considers optimal. And yes, 
there is such a question how really optimal they are, but existing 
settings work, work well for few years already (in a closed source 
solution delivered to the customers) and work better comparing to open 
source solution. This solution is far to be considered broken. Open 
source solution is delivered to absolutely different set of customers, 
customers do not intersect, and I guess we can't consider open source 
solution broken as well. It satisfy certain customers segment. And there 
are possibilities to improve both solutions. Both groups can be blamed 
in unwillingness, but... wait a minute... after all here are both groups 
in the thread discussing this topic, so are we willing or unwilling to 
change?


I personally think that optimal solution would be:
1) Either an API to permit drivers to program settings they consider 
optimal and avoid all this discussion altogether.
2) or remove this MOCS table from the SW level completely and hold it on 
GPU side hidden from the SW stack (yep, not possible for current HW)
As for the solution#1, I afraid we have technical issues, right? Is that 
true that only Render contexts can hold settings table and that's not 
possible for 

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

[Tvrtko Ursulin]

On 05/05/2017 15:49, Ville Syrjälä wrote:

On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

It seems that the DMC likes to transition between the DC states
a lot when there are no connected displays (no active power
domains) during simple command submission.


Is it trapping on some interrupt register accesses or what? And
if so which registers are affected?


It looks like GT IIR or something along those lines it but I couldn't 
say with total confidence. It is just a guess. Firmware binary 
definitely "mentions" those registers as can be seen by inspecting it 
with a hex editor.


The data I collected at least seems to present a correlation between the 
batch frequency and DC state transition frequency:


tgt DC  irqsirqs/s  irq batch/s DC/sDC/batch
submit  transitions /
freqbatch

1   2   78300   7830.00 1.964000.00 2000.00 0.50
990114000   52855   7550.71 1.325714.29 2000.00 0.35
952413500   49100   7328.36 1.235970.15 2014.93 0.34
909113500   49200   7235.29 1.235882.35 1985.29 0.34
500016900   33290   3916.47 0.834705.88 1988.24 0.42
27800   69550   4932.62 1.742836.88 1971.63 0.70
166757200   80200   2655.63 2.011324.50 1894.04 1.43
909 8   80034   1482.11 2.00740.74  1481.48 2.00
476 87000   80039   820.91  2.00410.26  892.31  2.18
196 16  80055   334.40  2.00167.08  668.34  4.00

Submitted batches were ~100us long in all cases. So with low batch 
frequency it looks pretty believable. For example when we have 167.08 
batches/s, we have 334.40 irq/s - which is double - as expected for 
execlists. And we get again double that in terms of DC transitions per 
second. Each irq is one GT IIR write from the GPU side, and another from 
the CPU side.


This was actually Imre's suggestion btw. Before I was only looking at 
the irq/s to DC/s correlation which was confusing me a lot since there 
are more of the latter, so I thought it can't be the trigger. But once 
Imre mentioned the possibility that things are triggered by IIR register 
writes numbers started making more sense.


Then with higher batch frequencies the ratio starts falling, is it 
because DC transitions are too slow to keep up, or something else I am 
not sure.


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

[Chris Wilson]

On Fri, May 05, 2017 at 08:43:36AM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 04/05/17 14:31, Chris Wilson wrote:
> >On Thu, May 04, 2017 at 09:26:35PM +, Srivatsa, Anusha wrote:
> >>>+void i915_guc_load_error_log_capture(struct drm_i915_private *i915) {
> >>>+  void *log, *buf;
> >>>+  struct i915_vma *vma = i915->guc.log.vma;
> >>>+
> >>>+  if (i915->gpu_error.guc_load_fail_log || !vma)
> >>>+  return;
> >>>+
> >>>+  /*
> >>>+   * the vma should be already pinned and mapped for log runtime
> >>>+   * management but let's play safe
> >>>+   */
> >>>+  log = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
> >>>+  if (IS_ERR(log)) {
> >>>+  DRM_ERROR("Failed to pin guc_log vma\n");
> >>>+  return;
> >>>+  }
> >>>+
> >>>+  buf = kzalloc(GUC_LOG_SIZE, GFP_KERNEL);
> >>>+  if (buf) {
> >>>+  memcpy(buf, log, GUC_LOG_SIZE);
> >>>+  i915->gpu_error.guc_load_fail_log = buf;
> >>>+  } else {
> >>>+  DRM_ERROR("Failed to copy guc log\n");
> >>>+  }
> >>>+
> >>>+  i915_gem_object_unpin_map(vma->obj);
> >
> >You are trading a swappable object for unswappable kernel memory. If you
> >want to have the guc log after guc is disabled, just keep the log object
> >around.
> >-Chris
> >
> 
> I had considered that, but in the end I wasn't sure if that was
> acceptable in case we end up modifying the code to recycle the
> object for future load attempts, although that is very unlikely. I
> was however unconvinced myself of using kzalloc and that's mainly
> why this was an RFC :)
> I'll flip it to take an extra reference on the object.

Just make sure you unpin it. I would suggest killing the guc->log.vma
and taking the object and placing it somewhere else as you have for the
buf, but not i915->gpu_error as that doesn't fit (this isn't a runtime
error that we are tracking). i915->guc.last_load_log?
-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] drm/i915: Update MOCS settings for gen 9

[Kenneth Graunke]

On Thursday, May 4, 2017 7:46:34 PM PDT Dmitry Rogozhkin wrote:
> 
> On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > MediaSDK is not a benchmark.  If I'm not mistaken, it's a userspace
> > driver produced by Intel engineers, one which Intel has the full
> > capability to change.  What you're saying is that Intel's MediaSDK
> > engineers are unwilling to change their software to provide better
> > performance for their Linux users.
> >
> > That's pretty mental.
> You are mistaken. Media SDK is not a driver. It is a user space library 
> which talks to the user space driver. And Media SDK does not set _any_ 
> caching policies you are discussing here. That's the driver who sets 
> these policies. I don't want to go further here who supports this 
> driver, Intel or not, but there are mediasdk engineers whom you blame to 
> not willing to do something and who actually only indirectly are related 
> to this topic. Please, if you mean driver, say a driver.

Sorry, that's my mistake - and I think a number of other people in the
thread were similarly confused.  So, the suggestion isn't to change
MediaSDK at all - it's to change the closed-source libva driver that's
setting MOCS values that aren't supported by the upstream kernel.  IIRC
the upstream libva-intel-driver does not have this bug.

My point largely stands, when redirected - someone is developing a
broken closed source userspace driver and is apparently unwilling to
change it.  That's the real problem.


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

[Daniele Ceraolo Spurio]

On 04/05/17 14:31, Chris Wilson wrote:

On Thu, May 04, 2017 at 09:26:35PM +, Srivatsa, Anusha wrote:

+void i915_guc_load_error_log_capture(struct drm_i915_private *i915) {
+   void *log, *buf;
+   struct i915_vma *vma = i915->guc.log.vma;
+
+   if (i915->gpu_error.guc_load_fail_log || !vma)
+   return;
+
+   /*
+* the vma should be already pinned and mapped for log runtime
+* management but let's play safe
+*/
+   log = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
+   if (IS_ERR(log)) {
+   DRM_ERROR("Failed to pin guc_log vma\n");
+   return;
+   }
+
+   buf = kzalloc(GUC_LOG_SIZE, GFP_KERNEL);
+   if (buf) {
+   memcpy(buf, log, GUC_LOG_SIZE);
+   i915->gpu_error.guc_load_fail_log = buf;
+   } else {
+   DRM_ERROR("Failed to copy guc log\n");
+   }
+
+   i915_gem_object_unpin_map(vma->obj);


You are trading a swappable object for unswappable kernel memory. If you
want to have the guc log after guc is disabled, just keep the log object
around.
-Chris



I had considered that, but in the end I wasn't sure if that was 
acceptable in case we end up modifying the code to recycle the object 
for future load attempts, although that is very unlikely. I was however 
unconvinced myself of using kzalloc and that's mainly why this was an RFC :)

I'll flip it to take an extra reference on the object.

Thanks,
Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 11/15] drm/i915: Support variable cursor height on ivb+

[Imre Deak]

On Mon, Mar 27, 2017 at 09:55:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> IVB introduced the CUR_FBC_CTL register which allows reducing the cursor
> height down to 8 lines from the otherwise square cursor dimensions.
> Implement support for it. CUR_FBC_CTL can't be used when the cursor
> is rotated.
> 
> Commandeer the otherwise unused cursor->cursor.size to track the
> current value of CUR_FBC_CTL to optimize away redundant CUR_FBC_CTL
> writes, and to notice when we need to arm the update via CURBASE if
> just CUR_FBC_CTL changes.
> 
> v2: Reverse the gen check to make it sane
> v3: Only enable CUR_FBC_CTL when cursor is enabled, adapt to
> earlier code changes which means we now actually turn off
> the cursor when we're supposed to unlike v2
> v4: Add a comment about rotation vs. CUR_FBC_CTL,
> rebase due to 'dirty' (Chris)
> v5: Rebase to the atomic world
> Handle 180 degree rotation
> Add HAS_CUR_FBC()
> v6: Rebase
> v7: Rebase due to I915_WRITE_FW/uncore.lock
> s/size/fbc_ctl/
> 
> Signed-off-by: Ville Syrjälä 

Nitpick: cursor.size could've been changed to be a union of size,fb_ctl
too. Either way looks ok:
Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_reg.h  |  5 -
>  drivers/gpu/drm/i915/intel_display.c | 38 
> +---
>  3 files changed, 36 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 86f097db8ef6..9524ce0442ad 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2927,6 +2927,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define HAS_FW_BLC(dev_priv) (INTEL_GEN(dev_priv) > 2)
>  #define HAS_PIPE_CXSR(dev_priv) ((dev_priv)->info.has_pipe_cxsr)
>  #define HAS_FBC(dev_priv)((dev_priv)->info.has_fbc)
> +#define HAS_CUR_FBC(dev_priv)(!HAS_GMCH_DISPLAY(dev_priv) && 
> INTEL_INFO(dev_priv)->gen >= 7)
>  
>  #define HAS_IPS(dev_priv)(IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv))
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4d97d9fb2ad0..9027debb1cf9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5447,7 +5447,9 @@ enum {
>  #define   CURSOR_POS_SIGN   0x8000
>  #define   CURSOR_X_SHIFT0
>  #define   CURSOR_Y_SHIFT16
> -#define CURSIZE  _MMIO(0x700a0)
> +#define CURSIZE  _MMIO(0x700a0) /* 845/865 */
> +#define _CUR_FBC_CTL_A   0x700a0 /* ivb+ */
> +#define   CUR_FBC_CTL_EN (1 << 31)
>  #define _CURBCNTR0x700c0
>  #define _CURBBASE0x700c4
>  #define _CURBPOS 0x700c8
> @@ -5463,6 +5465,7 @@ enum {
>  #define CURCNTR(pipe) _CURSOR2(pipe, _CURACNTR)
>  #define CURBASE(pipe) _CURSOR2(pipe, _CURABASE)
>  #define CURPOS(pipe) _CURSOR2(pipe, _CURAPOS)
> +#define CUR_FBC_CTL(pipe) _CURSOR2(pipe, _CUR_FBC_CTL_A)
>  
>  #define CURSOR_A_OFFSET 0x70080
>  #define CURSOR_B_OFFSET 0x700c0
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c6e026e617e5..53ec9d30437e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9364,17 +9364,16 @@ static u32 i9xx_cursor_ctl(const struct 
> intel_crtc_state *crtc_state,
>  
>  static bool i9xx_cursor_size_ok(const struct intel_plane_state *plane_state)
>  {
> + struct drm_i915_private *dev_priv =
> + to_i915(plane_state->base.plane->dev);
>   int width = plane_state->base.crtc_w;
>   int height = plane_state->base.crtc_h;
>  
>   if (!intel_cursor_size_ok(plane_state))
>   return false;
>  
> - /*
> -  * Cursors are limited to a few power-of-two
> -  * sizes, and they must be square.
> -  */
> - switch (width | height) {
> + /* Cursor width is limited to a few power-of-two sizes */
> + switch (width) {
>   case 256:
>   case 128:
>   case 64:
> @@ -9383,6 +9382,21 @@ static bool i9xx_cursor_size_ok(const struct 
> intel_plane_state *plane_state)
>   return false;
>   }
>  
> + /*
> +  * IVB+ have CUR_FBC_CTL which allows an arbitrary cursor
> +  * height from 8 lines up to the cursor width, when the
> +  * cursor is not rotated. Everything else requires square
> +  * cursors.
> +  */
> + if (HAS_CUR_FBC(dev_priv) &&
> + plane_state->base.rotation & DRM_ROTATE_0) {
> + if (height < 8 || height > width)
> + return false;
> + } else {
> + if (height != width)
> + return false;
> + }
> +
>   return true;
>  }
>  
> @@ -9444,12 +9458,15 @@ static void i9xx_update_cursor(struct intel_plane 
> 

Re: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

[Daniele Ceraolo Spurio]

On 04/05/17 14:26, Srivatsa, Anusha wrote:




-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Daniele Ceraolo Spurio
Sent: Thursday, May 4, 2017 11:52 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

We're currently deleting the GuC logs if the FW fails to load, but those are 
still
useful to understand why the loading failed. Instead of deleting them, taking a
snapshot allows us to access them after driver load is completed.


Hi Daniele, I like the idea. But just to confirm, we are still going to get the 
status of fetch and load-like PENDING  or FAIL, but the reason of failure is 
going to be in the debugfs. Correct?

Anusha



yes, no changes in the what comes out in dmesg. What is going to be in 
debugfs is not the reason for the failure but the GuC logs generated 
during the attempted load, which once decoded should show the reason for 
the failure.


Daniele


Cc: Oscar Mateo 
Cc: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
---
drivers/gpu/drm/i915/i915_debugfs.c   | 36 ---
drivers/gpu/drm/i915/i915_drv.c   |  3 +++
drivers/gpu/drm/i915/i915_drv.h   |  6 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 36
+++
drivers/gpu/drm/i915/intel_guc_fwif.h | 14 +++---
drivers/gpu/drm/i915/intel_guc_log.c  | 10 ++
drivers/gpu/drm/i915/intel_uc.c   |  7 +--
7 files changed, 84 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470..4ff20fc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2543,26 +2543,32 @@ static int i915_guc_info(struct seq_file *m, void
*data)  static int i915_guc_log_dump(struct seq_file *m, void *data)  {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_i915_gem_object *obj;
-   int i = 0, pg;
-
-   if (!dev_priv->guc.log.vma)
+   u32 *log;
+   int i = 0;
+
+   if (dev_priv->guc.log.vma) {
+   log = i915_gem_object_pin_map(dev_priv->guc.log.vma->obj,
+ I915_MAP_WC);
+   if (IS_ERR(log)) {
+   DRM_ERROR("Failed to pin guc_log vma\n");
+   return -ENOMEM;
+   }
+   } else if (dev_priv->gpu_error.guc_load_fail_log) {
+   log = dev_priv->gpu_error.guc_load_fail_log;
+   } else {
return 0;
-
-   obj = dev_priv->guc.log.vma->obj;
-   for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
-   u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));
-
-   for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
-   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
-  *(log + i), *(log + i + 1),
-  *(log + i + 2), *(log + i + 3));
-
-   kunmap_atomic(log);
}

+   for (i = 0; i < GUC_LOG_SIZE / sizeof(u32); i += 4)
+   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+  *(log + i), *(log + i + 1),
+  *(log + i + 2), *(log + i + 3));
+
seq_putc(m, '\n');

+   if (dev_priv->guc.log.vma)
+   i915_gem_object_unpin_map(dev_priv->guc.log.vma->obj);
+
return 0;
}

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 452c265..c7cb36c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1354,6 +1354,9 @@ void i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
i915_reset_error_state(dev_priv);

+   /* release GuC error log (if any) */
+   i915_guc_load_error_log_free(dev_priv);
+
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4588b3e..761c663 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1555,6 +1555,9 @@ struct i915_gpu_error {
/* Protected by the above dev->gpu_error.lock. */
struct i915_gpu_state *first_error;

+   /* Log snapshot if GuC errors during load */
+   void *guc_load_fail_log;
+
unsigned long missed_irq_rings;

/**
@@ -3687,6 +3690,9 @@ static inline void i915_reset_error_state(struct
drm_i915_private *i915)

#endif

+void i915_guc_load_error_log_capture(struct drm_i915_private *i915);
+void i915_guc_load_error_log_free(struct drm_i915_private *i915);
+
const char *i915_cache_level_str(struct drm_i915_private *i915, int type);

/* i915_cmd_parser.c */
diff --git 

[Intel-gfx] [maintainer-tools PATCH] docs: drm-misc: Remove misc-next merges during merge window/rc1

[Sean Paul]

In the merge timeline, remove the misc-next ~> drm-next merges while
the merge window is active, and during rc1. Pulls should only be requested
between rc2 and rc5.

Signed-off-by: Sean Paul 
---

While the early PR no-no is fresh in my mind, I'll update the merge timeline
to avoid making the same mistake again.

Sean



 drm-misc-timeline.json | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drm-misc-timeline.json b/drm-misc-timeline.json
index 7b039ce..30f4043 100644
--- a/drm-misc-timeline.json
+++ b/drm-misc-timeline.json
@@ -27,7 +27,7 @@
  wave: '=..0.=...0.',
  data: ['drm features for release + 1',
 'drm features for release + 2'],
- node: '...g.stuvw"..h.' }
+ node: '...g...uvw"..h.' }
],
 
{ name: 'drm-misc-fixes',
@@ -45,7 +45,7 @@
  wave: '==.',
  data: ['drm-misc features for release + 2',
 'drm-misc features for release + 3'],
- node: 'rxyz;:.' },
+ node: '..yz;:.' },
],
 
edge: [
@@ -58,7 +58,7 @@
/* misc-next-fixes to -next */
'o~>g', 'q~>p',
/* misc-next to -next */
-   'r~>s', 'x~>t', 'y~>u', 'z~>v', ';~>w', ':~>"'
+   'y~>u', 'z~>v', ';~>w', ':~>"'
 
],
 
-- 
2.13.0.rc1.294.g07d810a77f-goog

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-next-fixes for 4.12

[Sean Paul]

Hi Dave,
Many apologies for missing your initial PR. Just one patch to fix up the panel
for HP zBook 17 G2.

drm-misc-next-fixes-2017-05-05:
Core Changes:
- Add quirk for LGD 764 panel to default 10bpc (Mario)

Cc: Mario Kleiner 

Cheers, Sean


The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf:

  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next 
(2017-05-02 04:46:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-05-05

for you to fetch changes up to e345da82bd6bdfa8492f80b3ce4370acfd868d95:

  drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2 (2017-05-02 
10:37:45 +0200)


Core Changes:
- Add quirk for LGD 764 panel to default 10bpc (Mario)

Cc: Mario Kleiner 


Mario Kleiner (1):
  drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2

 drivers/gpu/drm/drm_edid.c | 8 
 1 file changed, 8 insertions(+)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Alex Williamson]

On Fri, 05 May 2017 08:55:31 +0200
Gerd Hoffmann  wrote:

>   Hi,
> 
> > > >>Hmm, that looks like a rather strange way to return a file descriptor.
> > > >>
> > > >>What is the reason to not use ioctls on the vfio file handle, like
> > > >>older version of these patches did?
> > > >If I understood correctly that Alex prefer not to change the ioctls on 
> > > >the vfio file
> > > >handle like the old version.
> > > >So I used this way the smallest change to general vfio framework only 
> > > >adding a
> > > >subregion definition.  
> > 
> > I think I was hoping we could avoid a separate file descriptor
> > altogether and use a vfio region instead.  
> 
> What exactly did you have in mind?  Put the framebuffer information
> (struct intel_vgpu_dmabuf) into the vfio region, then access it using
> read/write/mmap?

Yeah, that was my hope.  Adding a new file descriptor means we have one
more reference floating around complicating the life cycle of the
device, group, and container.  Furthermore this one is really only
visible to the mdev vendor driver, so we can't rely on vfio-core, the
vendor driver will need to consider the reference when releasing the
device.

> > However, it was explained
> > previously why this really needs to be a separate fd and I agree that
> > using a region to expose an fd is really awkward.  
> 
> Now with this patchset we have *two* kinds of separate file handles.
> First the anon-fd created by reading from the region.  This is then used
> to run the intel ioctls on, which in turn create the other kind of file
> handle (dma-buf-fd).
> 
> The dma-buf-fd really needs to be a separate fd, because it gets passed
> around as handle and because this is the way dma-bufs work (guess this
> is the discussion you are referring to).

Yep, we're going to need to trust the vendor driver to manage it, we
have lots of places where we need to trust the vendor driver for an
mdev device, unfortunately.
 
> I can't see a compelling reason for the anon-fd though.  I suspect this
> was done due to a misunderstanding ...

Yeah, vfio-core passes device ioctls to the vendor driver, so the
vendor driver should be able to implement a
VFIO_DEVICE_GVT_GET_DMABUF_FD ioctl direclty.  Ideally maybe this
isn't even GVT specific, and we'd s/GVT_//.  Thanks,

Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

[Ville Syrjälä]

On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> It seems that the DMC likes to transition between the DC states
> a lot when there are no connected displays (no active power
> domains) during simple command submission.

Is it trapping on some interrupt register accesses or what? And
if so which registers are affected?

> 
> This frantic activity on DC states has a terrible impact on the
> performance of the overall chip with huge latencies observed in
> the interrupt handlers and elsewhere. Simple tests like
> igt/gem_latency -n 0 are slowed down by a factor of eight.
> 
> Work around it by grabbing a modeset display power domain whilst
> there is any GT activity. This seems to be effective in making
> the DMC keep its paws off the chip.
> 
> On the other hand this may have a negative impact on the overall
> power budget of the chip and so could still affect performance.
> 
> This version limits the workaround got SKL GT3 and GT4 parts but
> this is just due the absence of testing on other platforms. It
> is possible we will have to apply it wider.
> 
> Signed-off-by: Tvrtko Ursulin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 5 +
>  drivers/gpu/drm/i915/i915_gem.c | 4 
>  drivers/gpu/drm/i915/i915_gem_request.c | 3 +++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 320c16df1c9c..4d58e2e28c2f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2990,6 +2990,11 @@ intel_info(const struct drm_i915_private *dev_priv)
>  
>  #define HAS_DECOUPLED_MMIO(dev_priv) 
> (INTEL_INFO(dev_priv)->has_decoupled_mmio)
>  
> +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> + HAS_CSR(dev_priv) && \
> + (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv)) && \
> + (dev_priv)->csr.dmc_payload
> +
>  #include "i915_trace.h"
>  
>  static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private 
> *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b2727905ef2b..c52d863f409c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3200,7 +3200,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
>  
>   if (INTEL_GEN(dev_priv) >= 6)
>   gen6_rps_idle(dev_priv);
> +
>   intel_runtime_pm_put(dev_priv);
> +
> + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
>  out_unlock:
>   mutex_unlock(>struct_mutex);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index 10361c7e3b37..10a3b51f6362 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -873,6 +873,9 @@ static void i915_gem_mark_busy(const struct 
> intel_engine_cs *engine)
>  
>   GEM_BUG_ON(!dev_priv->gt.active_requests);
>  
> + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> + intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
> +
>   intel_runtime_pm_get_noresume(dev_priv);
>   dev_priv->gt.awake = true;
>  
> -- 
> 2.9.3
> 
> ___
> 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] [PULL] drm-misc-next for 4.13

[Sean Paul]

Hi Dave,
Here's the first pull request for 4.13 from misc-next. It's surprisingly small
given that we had an extra week of feature freeze. The highlights are below, and
aside from these we had miscellaneous (heh) fixes sprinkled throughout.

A bit of administrivia for you:

We now have a standard template for misc pulls which break out UAPI/Cross-
subsystem/Core/Driver changes. Aside from hopefully making it easier for you,
this will remind me to explicitly think about the different changes I should
call out.

Secondly, I've Cc'd the authors of the sets I've summarized below. This should
provide an extra layer of protection against the misc maintainer summarizing
incorrectly (which is rightly a concern of yours).

Feedback is most welcome.


drm-misc-next-2017-05-05:
UAPI Changes:
- Return -ENODEV instead of -ENXIO when creating cma fb w/o valid gem (Daniel)

Core Changes:
- Add Laurent as bridge reviewer and Andrzej as bridge maintainer (Archit)
- Maintain new STM driver through -misc (Yannick)
- Misc doc improvements (as is tradition) (Daniel)

Driver Changes:
- Add out-fence support to vc4 V3D rendering (Eric)
- Add support for stm32f429 display hw and am-480272h3tmqw-t01h panel (Yannick)
- Remove 256MB cma limit from vc4 (Eric)
- Disable dw-hdmi audio when inactive, instead of always enabled (Romain)
- Add support for VGA to the ZTE driver (Shawn)

Cc: Archit Taneja 
Cc: Eric Anholt 
Cc: Yannick Fertre 
Cc: Daniel Vetter 
Cc: Romain Perier 
Cc: Navare, Manasi D 
Cc: Shawn Guo 

Happy weekend, Sean


The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf:

  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next 
(2017-05-02 04:46:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-05-05

for you to fetch changes up to 3c390df3337e54130e4b511ea3bbb868643cc5ea:

  Merge tag 'drm-for-v4.12' of git://people.freedesktop.org/~airlied/linux into 
drm-misc-next (2017-05-04 08:42:49 -0400)


UAPI Changes:
- Return -ENODEV instead of -ENXIO when creating cma fb w/o valid gem (Daniel)

Core Changes:
- Add Laurent as bridge reviewer and Andrzej as bridge maintainer (Archit)
- Maintain new STM driver through -misc (Yannick)
- Misc doc improvements (as is tradition) (Daniel)

Driver Changes:
- Add out-fence support to vc4 V3D rendering (Eric)
- Add support for stm32f429 display hw and am-480272h3tmqw-t01h panel (Yannick)
- Remove 256MB cma limit from vc4 (Eric)
- Disable dw-hdmi audio when inactive, instead of always enabled (Romain)
- Add support for VGA to the ZTE driver (Shawn)

Cc: Archit Taneja 
Cc: Eric Anholt 
Cc: Yannick Fertre 
Cc: Daniel Vetter 
Cc: Romain Perier 
Cc: Navare, Manasi D 
Cc: Shawn Guo 


Andres Rodriguez (1):
  dma-buf: avoid scheduling on fence status query v2

Archit Taneja (1):
  MAINTAINERS: Update maintainers/reviewers for bridge drivers

Boris Brezillon (1):
  drm/vc4: Add runtime PM support to the HDMI encoder driver

Chris Wilson (1):
  drm/mm: Split up long running selftests with cond_resched()

Clint Taylor (1):
  drm/cec: Add CEC over Aux register definitions

Colin Ian King (1):
  drm: fix spelling mistake: "committing"

Daniel Vetter (3):
  drm/doc: Fix missing @ctx documentation
  drm/doc: Interlink color manager docs better
  drm/cma-helper: Return ENOENT for "no such gem obj"

Dave Airlie (1):
  sync_file: get rid of internal reference count.

Eric Anholt (4):
  drm/vc4: Expose dma-buf fences for V3D rendering.
  drm/cma: Fix recent regression of mmap() in the MMU case.
  drm/vc4: Fix refcounting of runtime PM get if it errors out.
  drm/vc4: Allow using more than 256MB of CMA memory.

Gustavo Padovan (1):
  drm/atomic: fix doc to use new name for commit types

Jeffy Chen (2):
  drm/rockchip: Set line flag config register in vop_crtc_enable
  drm/rockchip: analogix_dp: Remove unused check and variables

Jyri Sarha (2):
  drm: drm_color_mgmt.h needs struct drm_crtc declaration
  drm: Make drm_atomic_replace_property_blob_from_id() more generic

Liu Ying (1):
  drm/bridge: sii902x: Add missing \n to the end of some dev_err messages

Navare, Manasi D (1):
  drm: Add DPCD definitions for DP 1.4 DSC feature

Romain Perier (2):
  drm: dw-hdmi: add specific I2S and AHB functions for stream handling
  drm: dw-hdmi: gate audio clock from the I2S enablement callbacks

Sean Paul (1):
  Merge tag 'drm-for-v4.12' of 

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Chris Wilson]

On Fri, May 05, 2017 at 03:20:08PM +0100, Tvrtko Ursulin wrote:
> 
> On 05/05/2017 14:51, Chris Wilson wrote:
> >On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 05/05/2017 14:32, Chris Wilson wrote:
> >>>On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
> 
> On 03/05/2017 12:37, Chris Wilson wrote:
> >struct intel_engine_cs {
> >@@ -367,6 +373,7 @@ struct intel_engine_cs {
> >
> > /* Execlists */
> > struct tasklet_struct irq_tasklet;
> >+struct execlist_priolist default_priolist;
> > struct execlist_port {
> > struct drm_i915_gem_request *request_count;
> >#define EXECLIST_COUNT_BITS 2
> >
> >>>
> >>>Just a small bikeshed to consider. Having switched to
> >>>I915_PRIORITY_NORMAL, do we have a better name for default_priolist? I
> >>>still prefer default_priolist over normal_priolist. Go back to
> >>>I915_PRIORITY_DEFAULT?
> >>
> >>default_priolist is fine I think since it is dual purpose. Primary
> >>purpose to avoid allocations as you said.
> >>
> >>Although I am still a bit dejected how some userspace could decide
> >>one day to send everything at I915_PRIORITY_NORMAL - n, in order to
> >>use I915_PRIORITY_NORMAL as the high prio not requiring
> >>cap_sys_admin, and in doing so completely defeat the atomic kmalloc
> >>avoidance. :(
> >
> >Should we just bite the bullet and install a kmem_cache here?
> >It didn't solve the kmalloc error handling, but it does at least give us
> >a freelist. There is a reasonable argument that as soon as userspace
> >starts using non-default priorities, we may see many different levels
> >justifying allocating a whole slab upfront.
> 
> Actually my argument is pants since allocations only happen with
> "opening" a new priority level. So I think leave it as it is until
> there is a need.

Patch is ready for kmalloc showing up as a latency source.
-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 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Tvrtko Ursulin]

On 05/05/2017 15:04, Chris Wilson wrote:

On Fri, May 05, 2017 at 02:50:46PM +0100, Tvrtko Ursulin wrote:


On 03/05/2017 12:37, Chris Wilson wrote:

[snip]


+#include 
+
+static inline void __list_del_many(struct list_head *head,
+  struct list_head *first)
+{
+   head->next = first;
+   first->prev = head;
+}


Btw it is similar to __list_cut_position, but without the second
list you don't need and deleting the first entry which you do not
want.

So I am just thinking if consistent naming with the core function
would be beneficial like __list_cut_position_before/exclusive?


It's not a cut, as in we don't create two seperate lists. It is more of
splice with itself, though I did look at cut and wonder if it would
magically eliminate the unwanted paths but no..

Still favouring a list_del prefix. Once upon a time I just opencoded
this, it's far easily than trying to work out a good name :)


It's not __list_del_many either since it does not unlink the ones in the 
middle. ;) Doesn't matter, as you say, it is quite hard to find the 
ideal name.


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Tvrtko Ursulin]

On 05/05/2017 14:51, Chris Wilson wrote:

On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote:


On 05/05/2017 14:32, Chris Wilson wrote:

On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:


On 03/05/2017 12:37, Chris Wilson wrote:

struct intel_engine_cs {
@@ -367,6 +373,7 @@ struct intel_engine_cs {

/* Execlists */
struct tasklet_struct irq_tasklet;
+   struct execlist_priolist default_priolist;
struct execlist_port {
struct drm_i915_gem_request *request_count;
#define EXECLIST_COUNT_BITS 2



Just a small bikeshed to consider. Having switched to
I915_PRIORITY_NORMAL, do we have a better name for default_priolist? I
still prefer default_priolist over normal_priolist. Go back to
I915_PRIORITY_DEFAULT?


default_priolist is fine I think since it is dual purpose. Primary
purpose to avoid allocations as you said.

Although I am still a bit dejected how some userspace could decide
one day to send everything at I915_PRIORITY_NORMAL - n, in order to
use I915_PRIORITY_NORMAL as the high prio not requiring
cap_sys_admin, and in doing so completely defeat the atomic kmalloc
avoidance. :(


Should we just bite the bullet and install a kmem_cache here?
It didn't solve the kmalloc error handling, but it does at least give us
a freelist. There is a reasonable argument that as soon as userspace
starts using non-default priorities, we may see many different levels
justifying allocating a whole slab upfront.


Actually my argument is pants since allocations only happen with 
"opening" a new priority level. So I think leave it as it is until there 
is a need.


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

[Sanford Rockowitz]

Jani,

Thanks for your quick and detailed response. 

You wrote:

> The single DP link is divided to several logical links to sink devices.

Suppose the dock has a DVI and/or HDMI connector.  Are those connectors
logical sinks to a master DisplayPort connection, or do they have their
own connection through the dock to the laptop?  If the former, then
telling people to use a DVI or HDMI connection on the dock would not be
a workaround. 

ddcutil looks for displays by examining all non-SMBus /dev/i2c devices
on the system.  If checks for the presence of slave address x50 and
x37.  If they exist it tries to read the EDID on x50 and a Virtual
Control Panel feature value on x37.  Looking at one of the user logs, I
see that a couple /dev/i2c-n devices have udev sysattr name DPMST.  When
ddcutil probes those /dev/i2c devices, slave addresses x50 and x37
appear active, but reading the EDID fails. So it would seem that the
i2c-dev driver is not properly handling DP-MST.   Does that
interpretation seem correct?  If so, I'll bounce the issue over to the
I2C folks.

Alternatively, do the DP-MST devices present as some other userspace
device that I can program to?  I imagine that searching udev for sysattr
name DPMST would find any place in the /dev tree besides /dev/i2c where
the devices are surfaced.   Would this be a bit-banging interface, or
something at a higher level?  Or would I need to write a device driver?

Thanks again,
Sanford



On 05/05/2017 05:59 AM, Jani Nikula wrote:
> On Fri, 05 May 2017, Sanford Rockowitz  wrote:
>> I am the author of ddcutil (www.ddcutil.com), a Linux utility that
>> manages monitor settings using DDC/CI. I am seeing a pattern of user
>> error reports in which I2C communication is not working when a system
>> with a recent Intel chip, using the i915 driver, is plugged into a
>> docking station.  Communication works when the video cable is plugged
>> directly into the laptop.   There also seems to be a correlation with
>> whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is
>> being executed), though this correlation is not as clear.
>>
>> I'm not sure how best to go about reporting these issues.  The usual bug
>> reporting mechanism asks for detailed information about a specific
>> system, which I don't have.   What I do have is the ability to see a
>> pattern.
>>
>> Because I2C communication is so fragile (dependencies on hardware
>> quirks, drivers, etc), ddcutil (which is written in C) has an extensive
>> subsystem devoted to remotely diagnosing user configurations.  It
>> already reports DDC (i.e. I2C) communication errors, and has interfaces
>> to udev, libdrm, and x11 libraries.  If there is some i915 specific code
>> I could add to refine the diagnosis, I would be happy to add that. 
>> (Note: ddcutil is entirely a user space program, using the i2c-dev
>> interface.)
>>
>> Suggestions on how to proceed appreciated.
> The issues are related to DP MST (Multi-Stream Transport) that the docks
> use nowadays. The single DP link is divided to several logical links to
> sink devices. The I2C communication needs to be encapsulated to remote
> I2C-over-AUX reads and writes, with the logical DP MST addresses, to
> route them to the correct sinks. In kernel, this is handled by the MST
> topology manager.
>
> Instead of using the I2C device directly for, say, card0-DP-1 or
> DPDDC-A, you need to be using the dynamically created and removed DP MST
> I2C devices that wrap the communications to remote I2C-over-AUX. Frankly
> I am not sure if the naming or parent/child relationships of the devices
> are quite right (based on looking at the code), but you should find the
> sysfs name attribute will be DPMST. I'm also not sure how you can
> associate those with the physical devices you have.
>
> If you have an option to tell your tool which I2C device to use, that
> should get you started and debugging. If there are issues with that,
> please let us know.
>
> In the long run, we should probably do something to make the discovery
> of the DP MST I2C devices easier, with naming and/or better parent/child
> relationships of the devices. It's just that the userspace I2C interface
> was probably pretty far down on the list of priorities when writing DP
> MST.
>
>
> BR,
> Jani.
>
>


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Chris Wilson]

On Fri, May 05, 2017 at 02:50:46PM +0100, Tvrtko Ursulin wrote:
> 
> On 03/05/2017 12:37, Chris Wilson wrote:
> 
> [snip]
> 
> >+#include 
> >+
> >+static inline void __list_del_many(struct list_head *head,
> >+   struct list_head *first)
> >+{
> >+head->next = first;
> >+first->prev = head;
> >+}
> 
> Btw it is similar to __list_cut_position, but without the second
> list you don't need and deleting the first entry which you do not
> want.
> 
> So I am just thinking if consistent naming with the core function
> would be beneficial like __list_cut_position_before/exclusive?

It's not a cut, as in we don't create two seperate lists. It is more of
splice with itself, though I did look at cut and wonder if it would
magically eliminate the unwanted paths but no..

Still favouring a list_del prefix. Once upon a time I just opencoded
this, it's far easily than trying to work out a good name :)
-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 09/15] drm/i915: Generalize cursor size checks a bit

[Imre Deak]

On Mon, Mar 27, 2017 at 09:55:40PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> We have the maximum cursor dimensions stored in the mode_config, so
> let's just consult that information instead of hardcoding the same
> information in multiple places.
> 
> We still need to keep some per-platform checks as the limitations are
> quite diverse.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 34 +-
>  1 file changed, 13 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 774f9668076f..4f7a3e3f03e7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9169,6 +9169,17 @@ static u32 intel_cursor_position(const struct 
> intel_plane_state *plane_state)
>   return pos;
>  }
>  
> +static bool intel_cursor_size_ok(const struct intel_plane_state *plane_state)
> +{
> + const struct drm_mode_config *config =
> + _state->base.plane->dev->mode_config;
> + int width = plane_state->base.crtc_w;
> + int height = plane_state->base.crtc_h;
> +
> + return width > 0 && width <= config->cursor_width &&
> + height > 0 && height <= config->cursor_height;
> +}
> +
>  static int intel_check_cursor(struct intel_crtc_state *crtc_state,
> struct intel_plane_state *plane_state)
>  {
> @@ -9221,28 +9232,13 @@ static u32 i845_cursor_ctl(const struct 
> intel_crtc_state *crtc_state,
>  
>  static bool i845_cursor_size_ok(const struct intel_plane_state *plane_state)
>  {
> - struct drm_i915_private *dev_priv =
> - to_i915(plane_state->base.plane->dev);
>   int width = plane_state->base.crtc_w;
> - int height = plane_state->base.crtc_h;
> -
> - if (width == 0 || height == 0)
> - return false;
>  
>   /*
>* 845g/865g are only limited by the width of their cursors,
>* the height is arbitrary up to the precision of the register.
>*/
> - if (!IS_ALIGNED(width, 64))
> - return false;
> -
> - if (width > (IS_I845G(dev_priv) ? 64 : 512))
> - return false;
> -
> - if (height > 1023)
> - return false;
> -
> - return true;
> + return intel_cursor_size_ok(plane_state) && IS_ALIGNED(width, 64);
>  }
>  
>  static int i845_check_cursor(struct intel_plane *plane,
> @@ -9378,12 +9374,10 @@ static u32 i9xx_cursor_ctl(const struct 
> intel_crtc_state *crtc_state,
>  
>  static bool i9xx_cursor_size_ok(const struct intel_plane_state *plane_state)
>  {
> - struct drm_i915_private *dev_priv =
> - to_i915(plane_state->base.plane->dev);
>   int width = plane_state->base.crtc_w;
>   int height = plane_state->base.crtc_h;
>  
> - if (width == 0 || height == 0)
> + if (!intel_cursor_size_ok(plane_state))
>   return false;
>  
>   /*
> @@ -9393,8 +9387,6 @@ static bool i9xx_cursor_size_ok(const struct 
> intel_plane_state *plane_state)
>   switch (width | height) {
>   case 256:
>   case 128:
> - if (IS_GEN2(dev_priv))
> - return false;
>   case 64:
>   break;
>   default:
> -- 
> 2.10.2
> 
> ___
> 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 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Chris Wilson]

On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote:
> 
> On 05/05/2017 14:32, Chris Wilson wrote:
> >On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 03/05/2017 12:37, Chris Wilson wrote:
> >>>struct intel_engine_cs {
> >>>@@ -367,6 +373,7 @@ struct intel_engine_cs {
> >>>
> >>>   /* Execlists */
> >>>   struct tasklet_struct irq_tasklet;
> >>>+  struct execlist_priolist default_priolist;
> >>>   struct execlist_port {
> >>>   struct drm_i915_gem_request *request_count;
> >>>#define EXECLIST_COUNT_BITS 2
> >>>
> >
> >Just a small bikeshed to consider. Having switched to
> >I915_PRIORITY_NORMAL, do we have a better name for default_priolist? I
> >still prefer default_priolist over normal_priolist. Go back to
> >I915_PRIORITY_DEFAULT?
> 
> default_priolist is fine I think since it is dual purpose. Primary
> purpose to avoid allocations as you said.
> 
> Although I am still a bit dejected how some userspace could decide
> one day to send everything at I915_PRIORITY_NORMAL - n, in order to
> use I915_PRIORITY_NORMAL as the high prio not requiring
> cap_sys_admin, and in doing so completely defeat the atomic kmalloc
> avoidance. :(

Should we just bite the bullet and install a kmem_cache here?
It didn't solve the kmalloc error handling, but it does at least give us
a freelist. There is a reasonable argument that as soon as userspace
starts using non-default priorities, we may see many different levels
justifying allocating a whole slab upfront.
-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 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Tvrtko Ursulin]

On 03/05/2017 12:37, Chris Wilson wrote:

[snip]


+#include 
+
+static inline void __list_del_many(struct list_head *head,
+  struct list_head *first)
+{
+   head->next = first;
+   first->prev = head;
+}


Btw it is similar to __list_cut_position, but without the second list 
you don't need and deleting the first entry which you do not want.


So I am just thinking if consistent naming with the core function would 
be beneficial like __list_cut_position_before/exclusive?


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/9] drm/i915/execlists: Reduce lock context between schedule/submit_request

[Chris Wilson]

On Fri, May 05, 2017 at 02:30:08PM +0100, Tvrtko Ursulin wrote:
> 
> On 03/05/2017 12:37, Chris Wilson wrote:
> >If we do not require to perform priority bumping, and we haven't yet
> >submitted the request, we can update its priority in situ and skip
> >acquiring the engine locks -- thus avoiding any contention between us
> >and submit/execute.
> >
> >Signed-off-by: Chris Wilson 
> >---
> > drivers/gpu/drm/i915/intel_lrc.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index fb0025627676..ca7f28795e2d 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -767,6 +767,17 @@ static void execlists_schedule(struct 
> >drm_i915_gem_request *request, int prio)
> > list_safe_reset_next(dep, p, dfs_link);
> > }
> >
> >+/* If we didn't need to bump any existing priorites, and we haven't
> 
> priorities
> 
> >+ * yet submitted this request (i..e there is no porential race with
> 
> potential
> 
> >+ * execlists_submit_request()), we can set our own priority and skip
> >+ * acquiring the engine locks.
> >+ */
> >+if (request->priotree.priority == INT_MIN) {
> >+request->priotree.priority = prio;
> >+if (stack.dfs_link.next == stack.dfs_link.prev)
> >+return;
> 
> Move the assignment of the priority under the if?

The assignment always work. I just liked the look of this code more :)
The skip of the assignment is minor benefit. For bonus points, could do
a list_del_entry(_link) after the return.

Sold.
-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 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Tvrtko Ursulin]

On 05/05/2017 14:32, Chris Wilson wrote:

On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:


On 03/05/2017 12:37, Chris Wilson wrote:

struct intel_engine_cs {
@@ -367,6 +373,7 @@ struct intel_engine_cs {

/* Execlists */
struct tasklet_struct irq_tasklet;
+   struct execlist_priolist default_priolist;
struct execlist_port {
struct drm_i915_gem_request *request_count;
#define EXECLIST_COUNT_BITS 2



Just a small bikeshed to consider. Having switched to
I915_PRIORITY_NORMAL, do we have a better name for default_priolist? I
still prefer default_priolist over normal_priolist. Go back to
I915_PRIORITY_DEFAULT?


default_priolist is fine I think since it is dual purpose. Primary 
purpose to avoid allocations as you said.


Although I am still a bit dejected how some userspace could decide one 
day to send everything at I915_PRIORITY_NORMAL - n, in order to use 
I915_PRIORITY_NORMAL as the high prio not requiring cap_sys_admin, and 
in doing so completely defeat the atomic kmalloc avoidance. :(


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Don't force serialisation on marking up execlists irq posted

[Tvrtko Ursulin]

On 03/05/2017 12:37, Chris Wilson wrote:

Since we coordinate with the execlists tasklet using a locked schedule
operation that ensures that after we set the engine->irq_posted we
always have an invocation of the tasklet, we do not need to use a locked
operation to set the engine->irq_posted itself.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8f60c8045b3e..951a7705949e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1360,7 +1360,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)

if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
if (port_count(>execlist_port[0])) {
-   set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
tasklet = true;
}
}



True :)

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 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Chris Wilson]

On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
> 
> On 03/05/2017 12:37, Chris Wilson wrote:
> > struct intel_engine_cs {
> >@@ -367,6 +373,7 @@ struct intel_engine_cs {
> >
> > /* Execlists */
> > struct tasklet_struct irq_tasklet;
> >+struct execlist_priolist default_priolist;
> > struct execlist_port {
> > struct drm_i915_gem_request *request_count;
> > #define EXECLIST_COUNT_BITS 2
> >

Just a small bikeshed to consider. Having switched to
I915_PRIORITY_NORMAL, do we have a better name for default_priolist? I
still prefer default_priolist over normal_priolist. Go back to
I915_PRIORITY_DEFAULT?
-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 7/9] drm/i915/execlists: Reduce lock context between schedule/submit_request

[Tvrtko Ursulin]

On 03/05/2017 12:37, Chris Wilson wrote:

If we do not require to perform priority bumping, and we haven't yet
submitted the request, we can update its priority in situ and skip
acquiring the engine locks -- thus avoiding any contention between us
and submit/execute.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fb0025627676..ca7f28795e2d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -767,6 +767,17 @@ static void execlists_schedule(struct drm_i915_gem_request 
*request, int prio)
list_safe_reset_next(dep, p, dfs_link);
}

+   /* If we didn't need to bump any existing priorites, and we haven't


priorities


+* yet submitted this request (i..e there is no porential race with


potential


+* execlists_submit_request()), we can set our own priority and skip
+* acquiring the engine locks.
+*/
+   if (request->priotree.priority == INT_MIN) {
+   request->priotree.priority = prio;
+   if (stack.dfs_link.next == stack.dfs_link.prev)
+   return;


Move the assignment of the priority under the if?


+   }
+
engine = request->engine;
spin_lock_irq(>timeline->lock);




Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

[Tvrtko Ursulin]

On 03/05/2017 12:37, Chris Wilson wrote:

All the requests at the same priority are executed in FIFO order. They
do not need to be stored in the rbtree themselves, as they are a simple
list within a level. If we move the requests at one priority into a list,
we can then reduce the rbtree to the set of priorities. This should keep
the height of the rbtree small, as the number of active priorities can not
exceed the number of active requests and should be typically only a few.

Currently, we have ~2k possible different priority levels, that may
increase to allow even more fine grained selection. Allocating those in
advance seems a waste (and may be impossible), so we opt for allocating
upon first use, and freeing after its requests are depleted. To avoid
the possibility of an allocation failure causing us to lose a request,
we preallocate the default priority (0) and bump any request to that
priority if we fail to allocate it the appropriate plist. Having a
request (that is ready to run, so not leading to corruption) execute
out-of-order is better than leaking the request (and its dependency
tree) entirely.

There should be a benefit to reducing execlists_dequeue() to principally
using a simple list (and reducing the frequency of both rbtree iteration
and balancing on erase) but for typical workloads, request coalescing
should be small enough that we don't notice any change. The main gain is
from improving PI calls to schedule, and the explicit list within a
level should make request unwinding simpler (we just need to insert at
the head of the list rather than the tail and not have to make the
rbtree search more complicated).

v2: Avoid use-after-free when deleting a depleted priolist

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 ++-
 drivers/gpu/drm/i915/i915_gem_request.c|   4 +-
 drivers/gpu/drm/i915/i915_gem_request.h|   2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |  53 ++
 drivers/gpu/drm/i915/i915_utils.h  |   9 ++
 drivers/gpu/drm/i915/intel_lrc.c   | 159 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h|   7 ++
 7 files changed, 163 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0b5d7142d8d9..a8c7788d986e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3314,7 +3314,6 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)

if (i915.enable_execlists) {
u32 ptr, read, write;
-   struct rb_node *rb;
unsigned int idx;

seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
@@ -3358,9 +3357,14 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
rcu_read_unlock();

spin_lock_irq(>timeline->lock);
-   for (rb = engine->execlist_first; rb; rb = rb_next(rb)) 
{
-   rq = rb_entry(rb, typeof(*rq), priotree.node);
-   print_request(m, rq, "\t\tQ ");
+   for (rb = engine->execlist_first; rb; rb = rb_next(rb)){
+   struct execlist_priolist *plist =
+   rb_entry(rb, typeof(*plist), node);
+
+   list_for_each_entry(rq,
+   >requests,
+   priotree.link)
+   print_request(m, rq, "\t\tQ ");
}
spin_unlock_irq(>timeline->lock);
} else if (INTEL_GEN(dev_priv) > 6) {
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 8d2a5c8e5005..ad2be26923fb 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -159,7 +159,7 @@ i915_priotree_fini(struct drm_i915_private *i915, struct 
i915_priotree *pt)
 {
struct i915_dependency *dep, *next;

-   GEM_BUG_ON(!RB_EMPTY_NODE(>node));
+   GEM_BUG_ON(!list_empty(>link));

/* Everyone we depended upon (the fences we wait to be signaled)
 * should retire before us and remove themselves from our list.
@@ -185,7 +185,7 @@ i915_priotree_init(struct i915_priotree *pt)
 {
INIT_LIST_HEAD(>signalers_list);
INIT_LIST_HEAD(>waiters_list);
-   RB_CLEAR_NODE(>node);
+   INIT_LIST_HEAD(>link);
pt->priority = INT_MIN;
 }

diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index feb81463abc9..6c58f7d87746 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

[Arkadiusz Hiler]

On Fri, May 05, 2017 at 12:49:49PM +0100, Chris Wilson wrote:
> On Fri, May 05, 2017 at 01:31:37PM +0200, Arkadiusz Hiler wrote:
> > On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote:
> > > 
> > > 
> > > On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > > > MediaSDK is not a benchmark.  If I'm not mistaken, it's a userspace
> > > > driver produced by Intel engineers, one which Intel has the full
> > > > capability to change.  What you're saying is that Intel's MediaSDK
> > > > engineers are unwilling to change their software to provide better
> > > > performance for their Linux users.
> > > > 
> > > > That's pretty mental.
> > > You are mistaken. Media SDK is not a driver. It is a user space library
> > > which talks to the user space driver. And Media SDK does not set _any_
> > > caching policies you are discussing here. That's the driver who sets these
> > > policies. I don't want to go further here who supports this driver, Intel 
> > > or
> > > not, but there are mediasdk engineers whom you blame to not willing to do
> > > something and who actually only indirectly are related to this topic.
> > > Please, if you mean driver, say a driver.
> > 
> > You are right. It is very unfortunate that those two were confused.
> > 
> > To further clarify, here's an excerpt from MediaSDK's README.md:
> > 
> > "Intel Media SDK depends on a special version of LibVA which comes with
> > Intel Media Server Studio installation and is not in upstream, so this
> > version is not compatible with the LibVA/driver available at 01org."
> > 
> > 
> > Nonetheless, the main question still stands:
> > 
> > How big is the performance gap when using appropriate, existing entries
> > entries vs the entries proposed here?
> > 
> > 
> > Also a couple more questions arise:
> > 
> > * What about versioning schema? We definitely need a consumer for that.
> > 
> > * The libva you use is a **closed** UMD. It this enough of a reason to
> >   do the change (sans the versioning)? It starts to get blurry here.
> > 
> > Don't get me wrong, I've seen the spec and believe that a lot of hard
> > work was put into determining the entries and the usage scenarios, and
> > that they can benefit us.
> > 
> > I even have some patches ready[0] and I would love to get them upstream,
> > but they have to be tested in reproducible manner, with clear
> > methodology. They need to be discussed and deemed useful by providing
> > real value. We cannot simply relay on opaque claims that they are good
> > for us.
> > 
> > 
> > To do the above I am fiddling with Mesa - if we will see performance
> > boost, then this would provide both a solid reason to add the entries
> > and a consumer for the versioning API.
> > 
> > 
> > As of proprietary libva/MediaSDK combo I see at least three options to
> > do "the 3" vs "extended mocs" testing:
> > 
> > 1. change the libva you use to utilize only the basic 3 entries only and
> >do the testing - if you can change the source
> > 
> > 2. change kernel and fill in entries with copies of the 3 basic ones and
> >do the testing - will work even without the source code of libva
> > 
> > 3. port the MOCS changes to 01org's libva and either use this version
> >from MediaSDK for testing or use some other benchmarks -  this could
> >be the consumer we need
> > 
> > I hope that this will move us forward.
> 
> Michal (W or W) has some patches to allow contexts to set their own mocs,
> which is definitely my preferred solution.
> -Chris

Michal Winiarski (CCed).

IIRC the series was only for render - other rings does not have
context-stored MOCS.

-- 
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/9] drm/i915/execlists: Reduce lock context between schedule/submit_request

[Chris Wilson]

s/context/contention/ in subject

On Wed, May 03, 2017 at 12:37:57PM +0100, Chris Wilson wrote:
> If we do not require to perform priority bumping, and we haven't yet
> submitted the request, we can update its priority in situ and skip
> acquiring the engine locks -- thus avoiding any contention between us
> and submit/execute.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index fb0025627676..ca7f28795e2d 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -767,6 +767,17 @@ static void execlists_schedule(struct 
> drm_i915_gem_request *request, int prio)
>   list_safe_reset_next(dep, p, dfs_link);
>   }
>  
> + /* If we didn't need to bump any existing priorites, and we haven't
> +  * yet submitted this request (i..e there is no porential race with
> +  * execlists_submit_request()), we can set our own priority and skip
> +  * acquiring the engine locks.
> +  */
> + if (request->priotree.priority == INT_MIN) {
> + request->priotree.priority = prio;
> + if (stack.dfs_link.next == stack.dfs_link.prev)
> + return;
> + }
> +
>   engine = request->engine;
>   spin_lock_irq(>timeline->lock);
>  
> -- 
> 2.11.0
> 

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restore GT performance in headless mode with DMC loaded

[Patchwork]

== Series Details ==

Series: drm/i915: Restore GT performance in headless mode with DMC loaded
URL   : https://patchwork.freedesktop.org/series/24017/
State : success

== Summary ==

Series 24017v1 drm/i915: Restore GT performance in headless mode with DMC loaded
https://patchwork.freedesktop.org/api/1.0/series/24017/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:577s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:509s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:548s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:485s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:458s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:566s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:458s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:569s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:460s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:489s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:431s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

369880c1680bf9bde467a40d2a03d3ad32341281 drm-tip: 2017y-05m-04d-15h-00m-33s UTC 
integration manifest
e0b135e drm/i915: Restore GT performance in headless mode with DMC loaded

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4630/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915/execlists: Pack the count into the low bits of the port.request

[Tvrtko Ursulin]

On 05/05/2017 12:16, Chris Wilson wrote:

On Fri, May 05, 2017 at 11:49:21AM +0100, Tvrtko Ursulin wrote:


On 03/05/2017 12:37, Chris Wilson wrote:

+static void port_assign(struct execlist_port *port,
+   struct drm_i915_gem_request *rq)
+{
+   GEM_BUG_ON(rq == port_request(port));
+
+   if (port_isset(port))
+   i915_gem_request_put(port_request(port));
+
+   port_set(port, port_pack(i915_gem_request_get(rq), port_count(port)));
+}


Reason for not having one implementation of port_assign with
enable_nested_signalling outside it in the guc case?


The handling of port.count is a big difference between guc and
ordinary execlists. For execlists we count contexts, for guc we count
requests.


Bah missed it, scrolling up and down and relying on memory is not a 
substitute for split screen..



static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct drm_i915_gem_request *last;
@@ -397,7 +401,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
struct rb_node *rb;
bool submit = false;

-   last = port->request;
+   last = port_request(port);
if (last)
/* WaIdleLiteRestore:bdw,skl
 * Apply the wa NOOPs to prevent ring:HEAD == req:TAIL
@@ -407,7 +411,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 */
last->tail = last->wa_tail;

-   GEM_BUG_ON(port[1].request);
+   GEM_BUG_ON(port_isset([1]));

/* Hardware submission is through 2 ports. Conceptually each port
 * has a (RING_START, RING_HEAD, RING_TAIL) tuple. RING_START is
@@ -464,7 +468,8 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)

GEM_BUG_ON(last->ctx == cursor->ctx);

-   i915_gem_request_assign(>request, last);
+   if (submit)
+   port_assign(port, last);


Optimisation? GEM_BUG_ON(last != port_request(port))?


Kind of, it is so both paths look identical and yes so we do meet the
criteria that last != port_request(port) (because it is silly to the do
the request_count dance if the goal is not to change request_count).


Ok.


@@ -479,7 +484,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
submit = true;
}
if (submit) {
-   i915_gem_request_assign(>request, last);
+   port_assign(port, last);
engine->execlist_first = rb;
}
spin_unlock_irq(>timeline->lock);
@@ -488,16 +493,11 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
execlists_submit_ports(engine);
}

-static bool execlists_elsp_idle(struct intel_engine_cs *engine)
-{
-   return !engine->execlist_port[0].request;
-}
-
static bool execlists_elsp_ready(const struct intel_engine_cs *engine)
{
const struct execlist_port *port = engine->execlist_port;

-   return port[0].count + port[1].count < 2;
+   return port_count([0]) + port_count([1]) < 2;
}

/*
@@ -547,7 +547,9 @@ static void intel_lrc_irq_handler(unsigned long data)
tail = GEN8_CSB_WRITE_PTR(head);
head = GEN8_CSB_READ_PTR(head);
while (head != tail) {
+   struct drm_i915_gem_request *rq;
unsigned int status;
+   unsigned int count;

if (++head == GEN8_CSB_ENTRIES)
head = 0;
@@ -577,20 +579,24 @@ static void intel_lrc_irq_handler(unsigned long data)
GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
 port[0].context_id);

-   GEM_BUG_ON(port[0].count == 0);
-   if (--port[0].count == 0) {
+   rq = port_unpack([0], );
+   GEM_BUG_ON(count == 0);
+   if (--count == 0) {


If you changed this to be:

count--;
port_set(...);
if (count > 0)
continue;

It would be perhaps a bit more readable, but a potentially useless
port_set on the other hand. Not sure.


We expect to overwrite port in the common path, or at least that's my
expectation. Decrementing count for lite-restore should be the
exception. Part of the intention is to do the minimal amount of work
(especially avoiding the appearance of setting port.count = 0
prematurely) and pass the later port.count == 0 assert.


I've seen the mode where we just append and append and append with no 
requests out coming out in a while :), but I agree it is not the typical 
case. So as I said I am fine with this as it is.





GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);
-   
GEM_BUG_ON(!i915_gem_request_completed(port[0].request));
-   execlists_context_status_change(port[0].request,
-  

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

[Chris Wilson]

On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> It seems that the DMC likes to transition between the DC states
> a lot when there are no connected displays (no active power
> domains) during simple command submission.
> 
> This frantic activity on DC states has a terrible impact on the
> performance of the overall chip with huge latencies observed in
> the interrupt handlers and elsewhere. Simple tests like
> igt/gem_latency -n 0 are slowed down by a factor of eight.
> 
> Work around it by grabbing a modeset display power domain whilst
> there is any GT activity. This seems to be effective in making
> the DMC keep its paws off the chip.
> 
> On the other hand this may have a negative impact on the overall
> power budget of the chip and so could still affect performance.

Please add this as a comment to the code, I think in mark_busy(). I
don't think this w/a will remain applicable forever and so merits a
continual reminder and being discussed again in future.
 
> This version limits the workaround got SKL GT3 and GT4 parts but
> this is just due the absence of testing on other platforms. It
> is possible we will have to apply it wider.
> 
> Signed-off-by: Tvrtko Ursulin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 5 +
>  drivers/gpu/drm/i915/i915_gem.c | 4 
>  drivers/gpu/drm/i915/i915_gem_request.c | 3 +++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 320c16df1c9c..4d58e2e28c2f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2990,6 +2990,11 @@ intel_info(const struct drm_i915_private *dev_priv)
>  
>  #define HAS_DECOUPLED_MMIO(dev_priv) 
> (INTEL_INFO(dev_priv)->has_decoupled_mmio)
>  
> +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> + HAS_CSR(dev_priv) && \
> + (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv)) && \
> + (dev_priv)->csr.dmc_payload

csr.dmc_payload is a bit of a surprise, but looks correct.

Acked-by: Chris Wilson 
-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] drm/i915: Update MOCS settings for gen 9

[Chris Wilson]

On Fri, May 05, 2017 at 01:31:37PM +0200, Arkadiusz Hiler wrote:
> On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote:
> > 
> > 
> > On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > > MediaSDK is not a benchmark.  If I'm not mistaken, it's a userspace
> > > driver produced by Intel engineers, one which Intel has the full
> > > capability to change.  What you're saying is that Intel's MediaSDK
> > > engineers are unwilling to change their software to provide better
> > > performance for their Linux users.
> > > 
> > > That's pretty mental.
> > You are mistaken. Media SDK is not a driver. It is a user space library
> > which talks to the user space driver. And Media SDK does not set _any_
> > caching policies you are discussing here. That's the driver who sets these
> > policies. I don't want to go further here who supports this driver, Intel or
> > not, but there are mediasdk engineers whom you blame to not willing to do
> > something and who actually only indirectly are related to this topic.
> > Please, if you mean driver, say a driver.
> 
> You are right. It is very unfortunate that those two were confused.
> 
> To further clarify, here's an excerpt from MediaSDK's README.md:
> 
> "Intel Media SDK depends on a special version of LibVA which comes with
> Intel Media Server Studio installation and is not in upstream, so this
> version is not compatible with the LibVA/driver available at 01org."
> 
> 
> Nonetheless, the main question still stands:
> 
> How big is the performance gap when using appropriate, existing entries
> entries vs the entries proposed here?
> 
> 
> Also a couple more questions arise:
> 
> * What about versioning schema? We definitely need a consumer for that.
> 
> * The libva you use is a **closed** UMD. It this enough of a reason to
>   do the change (sans the versioning)? It starts to get blurry here.
> 
> Don't get me wrong, I've seen the spec and believe that a lot of hard
> work was put into determining the entries and the usage scenarios, and
> that they can benefit us.
> 
> I even have some patches ready[0] and I would love to get them upstream,
> but they have to be tested in reproducible manner, with clear
> methodology. They need to be discussed and deemed useful by providing
> real value. We cannot simply relay on opaque claims that they are good
> for us.
> 
> 
> To do the above I am fiddling with Mesa - if we will see performance
> boost, then this would provide both a solid reason to add the entries
> and a consumer for the versioning API.
> 
> 
> As of proprietary libva/MediaSDK combo I see at least three options to
> do "the 3" vs "extended mocs" testing:
> 
> 1. change the libva you use to utilize only the basic 3 entries only and
>do the testing - if you can change the source
> 
> 2. change kernel and fill in entries with copies of the 3 basic ones and
>do the testing - will work even without the source code of libva
> 
> 3. port the MOCS changes to 01org's libva and either use this version
>from MediaSDK for testing or use some other benchmarks -  this could
>be the consumer we need
> 
> I hope that this will move us forward.

Michal (W or W) has some patches to allow contexts to set their own mocs,
which is definitely my preferred solution.
-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 13/13] tests/gem_exec_nop: Disable headless subtest on cairoless Android

[Arkadiusz Hiler]

On Thu, May 04, 2017 at 11:00:33AM +0300, Petri Latvala wrote:
> On Wed, Apr 19, 2017 at 01:01:55PM +0200, Arkadiusz Hiler wrote:
> > Currently whole igt_kms.c is disabled while compiling on Android without
> > cairo, so this tests does not compile.
> > 
> > There should be cleaner a way to disable only cairo dependant parts
> > which should allow us to enable at least some of the KMS tests, but
> > that's a bigger rework for another time.
> > 
> > Signed-off-by: Arkadiusz Hiler 
> > ---
> >  lib/Android.mk   | 1 +
> >  tests/gem_exec_nop.c | 4 
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/lib/Android.mk b/lib/Android.mk
> > index 31f88be..dc538b8 100644
> > --- a/lib/Android.mk
> > +++ b/lib/Android.mk
> > @@ -38,6 +38,7 @@ ifeq ("${ANDROID_HAS_CAIRO}", "1")
> >  LOCAL_C_INCLUDES += $(ANDROID_BUILD_TOP)/external/cairo-1.12.16/src
> >  LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=1 -DIGT_DATADIR=\".\" 
> > -DIGT_SRCDIR=\".\"
> >  else
> > +
> >  skip_lib_list := \
> >  igt_kms.c \
> >  igt_kms.h \
> > diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
> > index 66c2fc1..967caef 100644
> > --- a/tests/gem_exec_nop.c
> > +++ b/tests/gem_exec_nop.c
> > @@ -138,6 +138,7 @@ stable_nop_on_ring(int fd, uint32_t handle, unsigned 
> > int engine,
> > return n;
> >  }
> >  
> > +#if (!defined(ANDROID)) || (defined(ANDROID) && ANDROID_HAS_CAIRO)
> 
> 
> Tautological check for ANDROID being defined. Is it too confusing to reduce 
> this to
> 
> #if !defined(ANDROID) || ANDROID_HAS_CAIRO

Indeed, thanks.

-- 
Cheers,
Arek

> >  #define assert_within_epsilon(x, ref, tolerance) \
> >  igt_assert_f((x) <= (1.0 + tolerance) * ref && \
> >   (x) >= (1.0 - tolerance) * ref, \
> > @@ -178,6 +179,7 @@ static void headless(int fd, uint32_t handle)
> > /* check that the two execution speeds are roughly the same */
> > assert_within_epsilon(n_headless, n_display, 0.1f);
> >  }
> > +#endif
> >  
> >  static bool ignore_engine(int fd, unsigned engine)
> >  {
> > @@ -561,8 +563,10 @@ igt_main
> > igt_subtest("context-sequential")
> > sequential(device, handle, FORKED | CONTEXT, 150);
> >  
> > +#if (!defined(ANDROID)) || (defined(ANDROID) && ANDROID_HAS_CAIRO)
> 
> 
> Likewise.
> 
> 
> 
> 
> --
> Petri Latvala
> 
> 
> 
> 
> 
> > igt_subtest("headless")
> > headless(device, handle);
> > +#endif
> >  
> > igt_fixture {
> > igt_stop_hang_detector();
> > -- 
> > 2.9.3
> > 
> > ___
> > 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 i-g-t 05/13] chamelium: Fix build issues on Android

[Arkadiusz Hiler]

On Tue, May 02, 2017 at 12:53:16PM +0300, Petri Latvala wrote:
> On Wed, Apr 19, 2017 at 01:01:47PM +0200, Arkadiusz Hiler wrote:
> > Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H"
> > guard, and the file itself was included unconditionally.
> 
> I see unconditional config.h inclusion in several other places,
> is igt_chamelium.h the only file where it causes problems?

Yes that we the reason for this ifdef, but that might have been fixed in
other way by different patch as I can't reproduce the error anymore.

I'll drop that from this patch and later we can have one dedicated to
adding ifdefs everywhere.

The approach with config_android.h would need that, so that would be
good series to do it.

-- 
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

It seems that the DMC likes to transition between the DC states
a lot when there are no connected displays (no active power
domains) during simple command submission.

This frantic activity on DC states has a terrible impact on the
performance of the overall chip with huge latencies observed in
the interrupt handlers and elsewhere. Simple tests like
igt/gem_latency -n 0 are slowed down by a factor of eight.

Work around it by grabbing a modeset display power domain whilst
there is any GT activity. This seems to be effective in making
the DMC keep its paws off the chip.

On the other hand this may have a negative impact on the overall
power budget of the chip and so could still affect performance.

This version limits the workaround got SKL GT3 and GT4 parts but
this is just due the absence of testing on other platforms. It
is possible we will have to apply it wider.

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 drivers/gpu/drm/i915/i915_gem.c | 4 
 drivers/gpu/drm/i915/i915_gem_request.c | 3 +++
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 320c16df1c9c..4d58e2e28c2f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2990,6 +2990,11 @@ intel_info(const struct drm_i915_private *dev_priv)
 
 #define HAS_DECOUPLED_MMIO(dev_priv) (INTEL_INFO(dev_priv)->has_decoupled_mmio)
 
+#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
+   HAS_CSR(dev_priv) && \
+   (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv)) && \
+   (dev_priv)->csr.dmc_payload
+
 #include "i915_trace.h"
 
 static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private 
*dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b2727905ef2b..c52d863f409c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3200,7 +3200,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
 
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
+
intel_runtime_pm_put(dev_priv);
+
+   if (NEEDS_CSR_GT_PERF_WA(dev_priv))
+   intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
 out_unlock:
mutex_unlock(>struct_mutex);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 10361c7e3b37..10a3b51f6362 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -873,6 +873,9 @@ static void i915_gem_mark_busy(const struct intel_engine_cs 
*engine)
 
GEM_BUG_ON(!dev_priv->gt.active_requests);
 
+   if (NEEDS_CSR_GT_PERF_WA(dev_priv))
+   intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
+
intel_runtime_pm_get_noresume(dev_priv);
dev_priv->gt.awake = true;
 
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Make scratch register base and count flexible

[Michal Wajdeczko]

We are using some scratch registers in MMIO based send function.
Make their base and count flexible in preparation of upcoming
GuC firmware/hardware changes. While around, change cmd len
parameter verification from WARN_ON to GEM_BUG_ON as we don't
need this all the time.

v2: call out WARN/GEM_BUG change in the commit msg (Daniele)
v3: don't overqualify the ints (Chris)

Signed-off-by: Michal Wajdeczko 
Suggested-by: Daniele Ceraolo Spurio 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Jani Nikula 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_uc.c | 41 ++---
 drivers/gpu/drm/i915/intel_uc.h |  7 +++
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 72f49e6..9d11c42 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -260,9 +260,36 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
__intel_uc_fw_fini(_priv->huc.fw);
 }
 
+static inline i915_reg_t guc_send_reg(struct intel_guc *guc, u32 i)
+{
+   GEM_BUG_ON(!guc->send_regs.base);
+   GEM_BUG_ON(!guc->send_regs.count);
+   GEM_BUG_ON(i >= guc->send_regs.count);
+
+   return _MMIO(guc->send_regs.base + 4 * i);
+}
+
+static void guc_init_send_regs(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   enum forcewake_domains fw_domains = 0;
+   u32 i;
+
+   guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0));
+   guc->send_regs.count = SOFT_SCRATCH_COUNT - 1;
+
+   for (i = 0; i < guc->send_regs.count; i++) {
+   fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
+   guc_send_reg(guc, i),
+   FW_REG_READ | FW_REG_WRITE);
+   }
+   guc->send_regs.fw_domains = fw_domains;
+}
+
 static int guc_enable_communication(struct intel_guc *guc)
 {
/* XXX: placeholder for alternate setup */
+   guc_init_send_regs(guc);
guc->send = intel_guc_send_mmio;
return 0;
 }
@@ -407,19 +434,19 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
int i;
int ret;
 
-   if (WARN_ON(len < 1 || len > 15))
-   return -EINVAL;
+   GEM_BUG_ON(!len);
+   GEM_BUG_ON(len > guc->send_regs.count);
 
mutex_lock(>send_mutex);
-   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_BLITTER);
+   intel_uncore_forcewake_get(dev_priv, guc->send_regs.fw_domains);
 
dev_priv->guc.action_count += 1;
dev_priv->guc.action_cmd = action[0];
 
for (i = 0; i < len; i++)
-   I915_WRITE(SOFT_SCRATCH(i), action[i]);
+   I915_WRITE(guc_send_reg(guc, i), action[i]);
 
-   POSTING_READ(SOFT_SCRATCH(i - 1));
+   POSTING_READ(guc_send_reg(guc, i - 1));
 
intel_guc_notify(guc);
 
@@ -428,7 +455,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
 * Fast commands should still complete in 10us.
 */
ret = __intel_wait_for_register_fw(dev_priv,
-  SOFT_SCRATCH(0),
+  guc_send_reg(guc, 0),
   INTEL_GUC_RECV_MASK,
   INTEL_GUC_RECV_MASK,
   10, 10, );
@@ -450,7 +477,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
}
dev_priv->guc.action_status = status;
 
-   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_BLITTER);
+   intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
mutex_unlock(>send_mutex);
 
return ret;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 097289b..4dd39a7 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -205,6 +205,13 @@ struct intel_guc {
uint64_t submissions[I915_NUM_ENGINES];
uint32_t last_seqno[I915_NUM_ENGINES];
 
+   /* GuC's FW specific registers used in MMIO send */
+   struct {
+   u32 base;
+   unsigned int count;
+   unsigned int fw_domains; /* enum forcewake_domains */
+   } send_regs;
+
/* To serialize the intel_guc_send actions */
struct mutex send_mutex;
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

[Arkadiusz Hiler]

On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote:
> 
> 
> On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > MediaSDK is not a benchmark.  If I'm not mistaken, it's a userspace
> > driver produced by Intel engineers, one which Intel has the full
> > capability to change.  What you're saying is that Intel's MediaSDK
> > engineers are unwilling to change their software to provide better
> > performance for their Linux users.
> > 
> > That's pretty mental.
> You are mistaken. Media SDK is not a driver. It is a user space library
> which talks to the user space driver. And Media SDK does not set _any_
> caching policies you are discussing here. That's the driver who sets these
> policies. I don't want to go further here who supports this driver, Intel or
> not, but there are mediasdk engineers whom you blame to not willing to do
> something and who actually only indirectly are related to this topic.
> Please, if you mean driver, say a driver.

You are right. It is very unfortunate that those two were confused.

To further clarify, here's an excerpt from MediaSDK's README.md:

"Intel Media SDK depends on a special version of LibVA which comes with
Intel Media Server Studio installation and is not in upstream, so this
version is not compatible with the LibVA/driver available at 01org."


Nonetheless, the main question still stands:

How big is the performance gap when using appropriate, existing entries
entries vs the entries proposed here?


Also a couple more questions arise:

* What about versioning schema? We definitely need a consumer for that.

* The libva you use is a **closed** UMD. It this enough of a reason to
  do the change (sans the versioning)? It starts to get blurry here.

Don't get me wrong, I've seen the spec and believe that a lot of hard
work was put into determining the entries and the usage scenarios, and
that they can benefit us.

I even have some patches ready[0] and I would love to get them upstream,
but they have to be tested in reproducible manner, with clear
methodology. They need to be discussed and deemed useful by providing
real value. We cannot simply relay on opaque claims that they are good
for us.


To do the above I am fiddling with Mesa - if we will see performance
boost, then this would provide both a solid reason to add the entries
and a consumer for the versioning API.


As of proprietary libva/MediaSDK combo I see at least three options to
do "the 3" vs "extended mocs" testing:

1. change the libva you use to utilize only the basic 3 entries only and
   do the testing - if you can change the source

2. change kernel and fill in entries with copies of the 3 basic ones and
   do the testing - will work even without the source code of libva

3. port the MOCS changes to 01org's libva and either use this version
   from MediaSDK for testing or use some other benchmarks -  this could
   be the consumer we need

I hope that this will move us forward.

[0]: https://github.com/ivyl/linux/commits/mocs

-- 
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv4 2/3] drm/prime: Introduce drm_gem_prime_import_dev

[kbuild test robot]

Hi Laura,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170505]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Laura-Abbott/dma_buf-import-support-for-vgem/20170505-173856
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All warnings (new ones prefixed by >>):

   In file included from include/drm/drm_file.h:38:0,
from drivers/gpu/drm/drm_file.c:38:
>> include/drm/drm_prime.h:71:14: warning: 'struct device' declared inside 
>> parameter list will not be visible outside of this definition or declaration
  struct device *attach_dev);
 ^~

vim +71 include/drm/drm_prime.h

55  
56  struct drm_device;
57  struct drm_gem_object;
58  struct drm_file;
59  
60  struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
61   struct drm_gem_object *obj,
62   int flags);
63  int drm_gem_prime_handle_to_fd(struct drm_device *dev,
64 struct drm_file *file_priv, uint32_t 
handle, uint32_t flags,
65 int *prime_fd);
66  struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
67  struct dma_buf *dma_buf);
68  
69  struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev,
70  struct dma_buf *dma_buf,
  > 71  struct device 
*attach_dev);
72  
73  int drm_gem_prime_fd_to_handle(struct drm_device *dev,
74 struct drm_file *file_priv, int 
prime_fd, uint32_t *handle);
75  struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
76struct dma_buf_export_info 
*exp_info);
77  void drm_gem_dmabuf_release(struct dma_buf *dma_buf);
78  
79  int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
**pages,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915/execlists: Pack the count into the low bits of the port.request

[Chris Wilson]

On Fri, May 05, 2017 at 11:49:21AM +0100, Tvrtko Ursulin wrote:
> 
> On 03/05/2017 12:37, Chris Wilson wrote:
> >+static void port_assign(struct execlist_port *port,
> >+struct drm_i915_gem_request *rq)
> >+{
> >+GEM_BUG_ON(rq == port_request(port));
> >+
> >+if (port_isset(port))
> >+i915_gem_request_put(port_request(port));
> >+
> >+port_set(port, port_pack(i915_gem_request_get(rq), port_count(port)));
> >+}
> 
> Reason for not having one implementation of port_assign with
> enable_nested_signalling outside it in the guc case?

The handling of port.count is a big difference between guc and
ordinary execlists. For execlists we count contexts, for guc we count
requests.

> > static void execlists_dequeue(struct intel_engine_cs *engine)
> > {
> > struct drm_i915_gem_request *last;
> >@@ -397,7 +401,7 @@ static void execlists_dequeue(struct intel_engine_cs 
> >*engine)
> > struct rb_node *rb;
> > bool submit = false;
> >
> >-last = port->request;
> >+last = port_request(port);
> > if (last)
> > /* WaIdleLiteRestore:bdw,skl
> >  * Apply the wa NOOPs to prevent ring:HEAD == req:TAIL
> >@@ -407,7 +411,7 @@ static void execlists_dequeue(struct intel_engine_cs 
> >*engine)
> >  */
> > last->tail = last->wa_tail;
> >
> >-GEM_BUG_ON(port[1].request);
> >+GEM_BUG_ON(port_isset([1]));
> >
> > /* Hardware submission is through 2 ports. Conceptually each port
> >  * has a (RING_START, RING_HEAD, RING_TAIL) tuple. RING_START is
> >@@ -464,7 +468,8 @@ static void execlists_dequeue(struct intel_engine_cs 
> >*engine)
> >
> > GEM_BUG_ON(last->ctx == cursor->ctx);
> >
> >-i915_gem_request_assign(>request, last);
> >+if (submit)
> >+port_assign(port, last);
> 
> Optimisation? GEM_BUG_ON(last != port_request(port))?

Kind of, it is so both paths look identical and yes so we do meet the
criteria that last != port_request(port) (because it is silly to the do
the request_count dance if the goal is not to change request_count).

> >@@ -479,7 +484,7 @@ static void execlists_dequeue(struct intel_engine_cs 
> >*engine)
> > submit = true;
> > }
> > if (submit) {
> >-i915_gem_request_assign(>request, last);
> >+port_assign(port, last);
> > engine->execlist_first = rb;
> > }
> > spin_unlock_irq(>timeline->lock);
> >@@ -488,16 +493,11 @@ static void execlists_dequeue(struct intel_engine_cs 
> >*engine)
> > execlists_submit_ports(engine);
> > }
> >
> >-static bool execlists_elsp_idle(struct intel_engine_cs *engine)
> >-{
> >-return !engine->execlist_port[0].request;
> >-}
> >-
> > static bool execlists_elsp_ready(const struct intel_engine_cs *engine)
> > {
> > const struct execlist_port *port = engine->execlist_port;
> >
> >-return port[0].count + port[1].count < 2;
> >+return port_count([0]) + port_count([1]) < 2;
> > }
> >
> > /*
> >@@ -547,7 +547,9 @@ static void intel_lrc_irq_handler(unsigned long data)
> > tail = GEN8_CSB_WRITE_PTR(head);
> > head = GEN8_CSB_READ_PTR(head);
> > while (head != tail) {
> >+struct drm_i915_gem_request *rq;
> > unsigned int status;
> >+unsigned int count;
> >
> > if (++head == GEN8_CSB_ENTRIES)
> > head = 0;
> >@@ -577,20 +579,24 @@ static void intel_lrc_irq_handler(unsigned long data)
> > GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
> >  port[0].context_id);
> >
> >-GEM_BUG_ON(port[0].count == 0);
> >-if (--port[0].count == 0) {
> >+rq = port_unpack([0], );
> >+GEM_BUG_ON(count == 0);
> >+if (--count == 0) {
> 
> If you changed this to be:
> 
> count--;
> port_set(...);
> if (count > 0)
>   continue;
> 
> It would be perhaps a bit more readable, but a potentially useless
> port_set on the other hand. Not sure.

We expect to overwrite port in the common path, or at least that's my
expectation. Decrementing count for lite-restore should be the
exception. Part of the intention is to do the minimal amount of work
(especially avoiding the appearance of setting port.count = 0
prematurely) and pass the later port.count == 0 assert.

> > GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);
> >-
> >GEM_BUG_ON(!i915_gem_request_completed(port[0].request));
> >-execlists_context_status_change(port[0].request,
> >-
> >INTEL_CONTEXT_SCHEDULE_OUT);
> >+GEM_BUG_ON(!i915_gem_request_completed(rq));
> >+

Re: [Intel-gfx] [PATCH 3/9] drm/i915/execlists: Pack the count into the low bits of the port.request

[Tvrtko Ursulin]

On 03/05/2017 12:37, Chris Wilson wrote:

add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187)
function old new   delta
execlists_submit_ports   262 471+209
port_assign.isra   - 136+136
capture 63446359 +15
reset_common_ring438 452 +14
execlists_submit_request 228 238 +10
gen8_init_common_ring334 341  +7
intel_engine_is_idle 106 105  -1
i915_engine_info23142290 -24
__i915_gem_set_wedged_BKL485 411 -74
intel_lrc_irq_handler   17891604-185
execlists_update_context 294   --294

The most important change there is the improve to the
intel_lrc_irq_handler and excclist_submit_ports (net improvement since
execlists_update_context is now inlined).

v2: Use the port_api() for guc as well (even though currently we do not
pack any counters in there, yet) and hide all port->request_count inside
the helpers.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  32 
 drivers/gpu/drm/i915/i915_gem.c|   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  13 +++-
 drivers/gpu/drm/i915/i915_guc_submission.c |  32 +---
 drivers/gpu/drm/i915/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 117 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|  10 ++-
 7 files changed, 122 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470177b5..0b5d7142d8d9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3315,6 +3315,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
if (i915.enable_execlists) {
u32 ptr, read, write;
struct rb_node *rb;
+   unsigned int idx;

seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
   I915_READ(RING_EXECLIST_STATUS_LO(engine)),
@@ -3332,8 +,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
if (read > write)
write += GEN8_CSB_ENTRIES;
while (read < write) {
-   unsigned int idx = ++read % GEN8_CSB_ENTRIES;
-
+   idx = ++read % GEN8_CSB_ENTRIES;
seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, context: 
%d\n",
   idx,
   
I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
@@ -3341,21 +3341,19 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
}

rcu_read_lock();
-   rq = READ_ONCE(engine->execlist_port[0].request);
-   if (rq) {
-   seq_printf(m, "\t\tELSP[0] count=%d, ",
-  engine->execlist_port[0].count);
-   print_request(m, rq, "rq: ");
-   } else {
-   seq_printf(m, "\t\tELSP[0] idle\n");
-   }
-   rq = READ_ONCE(engine->execlist_port[1].request);
-   if (rq) {
-   seq_printf(m, "\t\tELSP[1] count=%d, ",
-  engine->execlist_port[1].count);
-   print_request(m, rq, "rq: ");
-   } else {
-   seq_printf(m, "\t\tELSP[1] idle\n");
+   for (idx = 0; idx < ARRAY_SIZE(engine->execlist_port); 
idx++) {
+   unsigned int count;
+
+   rq = port_unpack(>execlist_port[idx],
+);
+   if (rq) {
+   seq_printf(m, "\t\tELSP[%d] count=%d, ",
+  idx, count);
+   print_request(m, rq, "rq: ");
+   } else {
+   seq_printf(m, "\t\tELSP[%d] idle\n",
+  idx);
+   }
}
rcu_read_unlock();

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix rawclk readout for g4x

[Ville Syrjälä]

On Fri, May 05, 2017 at 09:48:08AM +0300, Jani Nikula wrote:
> On Thu, 04 May 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Turns out our skills in decoding the CLKCFG register weren't good
> > enough. On this particular elk the answer we got was 400 MHz when
> > in reality the clock was running at 266 MHz, which then caused us
> > to program a bogus AUX clock divider that caused all AUX communication
> > to fail.
> >
> > Sadly the docs are now in bit heaven, so the fix will have to be based
> > on empirical evidence. Using another elk machine I was able to frob
> > the FSB frequency from the BIOS and see how it affects the CLKCFG
> > register. The machine seesm to use a frequency of 266 MHz by default,
> > and fortunately it still boot even with the 50% CPU overclock that
> > we get when we bump the FSB up to 400 MHz.
> >
> > It turns out the actual FSB frequency and the register have no real
> > link whatsoever. The register value is based on some straps or something,
> > but fortunately those too can be configured from the BIOS on this board,
> > although it doesn't seem to respect the settings 100%. In the end I was
> > able to derive the following relationship:
> >
> > BIOS FSB / strap | CLKCFG
> > -
> > 200  | 0x2
> > 266  | 0x0
> > 333  | 0x4
> > 400  | 0x4
> >
> > So only the 200 and 400 MHz cases actually match how we're currently
> > decoding that register. But as the comment next to some of the defines
> > says, we have been just guessing anyway.
> >
> > So let's fix things up so that at least the 266 MHz case will work
> > correctly as that is actually the setting used by both the buggy
> > machine and my test machine.
> >
> > The fact that 333 and 400 MHz BIOS settings result in the same register
> > value is a little disappointing, as that means we can't tell them apart.
> > However, according to the gmch datasheet for both elk and ctg 400 Mhz is
> > not even a supported FSB frequency, so I'm going to make the assumption
> > that we should decode it as 333 MHz instead.
> 
> If you look at b11248df4c0d ("drm/i915: Add CLKCFG register definition")
> and 7662c8bd6545 ("drm/i915: add FIFO watermark support"), the original
> values seem to be on the guesswork side as well...

Some of them do match what's in the gmch datasheets for some platforms.
But sadly all the gmch datasheet are very incomplete, and some lack this
register entirely.

I would prefer to find a way to read this out from some actual PLL or
something, because these strap values might not have anything to do with
reality if the user has adjusted the FSB manually via the BIOS. But
yeah, -ENODOCS so there's not much we can do.

> 
> As such can't review, but
> 
> Acked-by: Jani Nikula 
> 
> >
> > Cc: sta...@vger.kernel.org
> > Cc: Tomi Sarvela 
> > Reported-by: Tomi Sarvela 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h| 10 +++---
> >  drivers/gpu/drm/i915/intel_cdclk.c |  6 ++
> >  2 files changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index ee8170cda93e..524fdfda9d45 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3059,10 +3059,14 @@ enum skl_disp_power_wells {
> >  #define CLKCFG_FSB_667 (3 << 0)
> > /* hrawclk 166 */
> >  #define CLKCFG_FSB_800 (2 << 0)
> > /* hrawclk 200 */
> >  #define CLKCFG_FSB_1067(6 << 0)
> > /* hrawclk 266 */
> > +#define CLKCFG_FSB_1067_ALT(0 << 0)
> > /* hrawclk 266 */
> >  #define CLKCFG_FSB_1333(7 << 0)
> > /* hrawclk 333 */
> > -/* Note, below two are guess */
> > -#define CLKCFG_FSB_1600(4 << 0)
> > /* hrawclk 400 */
> > -#define CLKCFG_FSB_1600_ALT(0 << 0)
> > /* hrawclk 400 */
> > +/*
> > + * Note that on at least on ELK the below value is reported for both
> > + * 333 and 400 MHz BIOS FSB setting, but given that the gmch datasheet
> > + * lists only 200/266/333 MHz FSB as supported let's decode it as 333 MHz.
> > + */
> > +#define CLKCFG_FSB_1333_ALT(4 << 0)
> > /* hrawclk 333 */
> >  #define CLKCFG_FSB_MASK(7 << 0)
> >  #define CLKCFG_MEM_533 (1 << 4)
> >  #define CLKCFG_MEM_667 (2 << 4)
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > 

Re: [Intel-gfx] i915 4.9 regression: DP AUX CH sanitization no longer working on Asus desktops

[Ville Syrjälä]

On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
> On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
>  wrote:
> > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
> > that are set when there is no VBT") fixes things for you.
> 
> I think this is not going to help. This would only make a difference
> when there is no VBT at all at which point we would see this message
> in the logs:
> 
> DRM_INFO("Failed to find VBIOS tables (VBT)\n");

No, the patch will in fact make a difference only when there is a VBT.

> 
> but in this case we have a VBT for ports B, C and E.
> 
>  [drm:intel_bios_init [i915]] Port B VBT info: DP:1 HDMI:1 DVI:1 EDP:0 CRT:0
>  [drm:intel_bios_init [i915]] VBT HDMI level shift for port B: 8
>  [drm:intel_bios_init [i915]] Port C VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0
>  [drm:intel_bios_init [i915]] VBT HDMI level shift for port C: 8
>  [drm:intel_bios_init [i915]] Port E VBT info: DP:1 HDMI:0 DVI:0 EDP:0 CRT:0
>  [drm:intel_bios_init [i915]] VBT HDMI level shift for port E: 0
> 
> Let me know if I'm missing something and we will test it anyway

Please do.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not sync RCU during shrinking

[Patchwork]

== Series Details ==

Series: drm/i915: Do not sync RCU during shrinking
URL   : https://patchwork.freedesktop.org/series/24008/
State : success

== Summary ==

Series 24008v1 drm/i915: Do not sync RCU during shrinking
https://patchwork.freedesktop.org/api/1.0/series/24008/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-byt-j1900) fdo#100652

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100652 https://bugs.freedesktop.org/show_bug.cgi?id=100652

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:427s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:428s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:541s
fi-byt-j1900 total:278  pass:253  dwarn:1   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:414s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:489s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:458s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:462s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:576s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:460s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:427s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:400s

369880c1680bf9bde467a40d2a03d3ad32341281 drm-tip: 2017y-05m-04d-15h-00m-33s UTC 
integration manifest
517be4b drm/i915: Do not sync RCU during shrinking

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4629/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

[Jani Nikula]

On Fri, 05 May 2017, Sanford Rockowitz  wrote:
> I am the author of ddcutil (www.ddcutil.com), a Linux utility that
> manages monitor settings using DDC/CI. I am seeing a pattern of user
> error reports in which I2C communication is not working when a system
> with a recent Intel chip, using the i915 driver, is plugged into a
> docking station.  Communication works when the video cable is plugged
> directly into the laptop.   There also seems to be a correlation with
> whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is
> being executed), though this correlation is not as clear.
>
> I'm not sure how best to go about reporting these issues.  The usual bug
> reporting mechanism asks for detailed information about a specific
> system, which I don't have.   What I do have is the ability to see a
> pattern.
>
> Because I2C communication is so fragile (dependencies on hardware
> quirks, drivers, etc), ddcutil (which is written in C) has an extensive
> subsystem devoted to remotely diagnosing user configurations.  It
> already reports DDC (i.e. I2C) communication errors, and has interfaces
> to udev, libdrm, and x11 libraries.  If there is some i915 specific code
> I could add to refine the diagnosis, I would be happy to add that. 
> (Note: ddcutil is entirely a user space program, using the i2c-dev
> interface.)
>
> Suggestions on how to proceed appreciated.

The issues are related to DP MST (Multi-Stream Transport) that the docks
use nowadays. The single DP link is divided to several logical links to
sink devices. The I2C communication needs to be encapsulated to remote
I2C-over-AUX reads and writes, with the logical DP MST addresses, to
route them to the correct sinks. In kernel, this is handled by the MST
topology manager.

Instead of using the I2C device directly for, say, card0-DP-1 or
DPDDC-A, you need to be using the dynamically created and removed DP MST
I2C devices that wrap the communications to remote I2C-over-AUX. Frankly
I am not sure if the naming or parent/child relationships of the devices
are quite right (based on looking at the code), but you should find the
sysfs name attribute will be DPMST. I'm also not sure how you can
associate those with the physical devices you have.

If you have an option to tell your tool which I2C device to use, that
should get you started and debugging. If there are issues with that,
please let us know.

In the long run, we should probably do something to make the discovery
of the DP MST I2C devices easier, with naming and/or better parent/child
relationships of the devices. It's just that the userspace I2C interface
was probably pretty far down on the list of priorities when writing DP
MST.


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 v1] ACPI: Switch to use generic UUID API

[Christoph Hellwig]

On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote:
> To complete the picture for folks not cc'ed on my patches,
> xfs use case suggests there is also justification for the additional helpers:
> 
> uuid_is_null() / uuid_equal()
> guid_is_null() / guid_equal()

The is_null is useful and I bet we'll find other instances.  I'm
not sure _equals really adds much value over the existing _cmp
helpers, but on the other hand they are so trivial that we might as
well add them.

The other thing XFS has is uuid_copy.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Zhenyu Wang]

On 2017.05.05 11:55:14 +0300, Joonas Lahtinen wrote:
> + Daniel
> 
> On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote:
> > On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote:
> > > 
> > > Currently GVT-g cannot work properly when host GuC submission
> > > is enabled, so disable GVT in this case.
> > > 
> > > Cc: Zhenyu Wang 
> > > Signed-off-by: Chuanxiao Dong 
> 
> 
> 
> > > @@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
> > >   goto bail;
> > >   }
> > >  
> > > + if (i915.enable_guc_submission) {
> > > + DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to 
> > > enabled GuC submission [i915.enable_guc_submission module parameter]\n");
> 
> Guest module parameter is not the correct way of detetecting if host
> has GuC submission enabled. And even if it was, the message is overly
> verbose (and it'll be incorrect once i915.enable_guc_submission
> defaults to something else than zero).
> 
> > > + goto bail;
> > > + }
> > > +
> > >   /*
> > >    * We're not in host or fail to find a MPT module, disable GVT-g
> > >    */
> > > -- 
> > 
> > Applied, thanks!
> 
> The original patch should've included at least some Cc's, or wait being
> merged through drm-tip as it's not int drm/i915/gvt directory at all
> (unlike the message states).
> 
> The patch should be reverted for being incorrect.
> 

ok, as this is not sent for any gvt pull, will drop this in gvt tree.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use a define for the default priority [0]

[Chris Wilson]

On Fri, May 05, 2017 at 10:21:32AM +0100, Tvrtko Ursulin wrote:
> 
> On 05/05/2017 10:13, Chris Wilson wrote:
> >On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote:
> >>Chris Wilson  writes:
> >>
> >>>On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:
> >Explicitly assign the default priority, and give it a name (macro).
> >
> >Signed-off-by: Chris Wilson 
> 
> 
> 
> > kref_init(>ref);
> > list_add_tail(>link, _priv->context_list);
> > ctx->i915 = dev_priv;
> >+ctx->priority = I915_PRIORITY_DFL;
> 
> I915_PRIORITY_DEFAULT would work better.
> >>>
> >>>On the one hand I have the symmetry with MIN, DFL, MAX, on the other
> >>>hand DFL is plain bizarre.
> >>
> >>DEF?
> >
> >I915_PRIORITY_DEFEAT. I'm perfectly happy just to 0, pesky Tvrtko.
> 
> Will to argue deflated. :) I suggested it for benefit in one of the
> later patches which explicitly compared against zero. if < 0 &&
> !cap_sys_admin or something.. I thought being explicit what zero
> means there would be a good thing.
> 
> DEFAULT or DEF both sounds good to me. Or NORMAL. DFL is not
> entirely new (SIG_DFL) but it does look very weird.

I like I915_PRIORITY_NORMAL.
-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] drm/i915: Do not sync RCU during shrinking

[Chris Wilson]

On Fri, May 05, 2017 at 12:40:09PM +0300, Joonas Lahtinen wrote:
> Due to the complex dependencies between workqueues and RCU, which
> are not easily detected by lockdep, do not synchronize RCU during
> shrinking. RCU sync gains us very little benefit in real life
> scenarios where the amount of memory used by object backing
> storage is dominant over the metadata under RCU.
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: J. R. Okajima 
> Cc: Andrea Arcangeli 
Reviewed-by: Chris Wilson 
-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

[Intel-gfx] [PATCH] drm/i915: Do not sync RCU during shrinking

[Joonas Lahtinen]

Due to the complex dependencies between workqueues and RCU, which
are not easily detected by lockdep, do not synchronize RCU during
shrinking. RCU sync gains us very little benefit in real life
scenarios where the amount of memory used by object backing
storage is dominant over the metadata under RCU.

Suggested-by: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: J. R. Okajima 
Cc: Andrea Arcangeli 
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 0e7352d..e1868ed 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -59,9 +59,6 @@ static void shrinker_unlock(struct drm_i915_private 
*dev_priv, bool unlock)
return;
 
mutex_unlock(_priv->drm.struct_mutex);
-
-   /* expedite the RCU grace period to free some request slabs */
-   synchronize_rcu_expedited();
 }
 
 static bool any_vma_pinned(struct drm_i915_gem_object *obj)
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

[Andy Shevchenko]

On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
> On Fri, May 5, 2017 at 9:20 AM, Dan Williams  > wrote:
> > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
> >  wrote:


> > > for (i = 0; i < NFIT_UUID_MAX; i++)
> > > -   if (memcmp(to_nfit_uuid(i), spa->range_guid, 16)
> > > == 0)
> > > +   if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le
> > > *)spa->range_guid))
> > 
> > What is _cmp_pp? Why not _compare?

Dan, it's a typo. In this patch it should be just ..._cmp(), which is
already a part of API.

> > 
> 
> I second that.
> 
> Andy,

Amir, just to be clear. This patch can be applied without any addons to
an existing API. Above is just a typo due to rebase in my tree. I will
replace it to just uuid_le_cmp().

> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems
> code).

> The only reason I took a swing at hoisting the xfs uuid helpers is
> because it didn't
> seem like your proposal was going to be posted soon or wasn't going to
> satisfy
> the filesystems use case.

> 
> My opinion now, is that your suggestion is probably much closer to the
> real deal
> than mine.
> 
> IMO, you should acknowledge that the common use case for filesystems
> is
> to handle an opaque char[16] which most likely holds a uuid_be and you
> should provide 'neutral' helpers to satisfy this use case.
> 
> The simplest would be to typedef uuid_t to struct uuid_be and to name
> 'neutral'
> helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my
> proposal.

> I think with this semantic change, our proposals can reach common
> grounds
> and satisfy a wider group of users (i.e. filesystem developers).
> 
> Christoph also suggested a similar treatment to typedef guid_t to
> struct uuid_le.
> I don't know the use cases enough to comment on that.

We may go this way. But I wouldn't prevent current users of uuid_le to
continue using it without conversion (it may be done case by case after
we settle an API)

So, summarize what Christoph said it will look like

typedef uuid_be uuid_t;
typedef uuid_le guid_t

uuid_cmp() / uuid_copy() / uuid_to_bin() / etc
guid_cmp() / guid_copy() / guid_to_bin() / etc

Correct? Christoph?

-- 
Andy Shevchenko 
Intel Finland Oy
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use a define for the default priority [0]

[Tvrtko Ursulin]

On 05/05/2017 10:13, Chris Wilson wrote:

On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote:

Chris Wilson  writes:


On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:

On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:

Explicitly assign the default priority, and give it a name (macro).

Signed-off-by: Chris Wilson 





kref_init(>ref);
list_add_tail(>link, _priv->context_list);
ctx->i915 = dev_priv;
+   ctx->priority = I915_PRIORITY_DFL;


I915_PRIORITY_DEFAULT would work better.


On the one hand I have the symmetry with MIN, DFL, MAX, on the other
hand DFL is plain bizarre.


DEF?


I915_PRIORITY_DEFEAT. I'm perfectly happy just to 0, pesky Tvrtko.


Will to argue deflated. :) I suggested it for benefit in one of the 
later patches which explicitly compared against zero. if < 0 && 
!cap_sys_admin or something.. I thought being explicit what zero means 
there would be a good thing.


DEFAULT or DEF both sounds good to me. Or NORMAL. DFL is not entirely 
new (SIG_DFL) but it does look very weird.


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

[Joonas Lahtinen]

On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote:
> > 
> > > 
> > > + David and Jon
> > > 
> > > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
> > > 
> > > The blocking issue I see is that bisecting is still not pointing at
> > > relevant commits. Both bisected commits from Bugzilla are not related
> > > to changes in stolen memory usage behavior. I'd assume a successful
> > > bisect to land at the patches where we start creating kernel internal
> > > objects from stolen memory. Otherwise we could be ignoring a bug
> > > elsewhere. If it consistently lands on those patches, then there might
> > > be something wrong with them, in addition to stolen memory problems.
> > [Zhang, Xiong Y] I only try kernel 4.8 and 4.9 above, as the bugzilla 
> > descripted,
> > guest 4.8 kernel doesn't see gpu hang in guest dmesg, 4.9 kernel has gpu 
> > hang
> > in guest dmesg. From this point, we could do git bisect.
> > But tons of IOMMU DMA R/W exception to stolen memory exist in host dmesg
> > when guest kernel is 4.8 and 4.9. This means guest domain iommu table
> > doesn't
> > have mapping for stolen memory and IGD fail in accessing stolen memory
> > from guest kernel 4.8 and 4.9. From this point, this issue isn't a 
> > regression and
> > shouldn't go git bisect. You could check this host error message from the
> > bugzilla
> > attachment. And this should be fixed first.
> > Anyway, I will try my best to get the ideal commit through git bisect, but 
> > I'm
> > afraid
> > the result is the same as past because we don't have a stable good point to
> > start git
> > bisect.
> [Zhang, Xiong Y] hi, Joonas:
> As you said, the gpu hang exist because i915 create ring buffer from stolen 
> memory.
> I did git bisect again, and the following commit is the first bad commit:
> commit c58b735fc762e891481e92af7124b85cb0a51fce
> Author: Chris Wilson 
> Date:   Thu Aug 18 17:16:57 2016 +0100
> 
> drm/i915: Allocate rings from stolen
> 
> If we have stolen available, make use of it for ringbuffer allocation.
> Previously this was restricted to !llc platforms, as writing to stolen
> requires a GGTT mapping - but now that we have partial mappable support,
> the mappable aperture isn't quite so precious so we can use it more
> freely and ringbuffers are a good user for the otherwise wasted stolen.
> 
> After reverting this patch from drm-intel-nightly, I didn't see gpu hang 
> during guest boot process.
> So what's our next step ?

An appropriate next step would be to evaluate how much work it is to
support the RMRR passthrough David mentioned about in his commit.

I'd also go talk with the IGD team, why they refuse to load the driver
when stolen memory is correctly reported as zero, and insist on being
lied to.

While doing that, please update the freedesktop.org bugs.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

[Joonas Lahtinen]

On to, 2017-04-27 at 05:54 +, Zhang, Xiong Y wrote:
> > 
> > Also, was fixing the IGD driver loading with zero stolen memory
> > considered instead? All this information should exist in the commit
> > message.
> [Zhang, Xiong Y] IGD and i915 driver read pci config register 0x50 to get 
> the size of stolen memory. When guest read this register, qemu could trap
> it and return one value to guest.
> So in order to  " fixing the IGD driver loading with zero stolen memory ",
> We have to modify both Qemu and IGD driver:
> 1) QEMU: trap read from pci cfg 0x50 register, then return zero to guest
> 2) IGD driver: when IGD driver see zero size of stolen memory, don't exit 
> loading
> and continue.
> This doesn't give any benefit to i915, i915 will still disable stolen memory 
> as i915
> see zero size stolen memory . So I prefer to disable stolen memory in i915 
> directly 
> and keep Qemu and IGD driver unchanged. 

If due to lack of code in QEMU, RMRR is not available. It'd sound to me
they should carry the change to report stolen as zero, because they're
in best position to track if that changes in future.

Also, if the IGD driver requires a special treatment where stolen is
reported to exist but is not functional, that logic should be fixed
where the flaw is. i915 driver is not the go-to for fixing any quirks
and lack of code related to virtualization.

The driver performs perfectly logically, if stolen is reported to
exist, it is expected to work, if not, it's not touched. Adding special
cases to satisfy conditions outside of i915 will make driver
maintenance a burden.

And, if all other options fail and we end up having to fix the issue in
i915, the fix should be robust, which this currently is not (see my
previous messages).

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use a define for the default priority [0]

[Chris Wilson]

On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:
> >> On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:
> >> > Explicitly assign the default priority, and give it a name (macro).
> >> > 
> >> > Signed-off-by: Chris Wilson 
> >> 
> >> 
> >> 
> >> >  kref_init(>ref);
> >> >  list_add_tail(>link, _priv->context_list);
> >> >  ctx->i915 = dev_priv;
> >> > +ctx->priority = I915_PRIORITY_DFL;
> >> 
> >> I915_PRIORITY_DEFAULT would work better.
> >
> > On the one hand I have the symmetry with MIN, DFL, MAX, on the other
> > hand DFL is plain bizarre.
> 
> DEF?

I915_PRIORITY_DEFEAT. I'm perfectly happy just to 0, pesky Tvrtko.
-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] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Chris Wilson]

On Fri, May 05, 2017 at 11:55:14AM +0300, Joonas Lahtinen wrote:
> + Daniel
> 
> On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote:
> > On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote:
> > > 
> > > Currently GVT-g cannot work properly when host GuC submission
> > > is enabled, so disable GVT in this case.
> > > 
> > > Cc: Zhenyu Wang 
> > > Signed-off-by: Chuanxiao Dong 
> 
> 
> 
> > > @@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
> > >   goto bail;
> > >   }
> > >  
> > > + if (i915.enable_guc_submission) {
> > > + DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to 
> > > enabled GuC submission [i915.enable_guc_submission module parameter]\n");
> 
> Guest module parameter is not the correct way of detetecting if host
> has GuC submission enabled. And even if it was, the message is overly
> verbose (and it'll be incorrect once i915.enable_guc_submission
> defaults to something else than zero).

It needs to be verbose because it is a message to the user, it should
tell them what broke, what that will likely mean to them and if possible
how to rectify. Even then we know they won't read the entirety of the
message but at least it gives us a starting point for the inevitable
bugs. We should always aim for clarity and avoid too much jargon in
DRM_INFO+.

In this case, you could argue that i915.enable_guc_submission is an
unsafe parameter set to off by default and so the combination of gvt +
guc is pure user error and they can keep both pieces.

Ideally we wouldn't use i915.enable_guc_submission at all, but gvt
should be disabled upon enabling guc -- since the combination is currently
inoperable. But again, this is just a user error and we can just -EIO
the driver load...
-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