Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

[Daniel Vetter]

On Fri, Feb 23, 2018 at 09:25:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> While we want to potentially support multiple different gamma/degamma
> LUT sizes we can (and should) at least check that the blob length
> is a multiple of the LUT entry size.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8945357212ba..933edec0299d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_device *dev,
>struct drm_property_blob **blob,
>uint64_t blob_id,
>ssize_t expected_size,
> +  ssize_t expected_size_mod,

Needs kerneldoc, and I'm not sure it's the most descriptive name. Maybe
expected_array_element_size?

With or without the bikeshed, but with the kerneldoc fixed:

Reviewed-by: Daniel Vetter 

Up to this patch in the series.
-Daniel

>bool *replaced)
>  {
>   struct drm_property_blob *new_blob = NULL;
> @@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_device *dev,
>   if (new_blob == NULL)
>   return -EINVAL;
>  
> - if (expected_size > 0 && expected_size != new_blob->length) {
> + if (expected_size > 0 &&
> + new_blob->length != expected_size) {
> + drm_property_blob_put(new_blob);
> + return -EINVAL;
> + }
> + if (expected_size_mod > 0 &&
> + new_blob->length % expected_size_mod != 0) {
>   drm_property_blob_put(new_blob);
>   return -EINVAL;
>   }
> @@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   >degamma_lut,
>   val,
> - -1,
> + -1, sizeof(struct drm_color_lut),
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
> @@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   >ctm,
>   val,
> - sizeof(struct drm_color_ctm),
> + sizeof(struct drm_color_ctm), -1,
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
> @@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   >gamma_lut,
>   val,
> - -1,
> + -1, sizeof(struct drm_color_lut),
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 4/6] drm: Introduce drm_color_lut_size()

[Daniel Vetter]

On Fri, Feb 23, 2018 at 09:25:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Provide a small helper to convert the blob length in bytes
> to the number of LUT entries.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  include/drm/drm_color_mgmt.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 03a59cbce621..7ddf4457f3c1 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -37,4 +37,9 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>  int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>int gamma_size);
>  

Add a bit of kerneldoc and you get my

Reviewed-by: Daniel Vetter 

for this and all remaining patches.
-Daniel

> +static inline int drm_color_lut_size(const struct drm_property_blob *blob)
> +{
> + return blob->length / sizeof(struct drm_color_lut);
> +}
> +
>  #endif
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Daniel Vetter]

On Fri, Feb 23, 2018 at 11:26:41AM -0500, Harry Wentland wrote:
> On 2018-02-22 04:42 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > The documentation for the ctm matrix suggests a two's complement
> > format, but at least the i915 implementation is using sign-magnitude
> > instead. And looks like malidp is doing the same. Change the docs
> > to match the current implementation, and change the type from __s64
> > to __u64 to drive the point home.
> > 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Mihail Atanassov 
> > Cc: Liviu Dudau 
> > Cc: Brian Starkey 
> > Cc: Mali DP Maintainers 
> > Cc: Johnson Lin 
> > Cc: Uma Shankar 
> > Cc: Shashank Sharma 
> > Signed-off-by: Ville Syrjälä 
> 
> Good clarification. Our new CTM implementation (1) actually assumed
> two's complement but nobody's using it yet, so we'll patch it to
> convert.

Another reason to start looking into igt and the tests there? That would
have caught this too ...
-Daniel

> 
> Reviewed-by: Harry Wentland 
> 
> (1) https://patchwork.freedesktop.org/patch/204005/
> 
> Harry
> 
> > ---
> >  include/uapi/drm/drm_mode.h | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 2c575794fb52..b5d7d9e0eff5 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
> >  };
> >  
> >  struct drm_color_ctm {
> > -   /* Conversion matrix in S31.32 format. */
> > -   __s64 matrix[9];
> > +   /*
> > +* Conversion matrix in S31.32 sign-magnitude
> > +* (not two's complement!) format.
> > +*/
> > +   __u64 matrix[9];
> >  };
> >  
> >  struct drm_color_lut {
> > 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Allow horizontal mirroring for cnl+ "sprite" planes

[Joonas Lahtinen]

On Mon, 2018-03-05 at 18:51 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> All CNL universal planes support horizontal mirroring. Currently
> we expose the capability only for the primary plane. Expose it
> for the overlay planes as well.
> 
> Cc: Joonas Lahtinen 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Joonas Lahtinen 

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.IGT: failure for drm/i915/cnl: document WaVFUnitClockGatingDisable

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: document WaVFUnitClockGatingDisable
URL   : https://patchwork.freedesktop.org/series/39409/
State : failure

== Summary ==

 Possible new issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-a-256x256-left-edge:
pass   -> DMESG-WARN (shard-hsw)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-top-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +2
Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-atomic:
fail   -> PASS   (shard-hsw) fdo#104873
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060 +1
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3390 pass:1783 dwarn:1   dfail:0   fail:7   skip:1597 
time:11972s
shard-hswtotal:3468 pass:1773 dwarn:2   dfail:0   fail:1   skip:1691 
time:11878s
shard-snbtotal:3468 pass:1362 dwarn:3   dfail:0   fail:2   skip:2101 
time:7062s
Blacklisted hosts:
shard-kbltotal:3382 pass:1902 dwarn:3   dfail:0   fail:6   skip:1469 
time:8787s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8238/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/15] drm/i915/guc: Always print log stats in i915_guc_info when using GuC

[Sagar Arun Kamble]

On 2/27/2018 6:22 PM, Michał Winiarski wrote:

While some of the content in this file is related to GuC submission
only, that's not the case with log related statistics.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_debugfs.c | 15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4bd24bbe7966..866d44a091b3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2331,7 +2331,7 @@ static void i915_guc_log_info(struct seq_file *m,
  {
struct intel_guc *guc = _priv->guc;
  
-	seq_puts(m, "\nGuC logging stats:\n");

+   seq_puts(m, "GuC logging stats:\n");
  
  	seq_printf(m, "\tISR:   flush count %10u, overflow count %10u\n",

   guc->log.flush_count[GUC_ISR_LOG_BUFFER],
@@ -2379,14 +2379,19 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const struct intel_guc *guc = _priv->guc;
  
-	if (!USES_GUC_SUBMISSION(dev_priv))

+   if (!USES_GUC(dev_priv))
return -ENODEV;
  
+	i915_guc_log_info(m, dev_priv);

+
+   if (!USES_GUC_SUBMISSION(dev_priv))
+   return 0;
+
GEM_BUG_ON(!guc->execbuf_client);
  
-	seq_printf(m, "Doorbell map:\n");

+   seq_printf(m, "\nDoorbell map:\n");
seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap);
-   seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc->db_cacheline);
+   seq_printf(m, "Doorbell next cacheline: 0x%x\n", guc->db_cacheline);
  
  	seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);

i915_guc_client_info(m, dev_priv, guc->execbuf_client);
@@ -2396,8 +2401,6 @@ static int i915_guc_info(struct seq_file *m, void *data)
i915_guc_client_info(m, dev_priv, guc->preempt_client);
}
  
-	i915_guc_log_info(m, dev_priv);

-
/* Add more as required ... */
  
  	return 0;


--
Thanks,
Sagar

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/cnl: Add Wa_2201832410

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add Wa_2201832410
URL   : https://patchwork.freedesktop.org/series/39408/
State : warning

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-right-edge:
dmesg-warn -> PASS   (shard-hsw)
Test kms_rotation_crc:
Subgroup bad-pixel-format:
pass   -> DMESG-WARN (shard-apl)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-left-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +1
Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-atomic:
fail   -> PASS   (shard-hsw) fdo#104873
Test kms_flip:
Subgroup 2x-modeset-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060 +2
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3468 pass:1825 dwarn:2   dfail:0   fail:7   skip:1633 
time:12286s
shard-hswtotal:3468 pass:1773 dwarn:1   dfail:0   fail:2   skip:1691 
time:11890s
shard-snbtotal:3468 pass:1362 dwarn:3   dfail:0   fail:2   skip:2101 
time:7068s
Blacklisted hosts:
shard-kbltotal:3390 pass:1908 dwarn:1   dfail:0   fail:6   skip:1474 
time:9094s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8237/shards.html
___
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/guc: Move check for fast memcpy_wc to relay creation

[Sagar Arun Kamble]

On 2/27/2018 6:22 PM, Michał Winiarski wrote:

We only need those fast memcpy_wc when we're using relay to read
continuous GuC log. Let's prevent the user from creating a relay if we
know we won't be able to keep up with GuC.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/intel_guc_log.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 4dee65692f5f..d2aca10ab986 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -452,16 +452,6 @@ int intel_guc_log_create(struct intel_guc *guc)
  
  	GEM_BUG_ON(guc->log.vma);
  
-	/*

-* We require SSE 4.1 for fast reads from the GuC log buffer and
-* it should be present on the chipsets supporting GuC based
-* submisssions.
-*/
-   if (WARN_ON(!i915_has_memcpy_from_wc())) {
-   ret = -EINVAL;
-   goto err;
-   }
-
vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
@@ -568,6 +558,16 @@ int intel_guc_log_relay_open(struct intel_guc *guc)
goto out_unlock;
}
  
+	/*

+* We require SSE 4.1 for fast reads from the GuC log buffer and
+* it should be present on the chipsets supporting GuC based
+* submisssions.
+*/
+   if (!i915_has_memcpy_from_wc()) {
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
ret = guc_log_relay_create(guc);
if (ret)
goto out_unlock;


--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH 08/15] drm/i915/guc: Split relay control and GuC log level

[Sagar Arun Kamble]

On 2/27/2018 6:22 PM, Michał Winiarski wrote:

Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a way to create a
relay on demand, when it wants to read a continuous log rather than a
snapshot.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
  drivers/gpu/drm/i915/i915_debugfs.c  | 56 ++
  drivers/gpu/drm/i915/i915_drv.c  |  2 -
  drivers/gpu/drm/i915/intel_guc_log.c | 76 +++-
  drivers/gpu/drm/i915/intel_guc_log.h |  9 +++--
  drivers/gpu/drm/i915/intel_uc.c  | 22 ---
  drivers/gpu/drm/i915/intel_uc.h  |  2 -
  6 files changed, 86 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 58983cafaece..4bd24bbe7966 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2496,32 +2496,73 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
return 0;
  }
  
-static int i915_guc_log_control_get(void *data, u64 *val)

+static int i915_guc_log_level_get(void *data, u64 *val)
  {
struct drm_i915_private *dev_priv = data;

s/dev_priv/i915 here and at other places
  
  	if (!USES_GUC(dev_priv))

return -ENODEV;
  
-	*val = intel_guc_log_control_get(_priv->guc);

+   *val = intel_guc_log_level_get(_priv->guc);
  
  	return 0;

  }
  
-static int i915_guc_log_control_set(void *data, u64 val)

+static int i915_guc_log_level_set(void *data, u64 val)
  {
struct drm_i915_private *dev_priv = data;
  
  	if (!USES_GUC(dev_priv))

return -ENODEV;
  
-	return intel_guc_log_control_set(_priv->guc, val);

+   return intel_guc_log_level_set(_priv->guc, val);
  }
  
-DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,

-   i915_guc_log_control_get, i915_guc_log_control_set,
+DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_level_fops,
+   i915_guc_log_level_get, i915_guc_log_level_set,
"%lld\n");
  
+static int i915_guc_log_relay_open(struct inode *inode, struct file *file)

+{
+   struct drm_i915_private *dev_priv = inode->i_private;
+
+   if (!USES_GUC(dev_priv))
+   return -ENODEV;
+
+   file->private_data = dev_priv;
+
write is passing guc struct so should we just set private_data to 
_priv->guc?

+   return intel_guc_log_relay_open(_priv->guc);
+}
+
+static ssize_t
+i915_guc_log_relay_write(struct file *filp,
+const char __user *ubuf,
+size_t cnt,
+loff_t *ppos)
+{
+   struct drm_i915_private *dev_priv = filp->private_data;
+
+   intel_guc_log_relay_flush(_priv->guc);
+
+   return cnt;
+}



+void intel_guc_log_relay_close(struct intel_guc *guc)
+{
GEM_BUG_ON(!guc_log_has_runtime(guc));
  

guc_log_has_runtime() check has to be with runtime.lock mutex locked.

With comments addressed:
Reviewed-by: Sagar Arun Kamble 

+   guc_log_flush_irq_disable(guc);
+   flush_work(>log.runtime.flush_work);
+
+   mutex_lock(>log.runtime.lock);
guc_log_unmap(guc);
guc_log_relay_destroy(guc);
-
mutex_unlock(>log.runtime.lock);
  }
diff --git a/drivers/gpu/drm/i915/intel_guc_log.h 
b/drivers/gpu/drm/i915/intel_guc_log.h
index 8c26cce77a98..df91f12a36ed 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/intel_guc_log.h
@@ -61,9 +61,10 @@ struct intel_guc_log {
  int intel_guc_log_create(struct intel_guc *guc);
  void intel_guc_log_destroy(struct intel_guc *guc);
  void intel_guc_log_init_early(struct intel_guc *guc);
-int intel_guc_log_control_get(struct intel_guc *guc);
-int intel_guc_log_control_set(struct intel_guc *guc, u64 control_val);
-int intel_guc_log_register(struct intel_guc *guc);
-void intel_guc_log_unregister(struct intel_guc *guc);
+int intel_guc_log_level_get(struct intel_guc *guc);
+int intel_guc_log_level_set(struct intel_guc *guc, u64 control_val);
+int intel_guc_log_relay_open(struct intel_guc *guc);
+void intel_guc_log_relay_close(struct intel_guc *guc);
+void intel_guc_log_relay_flush(struct intel_guc *guc);
  
  #endif

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 55a9b5b673e0..27e1f4c43b7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc *guc)
i915_gem_object_put(guc->load_err_log);
  }
  

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm/i915/error: remove unused gen8_engine_sync_index

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915/error: remove unused 
gen8_engine_sync_index
URL   : https://patchwork.freedesktop.org/series/39403/
State : failure

== Summary ==

 Possible new issues:

Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +6
Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup flip-vs-expired-vblank:
fail   -> PASS   (shard-snb) fdo#102887
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-mmap-cpu:
fail   -> PASS   (shard-apl) fdo#101623
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3453 pass:1818 dwarn:1   dfail:0   fail:7   skip:1626 
time:11878s
shard-hswtotal:3468 pass:1773 dwarn:1   dfail:0   fail:2   skip:1691 
time:11869s
shard-snbtotal:3453 pass:1354 dwarn:3   dfail:0   fail:2   skip:2093 
time:6853s
Blacklisted hosts:
shard-kbltotal:3274 pass:1852 dwarn:2   dfail:0   fail:5   skip:1411 
time:8213s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8236/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm: Make sure at least one plane supports the fb format (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm: Make sure at least one plane 
supports the fb format (rev3)
URL   : https://patchwork.freedesktop.org/series/39383/
State : failure

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-a-256x256-bottom-edge:
pass   -> DMESG-WARN (shard-hsw)
Subgroup pipe-a-256x256-top-edge:
pass   -> DMESG-WARN (shard-hsw)
Subgroup pipe-a-64x64-right-edge:
pass   -> INCOMPLETE (shard-hsw)
Subgroup pipe-c-128x128-left-edge:
dmesg-warn -> PASS   (shard-hsw)
Subgroup pipe-c-256x256-right-edge:
dmesg-warn -> PASS   (shard-hsw)
Subgroup pipe-c-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-apl)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup flip-vs-expired-vblank:
fail   -> PASS   (shard-snb) fdo#102887
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-mmap-cpu:
fail   -> PASS   (shard-apl) fdo#101623
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3468 pass:1826 dwarn:1   dfail:0   fail:7   skip:1633 
time:12377s
shard-hswtotal:3463 pass:1765 dwarn:3   dfail:0   fail:3   skip:1690 
time:11611s
shard-snbtotal:3468 pass:1363 dwarn:2   dfail:0   fail:2   skip:2101 
time:7060s
Blacklisted hosts:
shard-kbltotal:3382 pass:1902 dwarn:3   dfail:0   fail:6   skip:1469 
time:8784s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8235/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] drm-misc-next

[Daniel Vetter]

On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul  wrote:
> On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter  wrote:
>> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote:
>>> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul  wrote:
>>> >
>>> > Hi Dave,
>>> > Here's this weeks pull, relatively small when you pull out the trivial 
>>> > fixes.
>>> >
>>> > drm-misc-next-2018-02-28:
>>> > drm-misc-next for 4.17:
>>> >
>>> > UAPI Changes:
>>> >  Fix drm_color_ctm matrix docs to match usage and change the type to
>>> >  __u64 make it obvious (Ville)
>>>
>>> Hi Dave,
>>> Could you please hold off on pulling this? I'd like to sort out this
>>> change a bit more. We're already using the __s64 in chrome, and not
>>> explicitly sign-magnitude. I think it would be prudent to hash this
>>> out a little more.
>>>
>>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?l=161
>>
>> That code seems to be doing the exact same fun s.u63 math. This all looks
>> consistent to me.
>
> Hmm, yeah, I skimmed too quickly last week.
>
>>
>> Now in hindsight ofc we've screwed up the uapi, but well can't fix that
>> now again ...
>
> Yeah, I'm not convinced we should be changing the type. It's great to
> clarify the documentation to let userspace know it's sign-magnitude,
> but changing the type in-flight with users seems wrong.

But everyone must do unsigned bit ops to get this right, the s64 is
completely meaningless at best, and very likely will confuse someone.
What do we benefit by not changing it? We know all the users and have
the source, so we know that we won't hit another undefined corner of
C, which is about the only real issue I can even imagine. UAPI isn't
cast in stone, we simply have to make sure nothing breaks when we
clarify/update/remove/whatever it.
-Daniel

>
> Sean
>
>> -Daniel
>>
>>>
>>> Sean
>>>
>>> >
>>> > Core Changes:
>>> >  Check modifier with format when checking if a plane state is supported 
>>> > (Ville)
>>> >
>>> > Driver Changes:
>>> >  sun4i: Improve hw plane utilization (Maxime)
>>> >  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>>> >  virtio: Whitespace + checkpatch changes (Rodrigo)
>>> >
>>> > Cc: Maxime Ripard 
>>> > Cc: Oleksandr Andrushchenko 
>>> > Cc: Ville Syrjälä 
>>> > Cc: Rodrigo Siqueira 
>>> >
>>> > Cheers, Sean
>>> >
>>> >
>>> > The following changes since commit 
>>> > 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:
>>> >
>>> >   drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)
>>> >
>>> > are available in the Git repository at:
>>> >
>>> >   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-28
>>> >
>>> > for you to fetch changes up to 7628166d5e2883e4cdd142b99863d29d411a81b2:
>>> >
>>> >   tinydrm: add backlight dependency (2018-02-28 15:08:56 -0500)
>>> >
>>> > 
>>> > drm-misc-next for 4.17:
>>> >
>>> > UAPI Changes:
>>> >  Fix drm_color_ctm matrix docs to match usage and change the type to
>>> >  __u64 make it obvious (Ville)
>>> >
>>> > Core Changes:
>>> >  Check modifier with format when checking if a plane state is supported 
>>> > (Ville)
>>> >
>>> > Driver Changes:
>>> >  sun4i: Improve hw plane utilization (Maxime)
>>> >  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>>> >  virtio: Whitespace + checkpatch changes (Rodrigo)
>>> >
>>> > Cc: Maxime Ripard 
>>> > Cc: Oleksandr Andrushchenko 
>>> > Cc: Ville Syrjälä 
>>> > Cc: Rodrigo Siqueira 
>>> >
>>> > 
>>> > Arnd Bergmann (2):
>>> >   drm: fix drm_get_max_iomem type mismatch
>>> >   tinydrm: add backlight dependency
>>> >
>>> > Benjamin Gaignard (1):
>>> >   drm/stm: check pitch and size calculations even if !CONFIG_MMU
>>> >
>>> > Chris Wilson (1):
>>> >   drm/mm: Fix caching of leftmost node in the interval tree
>>> >
>>> > Linus Walleij (1):
>>> >   drm/panel: Fix ARM Versatile panel clocks
>>> >
>>> > Maxime Ripard (4):
>>> >   drm/sun4i: backend: Assign the pipes automatically
>>> >   drm/sun4i: Remove the plane description structure
>>> >   drm/sun4i: backend: Make zpos configurable
>>> >   drm/sun4i: backend: Remove ARGB spoofing
>>> >
>>> > Oleksandr Andrushchenko (5):
>>> >   drm/simple_kms_helper: Fix NULL pointer dereference with no active 
>>> > CRTC
>>> >   drm/simple_kms_helper: Add {enable|disable}_vblank callback support
>>> >   drm/mxsfb: Do not use deprecated drm_driver.{enable|disable)_vblank
>>> >   drm/tve200: Do not use deprecated drm_driver.{enable|disable)_vblank
>>> >   drm/pl111: Do not use deprecated 

Re: [Intel-gfx] [PATCH 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

[Sagar Arun Kamble]

On 3/5/2018 7:44 PM, Michał Winiarski wrote:

On Mon, Mar 05, 2018 at 04:01:18PM +0530, Sagar Arun Kamble wrote:


On 2/27/2018 6:22 PM, Michał Winiarski wrote:

Currently, we're treating relay and mapping of GuC log as a separate
concepts. We're also using inconsistent locking, sometimes using
relay_lock, sometimes using struct mutex.
Let's correct that. Anything touching the runtime is now serialized
using runtime.lock, while we're still using struct mutex as inner lock
for mapping.
We're still racy in setting the log level - but we'll take care of that
in the following patches.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
   drivers/gpu/drm/i915/intel_guc_log.c | 110 
++-
   drivers/gpu/drm/i915/intel_guc_log.h |   3 +-
   drivers/gpu/drm/i915/intel_uc.c  |  14 +++--
   3 files changed, 42 insertions(+), 85 deletions(-)


[SNIP]



How strongly do you feel about this one?
I wanted to tidy first (decouple things), rename later.

fine. it's ok.

INIT_WORK(>log.runtime.flush_work, capture_logs_work);
   }
@@ -448,12 +418,7 @@ int guc_log_relay_create(struct intel_guc *guc)
size_t n_subbufs, subbuf_size;
int ret;
-   if (!i915_modparams.guc_log_level)
-   return 0;
-
-   mutex_lock(>log.runtime.relay_lock);
-
-   GEM_BUG_ON(guc_log_has_relay(guc));
+   lockdep_assert_held(>log.runtime.lock);
 /* Keep the size of sub buffers same as shared log buffer */
subbuf_size = GUC_LOG_SIZE;
@@ -483,12 +448,9 @@ int guc_log_relay_create(struct intel_guc *guc)
GEM_BUG_ON(guc_log_relay_chan->subbuf_size < subbuf_size);
guc->log.runtime.relay_chan = guc_log_relay_chan;
-   mutex_unlock(>log.runtime.relay_lock);
-
return 0;
   err:
-   mutex_unlock(>log.runtime.relay_lock);
/* logging will be off */
i915_modparams.guc_log_level = 0;

This log_level decoupling is not taken care

Yup, though it belongs in "drm/i915/guc: Split relay control and GuC log level",
I'll add it there.


return ret;
@@ -496,20 +458,10 @@ int guc_log_relay_create(struct intel_guc *guc)
   void guc_log_relay_destroy(struct intel_guc *guc)
   {
-   mutex_lock(>log.runtime.relay_lock);
-
-   /*
-* It's possible that the relay was never allocated because
-* GuC log was disabled at the boot time.
-*/
-   if (!guc_log_has_relay(guc))
-   goto out_unlock;
+   lockdep_assert_held(>log.runtime.lock);
relay_close(guc->log.runtime.relay_chan);
guc->log.runtime.relay_chan = NULL;
-
-out_unlock:
-   mutex_unlock(>log.runtime.relay_lock);
   }
   static void guc_log_capture_logs(struct intel_guc *guc)
@@ -608,7 +560,6 @@ static void guc_log_flush_irq_disable(struct intel_guc *guc)
   void intel_guc_log_destroy(struct intel_guc *guc)
   {
-   guc_log_runtime_destroy(guc);
i915_vma_unpin_and_release(>log.vma);
   }
@@ -678,9 +629,10 @@ int intel_guc_log_control_set(struct intel_guc *guc, u64 
val)
   int intel_guc_log_register(struct intel_guc *guc)
   {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
int ret;
+   mutex_lock(>log.runtime.lock);
+
GEM_BUG_ON(guc_log_has_runtime(guc));
/*
@@ -692,35 +644,33 @@ int intel_guc_log_register(struct intel_guc *guc)
if (ret)
goto err;
-   mutex_lock(_priv->drm.struct_mutex);
-   ret = guc_log_runtime_create(guc);
-   mutex_unlock(_priv->drm.struct_mutex);
-
+   ret = guc_log_map(guc);
if (ret)
goto err_relay;
ret = guc_log_relay_file_create(guc);
if (ret)
-   goto err_runtime;
+   goto err_unmap;
guc_log_flush_irq_enable(guc);
+   mutex_unlock(>log.runtime.lock);
+
return 0;
-err_runtime:
-   mutex_lock(_priv->drm.struct_mutex);
-   guc_log_runtime_destroy(guc);
-   mutex_unlock(_priv->drm.struct_mutex);
+err_unmap:
+   guc_log_unmap(guc);
   err_relay:
guc_log_relay_destroy(guc);
   err:
+   mutex_unlock(>log.runtime.lock);
+
return ret;
   }
   void intel_guc_log_unregister(struct intel_guc *guc)
   {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
+   guc_log_flush_irq_disable(guc);

This move could be part of earlier patch.

/*
 * Once logging is disabled, GuC won't generate logs & send an
 * interrupt. But there could be some data in the log buffer
@@ -728,11 +678,13 @@ void intel_guc_log_unregister(struct intel_guc *guc)
 * buffer state and then collect the left over logs.
 */
guc_flush_logs(guc);
-   guc_log_flush_irq_disable(guc);
-   mutex_lock(_priv->drm.struct_mutex);
-   

Re: [Intel-gfx] [PATCH 02/15] drm/i915/guc: Create common entry points for log register/unregister

[Sagar Arun Kamble]

On 3/5/2018 7:08 PM, Michał Winiarski wrote:

On Mon, Mar 05, 2018 at 12:39:58PM +0530, Sagar Arun Kamble wrote:

Overall change looks good. Could you please clarify on below:

intel_uc_log_register|unregister are removed in patch later in the series.
Should we just stay with inner functions then to minimize changes?

I've done this to move (USES_GUC/guc_log_level) checks to the callers. Otherwise
it would need to stay in intel_guc_log_register, which would cause us to do more
changes in intel_guc_log_control_set later in the series (when we're actually
doing the decoupling).
But AFAIU change in that patch (8/15) will be decoupling 
guc_log_register from USES_GUC/guc_log_level which would be fine I guess.

Your call :)

-Michał



Thanks
Sagar

On 2/27/2018 6:22 PM, Michał Winiarski wrote:

We have many functions responsible for allocating different parts of
runtime called from multiple places. Let's stick with keeping
everything in guc_log_register instead.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
---
   drivers/gpu/drm/i915/i915_drv.c  |   6 +-
   drivers/gpu/drm/i915/i915_gem.c  |   4 +-
   drivers/gpu/drm/i915/intel_guc_log.c | 148 
++-
   drivers/gpu/drm/i915/intel_guc_log.h |   6 +-
   drivers/gpu/drm/i915/intel_uc.c  |  39 -
   drivers/gpu/drm/i915/intel_uc.h  |   6 +-
   6 files changed, 91 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b51024..719b2be73292 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -636,7 +636,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_contexts_fini(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
-   intel_uc_fini_misc(dev_priv);
+   intel_uc_fini_wq(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
i915_gem_drain_freed_objects(dev_priv);
@@ -1237,7 +1237,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
-   i915_guc_log_register(dev_priv);
+   intel_uc_log_register(dev_priv);
i915_setup_sysfs(dev_priv);
/* Depends on sysfs having been initialized */
@@ -1297,7 +1297,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
i915_pmu_unregister(dev_priv);
i915_teardown_sysfs(dev_priv);
-   i915_guc_log_unregister(dev_priv);
+   intel_uc_log_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
i915_gem_shrinker_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 14c855b1a3a4..4bf5f25b29e2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5279,7 +5279,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
if (ret)
return ret;
-   ret = intel_uc_init_misc(dev_priv);
+   ret = intel_uc_init_wq(dev_priv);
if (ret)
return ret;
@@ -5375,7 +5375,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(_priv->drm.struct_mutex);
-   intel_uc_fini_misc(dev_priv);
+   intel_uc_fini_wq(dev_priv);
if (ret != -EIO)
i915_gem_cleanup_userptr(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 22a05320817b..f1cab43d334e 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -441,7 +441,7 @@ void intel_guc_log_init_early(struct intel_guc *guc)
INIT_WORK(>log.runtime.flush_work, capture_logs_work);
   }
-int intel_guc_log_relay_create(struct intel_guc *guc)
+int guc_log_relay_create(struct intel_guc *guc)
   {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
@@ -494,7 +494,7 @@ int intel_guc_log_relay_create(struct intel_guc *guc)
return ret;
   }
-void intel_guc_log_relay_destroy(struct intel_guc *guc)
+void guc_log_relay_destroy(struct intel_guc *guc)
   {
mutex_lock(>log.runtime.relay_lock);
@@ -512,49 +512,6 @@ void intel_guc_log_relay_destroy(struct intel_guc *guc)
mutex_unlock(>log.runtime.relay_lock);
   }
-static int guc_log_late_setup(struct intel_guc *guc)
-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   int ret;
-
-   if (!guc_log_has_runtime(guc)) {
-   /*
-* If log was disabled at boot time, then setup needed to handle
-* log buffer 

Re: [Intel-gfx] [PATCH 07/15] drm/i915/guc: Flush directly in log unregister

[Sagar Arun Kamble]

On 3/5/2018 5:40 PM, Michał Winiarski wrote:

On Mon, Mar 05, 2018 at 05:28:33PM +0530, Sagar Arun Kamble wrote:


On 2/27/2018 6:22 PM, Michał Winiarski wrote:

Having both guc_flush_logs and guc_log_flush functions is confusing.
While we could just rename things, guc_flush_logs implementation is
quite simple. Let's get rid of it and move its content to unregister.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 

Reviewed-by: Sagar Arun Kamble 

this patch reminds me of need to do guc_log_flush in capture_uc_state prior
to reset in case user wants to read
updated log vma from error state. is this need valid?

I don't think so - force flush Host to GuC is related to "bookkeeping" (think
metadata describing log buffer state - HEAD/TAIL pointers etc).
In error state we don't care - we're dumping the whole log vma.
But while decoding from log vma in error state we will need up to date 
read/write pointers.

Or is the error handling logic requires not to invoke any H2G post hang.

Agree that this change has to be taken up later based on consensus on 
requirement but just wanted

understand the scenario more.

Thanks,
Sagar

In case of relay - we're moving data around, and we need to know what data to
move.

-Michał


---
   drivers/gpu/drm/i915/intel_guc_log.c | 35 +++
   1 file changed, 15 insertions(+), 20 deletions(-)



--
Thanks,
Sagar

___
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: Remove GUC_CTL_DEVICE_INFO parameter

[Sagar Arun Kamble]

On 3/5/2018 6:43 PM, Piotr Piórkowski wrote:

It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter
where we are passing GT type and Core family values.
Lets stop setup this parameter and remove related definitions.
Minor change to sentence above: Let's stop/remove setup of this 
parameter ...


v2: (this time without squashed HAX)
   - New title and description
   - Remove also GUC_CORE_FAMILY_* definitions (Michel)

Signed-off-by: Piotr Piórkowski 
Cc: Sagar Arun Kamble 
Cc: Michał Winiarski 
Cc: John A Spotswood 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Michel Thierry 
With Michel's suggestion and then corresponding subject update patch 
looks good to me.

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/intel_guc.c  | 24 
  drivers/gpu/drm/i915/intel_guc_fwif.h |  7 ---
  2 files changed, 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index ff08ea0ebf49..efc413137a89 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -200,26 +200,6 @@ void intel_guc_fini(struct intel_guc *guc)
guc_shared_data_destroy(guc);
  }
  
-static u32 get_gt_type(struct drm_i915_private *dev_priv)

-{
-   /* XXX: GT type based on PCI device ID? field seems unused by fw */
-   return 0;
-}
-
-static u32 get_core_family(struct drm_i915_private *dev_priv)
-{
-   u32 gen = INTEL_GEN(dev_priv);
-
-   switch (gen) {
-   case 9:
-   return GUC_CORE_FAMILY_GEN9;
-
-   default:
-   MISSING_CASE(gen);
-   return GUC_CORE_FAMILY_UNKNOWN;
-   }
-}
-
  static u32 get_log_verbosity_flags(void)
  {
if (i915_modparams.guc_log_level > 0) {
@@ -246,10 +226,6 @@ void intel_guc_init_params(struct intel_guc *guc)
  
  	memset(params, 0, sizeof(params));
  
-	params[GUC_CTL_DEVICE_INFO] |=

-   (get_gt_type(dev_priv) << GUC_CTL_GT_TYPE_SHIFT) |
-   (get_core_family(dev_priv) << GUC_CTL_CORE_FAMILY_SHIFT);
-
/*
 * GuC ARAT increment is 10 ns. GuC default scheduler quantum is one
 * second. This ARAR is calculated by:
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 6a10aa6f04d3..5131e67e663f 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -23,9 +23,6 @@
  #ifndef _INTEL_GUC_FWIF_H
  #define _INTEL_GUC_FWIF_H
  
-#define GUC_CORE_FAMILY_GEN9		12

-#define GUC_CORE_FAMILY_UNKNOWN0x7fff
-
  #define GUC_CLIENT_PRIORITY_KMD_HIGH  0
  #define GUC_CLIENT_PRIORITY_HIGH  1
  #define GUC_CLIENT_PRIORITY_KMD_NORMAL2
@@ -81,10 +78,6 @@
  #define GUC_CTL_ARAT_HIGH 1
  #define GUC_CTL_ARAT_LOW  2
  
-#define GUC_CTL_DEVICE_INFO		3

-#define   GUC_CTL_GT_TYPE_SHIFT0
-#define   GUC_CTL_CORE_FAMILY_SHIFT7
-
  #define GUC_CTL_LOG_PARAMS4
  #define   GUC_LOG_VALID   (1 << 0)
  #define   GUC_LOG_NOTIFY_ON_HALF_FULL (1 << 1)


--
Thanks,
Sagar

___
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: add schedule out notification of preempted but completed request (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: add schedule out notification of preempted but completed 
request (rev2)
URL   : https://patchwork.freedesktop.org/series/38903/
State : success

== Summary ==

Series 38903v2 drm/i915: add schedule out notification of preempted but 
completed request
https://patchwork.freedesktop.org/api/1.0/series/38903/revisions/2/mbox/

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-hsw-4770)

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:431s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:501s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:408s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:520s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:389s

0277dd47369ad982da80d2d07babb469f2e1b881 drm-tip: 2018y-03m-06d-01h-44m-46s UTC 
integration manifest
10b67f1db0c3 drm/i915: add schedule out notification of preempted but completed 
request

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8240/issues.html
___
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/cnp: Document WaSouthDisplayDisablePWMCGEGating

[Patchwork]

== Series Details ==

Series: drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating
URL   : https://patchwork.freedesktop.org/series/39410/
State : success

== Summary ==

Series 39410v1 drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating
https://patchwork.freedesktop.org/api/1.0/series/39410/revisions/1/mbox/

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-hsw-4770)

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:519s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:520s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:536s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:428s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s

0277dd47369ad982da80d2d07babb469f2e1b881 drm-tip: 2018y-03m-06d-01h-44m-46s UTC 
integration manifest
6d693b0695a2 drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8239/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: add schedule out notification of preempted but completed request

[Weinan Li]

There is one corner case missing schedule out notification of the preempted
request. The preempted request is just completed when preemption happen,
then it will be canceled and won't be resubmitted later, GVT-g will lost
the schedule out notification.

Here add schedule out notification if found the preempted request has been
completed.

v2:
- refine description, add completed check and notification in
  execlists_cancel_port_requests. (Chris)

v3:
- use ternary confitional, remove local variable. (Tvrtko)

Cc: Chris Wilson 
Signed-off-by: Weinan Li 
Signed-off-by: Zhenyu Wang 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36b376e..b35026b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -672,7 +672,12 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 
GEM_BUG_ON(!execlists->active);
intel_engine_context_out(rq->engine);
-   execlists_context_status_change(rq, 
INTEL_CONTEXT_SCHEDULE_PREEMPTED);
+
+   execlists_context_status_change(rq,
+   i915_request_completed(rq) ?
+   INTEL_CONTEXT_SCHEDULE_OUT :
+   
INTEL_CONTEXT_SCHEDULE_PREEMPTED);
+
i915_request_put(rq);
 
memset(port, 0, sizeof(*port));
-- 
1.9.1

___
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/cnl: document WaVFUnitClockGatingDisable

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: document WaVFUnitClockGatingDisable
URL   : https://patchwork.freedesktop.org/series/39409/
State : success

== Summary ==

Series 39409v1 drm/i915/cnl: document WaVFUnitClockGatingDisable
https://patchwork.freedesktop.org/api/1.0/series/39409/revisions/1/mbox/

 Known issues:

Test kms_chamelium:
Subgroup dp-edid-read:
fail   -> PASS   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:425s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:410s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:520s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s

e0164934bc08a991c3c2d2e3671a9e3e46b8448e drm-tip: 2018y-03m-05d-23h-48m-01s UTC 
integration manifest
df3b84015a8e drm/i915/cnl: document WaVFUnitClockGatingDisable

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8238/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: document WaVFUnitClockGatingDisable

[Rafael Antognolli]

On Mon, Mar 05, 2018 at 05:20:00PM -0800, Rodrigo Vivi wrote:
> No functional change. WA is already properly applied.
> but in different databases it has different names.
> Let's document all of them to avoid future confusion.

Works for me.

Reviewed-by: Rafael Antognolli 

> Cc: Rafael Antognolli 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index be01012bb65f..c0253e42a280 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8528,6 +8528,7 @@ static void cnl_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>   I915_WRITE(SUBSLICE_UNIT_LEVEL_CLKGATE, val);
>  
>   /* WaDisableVFclkgate:cnl */
> + /* WaVFUnitClockGatingDisable:cnl */
>   val = I915_READ(UNSLICE_UNIT_LEVEL_CLKGATE);
>   val |= VFUNIT_CLKGATE_DIS;
>   I915_WRITE(UNSLICE_UNIT_LEVEL_CLKGATE, val);
> -- 
> 2.13.6
> 
___
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/cnl: Add Wa_2201832410

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add Wa_2201832410
URL   : https://patchwork.freedesktop.org/series/39408/
State : success

== Summary ==

Series 39408v1 drm/i915/cnl: Add Wa_2201832410
https://patchwork.freedesktop.org/api/1.0/series/39408/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup dp-edid-read:
fail   -> PASS   (fi-kbl-7500u) fdo#102505

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:495s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:470s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:423s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:465s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:437s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:498s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:513s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s

e0164934bc08a991c3c2d2e3671a9e3e46b8448e drm-tip: 2018y-03m-05d-23h-48m-01s UTC 
integration manifest
7393f94a4776 drm/i915/cnl: Add Wa_2201832410

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8237/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating

[Rodrigo Vivi]

No functional change since WA is already applied.
But since it has different names on different databases,
let's document it here to avoid future confusion.

Cc: Radhakrishna Sripada 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c0253e42a280..b8da4dcdd584 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8492,7 +8492,7 @@ static void cnp_init_clock_gating(struct drm_i915_private 
*dev_priv)
if (!HAS_PCH_CNP(dev_priv))
return;
 
-   /* Display WA #1181: cnp */
+   /* Display WA #1181 WaSouthDisplayDisablePWMCGEGating: cnp */
I915_WRITE(SOUTH_DSPCLK_GATE_D, I915_READ(SOUTH_DSPCLK_GATE_D) |
   CNP_PWM_CGE_GATING_DISABLE);
 }
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/error: standardize function style in error capture

[Michel Thierry]

On 3/5/2018 2:21 PM, Daniele Ceraolo Spurio wrote:

some of the static functions used from capture() have the "i915_"
prefix while other don't; most of them take i915 as a parameter, but one
of them derives it internally from error->i915. Let's be consistent by
avoiding prefix for static functions and by getting i915 from
error->i915.


Following the fist part of this logic, i915_error_object_free could 
probably be just error_object_free, but this would never end...


Changes look OK to me, feel free to add my r-b if you need it.


While at it, s/dev_priv/i915 in functions that don't
perform register reads.

v2: take i915 from error->i915 (Michal), s/dev_priv/i915,
 update commit message

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 


Reviewed-by: Michel Thierry 


---
  drivers/gpu/drm/i915/i915_gpu_error.c | 84 ---
  1 file changed, 39 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ef29fb48d6d9..9afb1b9674c0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1084,9 +1084,9 @@ static uint32_t i915_error_generate_code(struct 
drm_i915_private *dev_priv,
return error_code;
  }
  
-static void i915_gem_record_fences(struct drm_i915_private *dev_priv,

-  struct i915_gpu_state *error)
+static void gem_record_fences(struct i915_gpu_state *error)
  {
+   struct drm_i915_private *dev_priv = error->i915;
int i;
  
  	if (INTEL_GEN(dev_priv) >= 6) {

@@ -1424,14 +1424,14 @@ capture_object(struct drm_i915_private *dev_priv,
}
  }
  
-static void i915_gem_record_rings(struct drm_i915_private *dev_priv,

- struct i915_gpu_state *error)
+static void gem_record_rings(struct i915_gpu_state *error)
  {
-   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct drm_i915_private *i915 = error->i915;
+   struct i915_ggtt *ggtt = >ggtt;
int i;
  
  	for (i = 0; i < I915_NUM_ENGINES; i++) {

-   struct intel_engine_cs *engine = dev_priv->engine[i];
+   struct intel_engine_cs *engine = i915->engine[i];
struct drm_i915_error_engine *ee = >engine[i];
struct i915_request *request;
  
@@ -1460,17 +1460,16 @@ static void i915_gem_record_rings(struct drm_i915_private *dev_priv,

 * by userspace.
 */
ee->batchbuffer =
-   i915_error_object_create(dev_priv,
-request->batch);
+   i915_error_object_create(i915, request->batch);
  
-			if (HAS_BROKEN_CS_TLB(dev_priv))

+   if (HAS_BROKEN_CS_TLB(i915))
ee->wa_batchbuffer =
-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 
engine->scratch);
request_record_user_bo(request, ee);
  
  			ee->ctx =

-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 
request->ctx->engine[i].state);
  
  			error->simulated |=

@@ -1484,27 +1483,24 @@ static void i915_gem_record_rings(struct 
drm_i915_private *dev_priv,
ee->cpu_ring_head = ring->head;
ee->cpu_ring_tail = ring->tail;
ee->ringbuffer =
-   i915_error_object_create(dev_priv, ring->vma);
+   i915_error_object_create(i915, ring->vma);
  
  			engine_record_requests(engine, request, ee);

}
  
  		ee->hws_page =

-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 engine->status_page.vma);
  
-		ee->wa_ctx =

-   i915_error_object_create(dev_priv, engine->wa_ctx.vma);
+   ee->wa_ctx = i915_error_object_create(i915, engine->wa_ctx.vma);
  
-		ee->default_state =

-   capture_object(dev_priv, engine->default_state);
+   ee->default_state = capture_object(i915, engine->default_state);
}
  }
  
-static void i915_gem_capture_vm(struct drm_i915_private *dev_priv,

-   struct i915_gpu_state *error,
-   struct i915_address_space *vm,
-   int idx)
+static void gem_capture_vm(struct i915_gpu_state *error,
+  struct 

[Intel-gfx] [PATCH] drm/i915/cnl: document WaVFUnitClockGatingDisable

[Rodrigo Vivi]

No functional change. WA is already properly applied.
but in different databases it has different names.
Let's document all of them to avoid future confusion.

Cc: Rafael Antognolli 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index be01012bb65f..c0253e42a280 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8528,6 +8528,7 @@ static void cnl_init_clock_gating(struct drm_i915_private 
*dev_priv)
I915_WRITE(SUBSLICE_UNIT_LEVEL_CLKGATE, val);
 
/* WaDisableVFclkgate:cnl */
+   /* WaVFUnitClockGatingDisable:cnl */
val = I915_READ(UNSLICE_UNIT_LEVEL_CLKGATE);
val |= VFUNIT_CLKGATE_DIS;
I915_WRITE(UNSLICE_UNIT_LEVEL_CLKGATE, val);
-- 
2.13.6

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

[Intel-gfx] [PATCH] drm/i915/cnl: Add Wa_2201832410

[Rodrigo Vivi]

"Clock gating bug in GWL may not clear barrier state when an EOT
is received, causing a hang the next time that barrier is used."

HSDES: 2201832410

Cc: Rafael Antognolli 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_pm.c | 5 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a060726fed7e..42baf90edb6f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3953,6 +3953,9 @@ enum {
 #define  SARBUNIT_CLKGATE_DIS  (1 << 5)
 #define  RCCUNIT_CLKGATE_DIS   (1 << 7)
 
+#define SUBSLICE_UNIT_LEVEL_CLKGATE_MMIO(0x9524)
+#define  GWUNIT_CLKGATE_DIS(1 << 16)
+
 #define UNSLICE_UNIT_LEVEL_CLKGATE _MMIO(0x9434)
 #define  VFUNIT_CLKGATE_DIS(1 << 20)
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3e60279f18b1..be01012bb65f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8522,6 +8522,11 @@ static void cnl_init_clock_gating(struct 
drm_i915_private *dev_priv)
val |= SARBUNIT_CLKGATE_DIS;
I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
 
+   /* Wa_2201832410:cnl */
+   val = I915_READ(SUBSLICE_UNIT_LEVEL_CLKGATE);
+   val |= GWUNIT_CLKGATE_DIS;
+   I915_WRITE(SUBSLICE_UNIT_LEVEL_CLKGATE, val);
+
/* WaDisableVFclkgate:cnl */
val = I915_READ(UNSLICE_UNIT_LEVEL_CLKGATE);
val |= VFUNIT_CLKGATE_DIS;
-- 
2.13.6

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

[Intel-gfx] linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Stephen Rothwell]

Hi Liviu,

Today's linux-next merge of the mali-dp tree got a conflict in:

  drivers/gpu/drm/arm/malidp_planes.c

between commit:

  81af63a4af82 ("drm: Don't pass clip to drm_atomic_helper_check_plane_state()")

from the drm-misc tree and commit:

  4968211e7b8f ("drm: mali-dp: Uninitialized variable in 
malidp_se_check_scaling()")

from the mali-dp tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/arm/malidp_planes.c
index ee32361c87ac,b2d11df6b5e1..
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@@ -147,7 -147,13 +146,9 @@@ static int malidp_se_check_scaling(stru
if (!crtc_state)
return -EINVAL;
  
 -  if (crtc_state->enable)
 -  drm_mode_get_hv_timing(_state->mode,
 - , );
 -
+   mc = to_malidp_crtc_state(crtc_state);
+ 
 -  ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
 +  ret = drm_atomic_helper_check_plane_state(state, crtc_state,
  0, INT_MAX, true, true);
if (ret)
return ret;


pgpH3ThJbdc86.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+

[Patchwork]

== Series Details ==

Series: drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+
URL   : https://patchwork.freedesktop.org/series/39393/
State : warning

== Summary ==

 Possible new issues:

Test kms_concurrent:
Subgroup pipe-b:
pass   -> SKIP   (shard-snb)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-modeset:
skip   -> PASS   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-top-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +1
Subgroup pipe-c-128x128-bottom-edge:
pass   -> FAIL   (shard-apl) fdo#104671
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
skip   -> PASS   (shard-snb) fdo#102670
Test kms_flip:
Subgroup dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#103167

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:3412 pass:1798 dwarn:1   dfail:0   fail:9   skip:1602 
time:11999s
shard-hswtotal:3468 pass:1774 dwarn:1   dfail:0   fail:1   skip:1691 
time:11739s
shard-snbtotal:3468 pass:1363 dwarn:2   dfail:0   fail:1   skip:2102 
time:7083s
Blacklisted hosts:
shard-kbltotal:3270 pass:1842 dwarn:1   dfail:0   fail:7   skip:1416 
time:8206s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8234/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

[Manasi Navare]

On Wed, Feb 28, 2018 at 03:10:24PM -0500, Lyude Paul wrote:
> On Wed, 2018-02-28 at 11:57 -0800, Manasi Navare wrote:
> > On Wed, Feb 28, 2018 at 02:41:06PM -0500, Lyude Paul wrote:
> > > On Wed, 2018-02-28 at 11:27 -0800, Manasi Navare wrote:
> > > > On Wed, Feb 28, 2018 at 02:07:34PM -0500, Lyude Paul wrote:
> > > > > 
> > > > > On Tue, 2018-02-27 at 23:17 -0800, Manasi Navare wrote:
> > > > > > Ville,  thanks for the patch and
> > > > > > Sorry for not being able to review this earlier.
> > > > > > Please find some comments below:
> > > > > > 
> > > > > > On Wed, Jan 31, 2018 at 03:27:10PM +0200, Ville Syrjälä wrote:
> > > > > > > On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> > > > > > > > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote:
> > > > > > > > > From: Ville Syrjälä 
> > > > > > > > > 
> > > > > > > > > Doing link retraining from the short pulse handler is
> > > > > > > > > problematic
> > > > > > > > > since
> > > > > > > > > that might introduce deadlocks with MST sideband processing.
> > > > > > > > > Currently
> > > > > > > > > we don't retrain MST links from this code, but we want to
> > > > > > > > > change
> > > > > > > > > that.
> > > > > > > > > So better to move the entire thing to the hotplug work. We can
> > > > > > > > > utilize
> > > > > > > > > the new encoder->hotplug() hook for this.
> > > > > > > > > 
> > > > > > > > > The only thing we leave in the short pulse handler is the link
> > > > > > > > > status
> > > > > > > > > check. That one still depends on the link parameters stored
> > > > > > > > > under
> > > > > > > > > intel_dp, so no locking around that but races should be mostly
> > > > > > > > > harmless
> > > > > > > > > as the actual retraining code will recheck the link state if
> > > > > > > > > we
> > > > > > > > > end up there by mistake.
> > > > > > > > > 
> > > > > > > > > v2: Rebase due to ->post_hotplug() now being just ->hotplug()
> > > > > > > > > Check the connector type to figure out if we should do
> > > > > > > > > the HDMI thing or the DP think for DDI
> > > > > > > > > 
> > > > > > > > > Cc: Manasi Navare 
> > > > > > > > > Cc: Maarten Lankhorst 
> > > > > > > > > Signed-off-by: Ville Syrjälä 
> > > > > > > > > ---
> > > > > > > > >  drivers/gpu/drm/i915/intel_ddi.c |  10 +-
> > > > > > > > >  drivers/gpu/drm/i915/intel_dp.c  | 196
> > > > > > > > > ++--
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> > > > > > > > >  3 files changed, 120 insertions(+), 88 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > > index 25793bdc692f..5f3d58f1ae6e 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct
> > > > > > > > > intel_encoder
> > > > > > > > > *encoder,
> > > > > > > > >   drm_modeset_acquire_init(, 0);
> > > > > > > > >  
> > > > > > > > >   for (;;) {
> > > > > > > > > - ret = intel_hdmi_reset_link(encoder, );
> > > > > > > > > + if (connector->base.connector_type ==
> > > > > > > > > DRM_MODE_CONNECTOR_HDMIA)
> > > > > > > > > + ret = intel_hdmi_reset_link(encoder,
> > > > > > > > > );
> > > > > > > > > + else
> > > > > > > > > + ret = intel_dp_retrain_link(encoder,
> > > > > > > > > );
> > > > > > > > >  
> > > > > > > > >   if (ret == -EDEADLK) {
> > > > > > > > >   drm_modeset_backoff();
> > > > > > > > > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct
> > > > > > > > > drm_i915_private
> > > > > > > > > *dev_priv,
> > > > > > > > > enum port port)
> > > > > > > > >   drm_encoder_init(_priv->drm, encoder,
> > > > > > > > > _ddi_funcs,
> > > > > > > > >DRM_MODE_ENCODER_TMDS, "DDI %c",
> > > > > > > > > port_name(port));
> > > > > > > > >  
> > > > > > > > > - if (init_hdmi)
> > > > > > > > > - intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > > > > > - else
> > > > > > > > > - intel_encoder->hotplug =
> > > > > > > > > intel_encoder_hotplug;
> > > > > > > > > + intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > > > > >   intel_encoder->compute_output_type =
> > > > > > > > > intel_ddi_compute_output_type;
> > > > > > > > >   intel_encoder->compute_config =
> > > > > > > > > intel_ddi_compute_config;
> > > > > > > > >   intel_encoder->enable = intel_enable_ddi;
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > > > index 6bbf14410c2a..152016e09a11 100644
> > > > > 

Re: [Intel-gfx] [PULL] drm-misc-next

[Sean Paul]

On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter  wrote:
> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote:
>> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul  wrote:
>> >
>> > Hi Dave,
>> > Here's this weeks pull, relatively small when you pull out the trivial 
>> > fixes.
>> >
>> > drm-misc-next-2018-02-28:
>> > drm-misc-next for 4.17:
>> >
>> > UAPI Changes:
>> >  Fix drm_color_ctm matrix docs to match usage and change the type to
>> >  __u64 make it obvious (Ville)
>>
>> Hi Dave,
>> Could you please hold off on pulling this? I'd like to sort out this
>> change a bit more. We're already using the __s64 in chrome, and not
>> explicitly sign-magnitude. I think it would be prudent to hash this
>> out a little more.
>>
>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?l=161
>
> That code seems to be doing the exact same fun s.u63 math. This all looks
> consistent to me.

Hmm, yeah, I skimmed too quickly last week.

>
> Now in hindsight ofc we've screwed up the uapi, but well can't fix that
> now again ...

Yeah, I'm not convinced we should be changing the type. It's great to
clarify the documentation to let userspace know it's sign-magnitude,
but changing the type in-flight with users seems wrong.

Sean

> -Daniel
>
>>
>> Sean
>>
>> >
>> > Core Changes:
>> >  Check modifier with format when checking if a plane state is supported 
>> > (Ville)
>> >
>> > Driver Changes:
>> >  sun4i: Improve hw plane utilization (Maxime)
>> >  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>> >  virtio: Whitespace + checkpatch changes (Rodrigo)
>> >
>> > Cc: Maxime Ripard 
>> > Cc: Oleksandr Andrushchenko 
>> > Cc: Ville Syrjälä 
>> > Cc: Rodrigo Siqueira 
>> >
>> > Cheers, Sean
>> >
>> >
>> > The following changes since commit 
>> > 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:
>> >
>> >   drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)
>> >
>> > are available in the Git repository at:
>> >
>> >   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-28
>> >
>> > for you to fetch changes up to 7628166d5e2883e4cdd142b99863d29d411a81b2:
>> >
>> >   tinydrm: add backlight dependency (2018-02-28 15:08:56 -0500)
>> >
>> > 
>> > drm-misc-next for 4.17:
>> >
>> > UAPI Changes:
>> >  Fix drm_color_ctm matrix docs to match usage and change the type to
>> >  __u64 make it obvious (Ville)
>> >
>> > Core Changes:
>> >  Check modifier with format when checking if a plane state is supported 
>> > (Ville)
>> >
>> > Driver Changes:
>> >  sun4i: Improve hw plane utilization (Maxime)
>> >  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>> >  virtio: Whitespace + checkpatch changes (Rodrigo)
>> >
>> > Cc: Maxime Ripard 
>> > Cc: Oleksandr Andrushchenko 
>> > Cc: Ville Syrjälä 
>> > Cc: Rodrigo Siqueira 
>> >
>> > 
>> > Arnd Bergmann (2):
>> >   drm: fix drm_get_max_iomem type mismatch
>> >   tinydrm: add backlight dependency
>> >
>> > Benjamin Gaignard (1):
>> >   drm/stm: check pitch and size calculations even if !CONFIG_MMU
>> >
>> > Chris Wilson (1):
>> >   drm/mm: Fix caching of leftmost node in the interval tree
>> >
>> > Linus Walleij (1):
>> >   drm/panel: Fix ARM Versatile panel clocks
>> >
>> > Maxime Ripard (4):
>> >   drm/sun4i: backend: Assign the pipes automatically
>> >   drm/sun4i: Remove the plane description structure
>> >   drm/sun4i: backend: Make zpos configurable
>> >   drm/sun4i: backend: Remove ARGB spoofing
>> >
>> > Oleksandr Andrushchenko (5):
>> >   drm/simple_kms_helper: Fix NULL pointer dereference with no active 
>> > CRTC
>> >   drm/simple_kms_helper: Add {enable|disable}_vblank callback support
>> >   drm/mxsfb: Do not use deprecated drm_driver.{enable|disable)_vblank
>> >   drm/tve200: Do not use deprecated drm_driver.{enable|disable)_vblank
>> >   drm/pl111: Do not use deprecated drm_driver.{enable|disable)_vblank
>> >
>> > Rodrigo Siqueira (7):
>> >   drm/virtio: Add tabs at the start of a line
>> >   drm/virtio: Add blank line after variable declarations
>> >   drm/virtio: Add */ in block comments to separate line
>> >   drm/virtio: Remove return from void function
>> >   drm/virtio: Replace 'unsigned' for 'unsigned int'
>> >   drm/virtio: Remove multiple blank lines
>> >   drm/virtio: Add spaces around operators
>> >
>> > Thierry Reding (1):
>> >   drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC
>> >
>> > Ville Syrjälä (4):
>> >   drm: Check that the plane supports the request format+modifier combo
>> 

Re: [Intel-gfx] Question about latest skl_dmc_ver1_27.bin and kernel version.

[Rodrigo Vivi]

Hi Paul,

The use of symbolic links was deprecated exactly to avoid this kind of situation
you faced when blindly replacing dmc 1.26 per 1.27. We never tested that kernel
version with that DMC so we don't know what to expect.

As the regular end users concerns they should never touch any firmware and rely
on the distribution to update linux-firmware packages.

You, as the linux distribution OSV, should package linux-firmware from 
linux-firmware.git
and don't hack it.

If you are sure that you need the new version you should then backport the 
patch:
https://patchwork.freedesktop.org/series/33568/ on your kernel, instead of 
renaming
files or using symbolic link.

Thanks,
Rodrigo.

On Mon, Mar 05, 2018 at 04:31:59PM -0500, Paul Knopf wrote:
> I am trying to setup Intel's new open-source iHD driver on a Yocto 
> environment.
> 
> https://software.intel.com/en-us/articles/build-and-debug-open-source-media-stack
> 
> The documentation says that skl_dmc_ver1_27.bin is required. Their 
> documentation updates
> a symlink (skl_dmc_ver1.bin), as if the kernel loads it, but starting at 
> kernel 4.8, it
> stopped loading the symlink and instead loads a specific version of the dmc 
> (see here:
> https://github.com/torvalds/linux/blob/v4.8/drivers/gpu/drm/i915/intel_csr.c#L48).
>  Is the
> Intel documentation accurate? It is confusing because the guide refers to 
> 4.14.16
> specifically, which doesn't use the symlink file skl_dmc_ver1.bin.
> 
> Any ways, I tried replacing skl_dmc_ver1_26.bin with skl_dmc_ver1_27.bin to 
> have the same
> effect, but I got a segfault on boot.
> 
> https://pastebin.com/amW9vDdC
> 
> Should I even bother updating the DMC? Should the iHD driver work on most 
> kernels, even
> with 1_26 version of DMC?
> 
> By the way, this is the kernel I am using (with Yocto).
> 
> https://github.com/intel/linux-intel-lts/tree/4.14/yocto/base/drivers/gpu/drm/i915
> 
> Any help would be greatly appreciated. There is no documentation on this 
> stuff.

> ___
> 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 1/3] drm: Make sure at least one plane supports the fb format

[Eric Anholt]

Ville Syrjälä  writes:

> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
>> Ville Syrjala  writes:
>> 
>> > From: Ville Syrjälä 
>> >
>> > To make life easier for drivers, let's have the core check that the
>> > requested pixel format is supported by at least one plane when creating
>> > a new framebuffer.
>> >
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/drm_framebuffer.c | 26 ++
>> >  1 file changed, 26 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> > b/drivers/gpu/drm/drm_framebuffer.c
>> > index c0530a1af5e3..155b21e579c4 100644
>> > --- a/drivers/gpu/drm/drm_framebuffer.c
>> > +++ b/drivers/gpu/drm/drm_framebuffer.c
>> > @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
>> >return DIV_ROUND_UP(height, format->vsub);
>> >  }
>> >  
>> > +static bool planes_have_format(struct drm_device *dev, u32 format)
>> > +{
>> > +  struct drm_plane *plane;
>> > +
>> > +  /* TODO: maybe maintain a device level format list? */
>> > +  drm_for_each_plane(plane, dev) {
>> > +  int i;
>> > +
>> > +  for (i = 0; i < plane->format_count; i++) {
>> > +  if (plane->format_types[i] == format)
>> > +  return true;
>> > +  }
>> > +  }
>> > +
>> > +  return false;
>> > +}
>> > +
>> >  static int framebuffer_check(struct drm_device *dev,
>> > const struct drm_mode_fb_cmd2 *r)
>> >  {
>> > @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
>> >return -EINVAL;
>> >}
>> >  
>> > +  if (!planes_have_format(dev, r->pixel_format)) {
>> > +  struct drm_format_name_buf format_name;
>> > +
>> > +  DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
>> > +drm_get_format_name(r->pixel_format,
>> > +_name));
>> > +  return -EINVAL;
>> > +  }
>> > +
>> 
>> Won't this break KMS on things like the radeon driver, which doesn't do
>> planes?  Maybe check if any universal planes have been registered and
>> only do the check in that case?
>
> Hmm. I thought we add the implicit planes always. Apparently
> drm_crtc_init() adds a primary with X/ARGB, but no more. So
> this would break all other formats, which is probably a bit too
> aggressive.
>
> I guess I could just skip the check in case any plane has
> plane->format_default set. That should be indicating that the driver
> doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
> Harry?
>
>> 
>> Also, "any_planes_have_format()" might be slightly more descriptive.
>
> Or any_plane_has_format()? Is that more englishy? :)

I like it.


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 1/3] drm: Make sure at least one plane supports the fb format

[Harry Wentland]

On 2018-03-05 04:33 PM, Alex Deucher wrote:
> On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä
>  wrote:
>> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
>>> Ville Syrjala  writes:
>>>
 From: Ville Syrjälä 

 To make life easier for drivers, let's have the core check that the
 requested pixel format is supported by at least one plane when creating
 a new framebuffer.

 Signed-off-by: Ville Syrjälä 
 ---
  drivers/gpu/drm/drm_framebuffer.c | 26 ++
  1 file changed, 26 insertions(+)

 diff --git a/drivers/gpu/drm/drm_framebuffer.c 
 b/drivers/gpu/drm/drm_framebuffer.c
 index c0530a1af5e3..155b21e579c4 100644
 --- a/drivers/gpu/drm/drm_framebuffer.c
 +++ b/drivers/gpu/drm/drm_framebuffer.c
 @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
 return DIV_ROUND_UP(height, format->vsub);
  }

 +static bool planes_have_format(struct drm_device *dev, u32 format)
 +{
 +   struct drm_plane *plane;
 +
 +   /* TODO: maybe maintain a device level format list? */
 +   drm_for_each_plane(plane, dev) {
 +   int i;
 +
 +   for (i = 0; i < plane->format_count; i++) {
 +   if (plane->format_types[i] == format)
 +   return true;
 +   }
 +   }
 +
 +   return false;
 +}
 +
  static int framebuffer_check(struct drm_device *dev,
  const struct drm_mode_fb_cmd2 *r)
  {
 @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
 return -EINVAL;
 }

 +   if (!planes_have_format(dev, r->pixel_format)) {
 +   struct drm_format_name_buf format_name;
 +
 +   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
 + drm_get_format_name(r->pixel_format,
 + _name));
 +   return -EINVAL;
 +   }
 +
>>>
>>> Won't this break KMS on things like the radeon driver, which doesn't do
>>> planes?  Maybe check if any universal planes have been registered and
>>> only do the check in that case?
>>
>> Hmm. I thought we add the implicit planes always. Apparently
>> drm_crtc_init() adds a primary with X/ARGB, but no more. So
>> this would break all other formats, which is probably a bit too
>> aggressive.
>>
>> I guess I could just skip the check in case any plane has
>> plane->format_default set. That should be indicating that the driver
>> doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
>> Harry?
> 
> Probably leftover from DC bringup?

I'm not sure if I'm following. Which flag are we talking about?

Is the concern the DC driver or amdgpu with DC (or radeon)?

DC does not call drm_crtc_init(). It initializes universal planes in 
amdgpu_dm_initialize_drm_device() -> amdgpu_dm_plane_init().

From a quick glance this patch looks fine by me.

Harry

> 
> Alex
> 
>>
>>>
>>> Also, "any_planes_have_format()" might be slightly more descriptive.
>>
>> Or any_plane_has_format()? Is that more englishy? :)
>>
>> --
>> Ville Syrjälä
>> Intel OTC
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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 [v2,1/3] drm/i915/error: remove unused gen8_engine_sync_index

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915/error: remove unused 
gen8_engine_sync_index
URL   : https://patchwork.freedesktop.org/series/39403/
State : success

== Summary ==

Series 39403v1 series starting with [v2,1/3] drm/i915/error: remove unused 
gen8_engine_sync_index
https://patchwork.freedesktop.org/api/1.0/series/39403/revisions/1/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:497s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:477s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:465s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:408s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:467s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:472s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:437s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:520s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:500s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:424s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:521s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s

82e049a0d7e6bcaae89a1e0774c8dc0d60b081a1 drm-tip: 2018y-03m-05d-18h-55m-22s UTC 
integration manifest
b7bf31cffa00 drm/i915/error: capture uc_state after gen_state
72d9c6214db9 drm/i915/error: standardize function style in error capture
1b3f3ad9c402 drm/i915/error: remove unused gen8_engine_sync_index

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8236/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/3] drm/i915/error: remove unused gen8_engine_sync_index

[Daniele Ceraolo Spurio]

Leftover from Gen8 ringbuffer support removal

Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a7933c9b5562..ef29fb48d6d9 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1102,27 +1102,6 @@ static void i915_gem_record_fences(struct 
drm_i915_private *dev_priv,
error->nfence = i;
 }
 
-static inline u32
-gen8_engine_sync_index(struct intel_engine_cs *engine,
-  struct intel_engine_cs *other)
-{
-   int idx;
-
-   /*
-* rcs -> 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
-* vcs -> 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
-* bcs -> 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
-* vecs -> 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
-* vcs2 -> 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
-*/
-
-   idx = (other - engine) - 1;
-   if (idx < 0)
-   idx += I915_NUM_ENGINES;
-
-   return idx;
-}
-
 static void gen6_record_semaphore_state(struct intel_engine_cs *engine,
struct drm_i915_error_engine *ee)
 {
-- 
2.16.2

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

[Intel-gfx] [PATCH v2 2/3] drm/i915/error: standardize function style in error capture

[Daniele Ceraolo Spurio]

some of the static functions used from capture() have the "i915_"
prefix while other don't; most of them take i915 as a parameter, but one
of them derives it internally from error->i915. Let's be consistent by
avoiding prefix for static functions and by getting i915 from
error->i915. While at it, s/dev_priv/i915 in functions that don't
perform register reads.

v2: take i915 from error->i915 (Michal), s/dev_priv/i915,
update commit message

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 84 ---
 1 file changed, 39 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ef29fb48d6d9..9afb1b9674c0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1084,9 +1084,9 @@ static uint32_t i915_error_generate_code(struct 
drm_i915_private *dev_priv,
return error_code;
 }
 
-static void i915_gem_record_fences(struct drm_i915_private *dev_priv,
-  struct i915_gpu_state *error)
+static void gem_record_fences(struct i915_gpu_state *error)
 {
+   struct drm_i915_private *dev_priv = error->i915;
int i;
 
if (INTEL_GEN(dev_priv) >= 6) {
@@ -1424,14 +1424,14 @@ capture_object(struct drm_i915_private *dev_priv,
}
 }
 
-static void i915_gem_record_rings(struct drm_i915_private *dev_priv,
- struct i915_gpu_state *error)
+static void gem_record_rings(struct i915_gpu_state *error)
 {
-   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct drm_i915_private *i915 = error->i915;
+   struct i915_ggtt *ggtt = >ggtt;
int i;
 
for (i = 0; i < I915_NUM_ENGINES; i++) {
-   struct intel_engine_cs *engine = dev_priv->engine[i];
+   struct intel_engine_cs *engine = i915->engine[i];
struct drm_i915_error_engine *ee = >engine[i];
struct i915_request *request;
 
@@ -1460,17 +1460,16 @@ static void i915_gem_record_rings(struct 
drm_i915_private *dev_priv,
 * by userspace.
 */
ee->batchbuffer =
-   i915_error_object_create(dev_priv,
-request->batch);
+   i915_error_object_create(i915, request->batch);
 
-   if (HAS_BROKEN_CS_TLB(dev_priv))
+   if (HAS_BROKEN_CS_TLB(i915))
ee->wa_batchbuffer =
-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 
engine->scratch);
request_record_user_bo(request, ee);
 
ee->ctx =
-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 
request->ctx->engine[i].state);
 
error->simulated |=
@@ -1484,27 +1483,24 @@ static void i915_gem_record_rings(struct 
drm_i915_private *dev_priv,
ee->cpu_ring_head = ring->head;
ee->cpu_ring_tail = ring->tail;
ee->ringbuffer =
-   i915_error_object_create(dev_priv, ring->vma);
+   i915_error_object_create(i915, ring->vma);
 
engine_record_requests(engine, request, ee);
}
 
ee->hws_page =
-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 engine->status_page.vma);
 
-   ee->wa_ctx =
-   i915_error_object_create(dev_priv, engine->wa_ctx.vma);
+   ee->wa_ctx = i915_error_object_create(i915, engine->wa_ctx.vma);
 
-   ee->default_state =
-   capture_object(dev_priv, engine->default_state);
+   ee->default_state = capture_object(i915, engine->default_state);
}
 }
 
-static void i915_gem_capture_vm(struct drm_i915_private *dev_priv,
-   struct i915_gpu_state *error,
-   struct i915_address_space *vm,
-   int idx)
+static void gem_capture_vm(struct i915_gpu_state *error,
+  struct i915_address_space *vm,
+  int idx)
 {
struct drm_i915_error_buffer *active_bo;
struct i915_vma *vma;
@@ -1527,8 +1523,7 @@ static void i915_gem_capture_vm(struct drm_i915_private 

[Intel-gfx] [PATCH v2 3/3] drm/i915/error: capture uc_state after gen_state

[Daniele Ceraolo Spurio]

error->device_info.has_guc, which we check in capture_uc_state, is set
in capture_gen_state, so the latter needs to be performed first.

v2: rebased

Reported-by: Vinay Belgaumkar 
Fixes: 7d41ef3479a6 (drm/i915: Add Guc/HuC firmware details to error state)
Cc: Vinay Belgaumkar 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson  #v1
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9afb1b9674c0..9e5e9547adb2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1743,8 +1743,8 @@ static int capture(void *data)
  error->i915->gt.last_init_time);
 
capture_params(error);
-   capture_uc_state(error);
capture_gen_state(error);
+   capture_uc_state(error);
capture_reg_state(error);
gem_record_fences(error);
gem_record_rings(error);
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/error: capture uc_state after gen_state

[Daniele Ceraolo Spurio]

On 03/03/18 01:55, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2018-03-02 19:19:30)

error->device_info.has_guc, which we check in capture_uc_state, is set
in capture_gen_state, so the latter needs to be performed first.

Reported-by: Vinay Belgaumkar 
Cc: Vinay Belgaumkar 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 


Care to add a fixes in case you want this backported?



I had purposely omitted the tag as I thought that since GuC is disabled 
by default we wouldn't backport patches related to it, but I guess I had 
the wrong idea :)

I'll add the tag in v2

Thanks,
Daniele


Reviewed-by: Chris Wilson 
-Chris


___
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 [v2,1/3] drm: Make sure at least one plane supports the fb format (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm: Make sure at least one plane 
supports the fb format (rev3)
URL   : https://patchwork.freedesktop.org/series/39383/
State : success

== Summary ==

Series 39383v3 series starting with [v2,1/3] drm: Make sure at least one plane 
supports the fb format
https://patchwork.freedesktop.org/api/1.0/series/39383/revisions/3/mbox/

 Known issues:

Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:369s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:507s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:468s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:394s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:436s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:518s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:420s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:519s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s

82e049a0d7e6bcaae89a1e0774c8dc0d60b081a1 drm-tip: 2018y-03m-05d-18h-55m-22s UTC 
integration manifest
ea0839bcb7f2 drm: Fix some coding style issues
b2f4a47f3ed9 drm/i915: Eliminate the horrendous format check code
11545007e0a6 drm: Make sure at least one plane supports the fb format

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8235/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for Test the plane formats on the Chamelium

[Patchwork]

== Series Details ==

Series: Test the plane formats on the Chamelium
URL   : https://patchwork.freedesktop.org/series/39380/
State : warning

== Summary ==

 Possible new issues:

Test gem_exec_blt:
Subgroup cold-max:
pass   -> DMESG-WARN (shard-hsw)
Test kms_flip:
Subgroup flip-vs-modeset-interruptible:
pass   -> DMESG-WARN (shard-hsw)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-modeset:
skip   -> PASS   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-right-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
skip   -> PASS   (shard-snb) fdo#102670
Test kms_flip:
Subgroup dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
pass   -> DMESG-FAIL (shard-hsw) fdo#103167

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:3424 pass:1802 dwarn:1   dfail:0   fail:7   skip:1612 
time:11586s
shard-hswtotal:3469 pass:1771 dwarn:3   dfail:1   fail:1   skip:1692 
time:11814s
shard-snbtotal:3469 pass:1365 dwarn:1   dfail:0   fail:1   skip:2102 
time:7171s
Blacklisted hosts:
shard-kbltotal:3424 pass:1928 dwarn:1   dfail:0   fail:7   skip:1487 
time:8867s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1061/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v12 1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Yaodong Li]

On 03/02/2018 12:04 AM, Sagar Arun Kamble wrote:


Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 

I think maintainers will prefer as:
either

Cc:
Cc:
S-o-b:
R-b:

or

S-o-b:
Cc:
Cc:
R-b:
Thanks Sagar! I will include these changes along with other 
comments/suggestion

from Joonas (if any:-))

Regards,
-Jackie

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

[Intel-gfx] [PATCH v2 2/3] drm/i915: Eliminate the horrendous format check code

[Ville Syrjala]

From: Ville Syrjälä 

Now that the core makes sure that the pixel format is supported
by at least one plane, we can eliminate the hand rolled code for the
same thing in i915. The way we were doing was extremely inconvenient
because not only did you have to add the format to the plane's format
list, but you also had to come up with the correct platform checks
for this code.

v2: Nuke the modifier checks as well since the core does that too now

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 86 
 1 file changed, 86 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb08590b4d40..3ed1ef05cb55 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13991,7 +13991,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = _fb->base;
-   struct drm_format_name_buf format_name;
u32 pitch_limit;
unsigned int tiling, stride;
int ret = -EINVAL;
@@ -14022,37 +14021,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
}
}
 
-   /* Passed in modifier sanity checking. */
-   switch (mode_cmd->modifier[0]) {
-   case I915_FORMAT_MOD_Y_TILED_CCS:
-   case I915_FORMAT_MOD_Yf_TILED_CCS:
-   switch (mode_cmd->pixel_format) {
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_ABGR:
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
-   break;
-   default:
-   DRM_DEBUG_KMS("RC supported only with RGB 
formats\n");
-   goto err;
-   }
-   /* fall through */
-   case I915_FORMAT_MOD_Y_TILED:
-   case I915_FORMAT_MOD_Yf_TILED:
-   if (INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
- mode_cmd->modifier[0]);
-   goto err;
-   }
-   case DRM_FORMAT_MOD_LINEAR:
-   case I915_FORMAT_MOD_X_TILED:
-   break;
-   default:
-   DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
- mode_cmd->modifier[0]);
-   goto err;
-   }
-
/*
 * gen2/3 display engine uses the fence if present,
 * so the tiling mode must match the fb modifier exactly.
@@ -14083,60 +14051,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
 
-   /* Reject formats not supported by any plane early. */
-   switch (mode_cmd->pixel_format) {
-   case DRM_FORMAT_C8:
-   case DRM_FORMAT_RGB565:
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
-   break;
-   case DRM_FORMAT_XRGB1555:
-   if (INTEL_GEN(dev_priv) > 3) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
-   INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_XRGB2101010:
-   case DRM_FORMAT_XBGR2101010:
-   if (INTEL_GEN(dev_priv) < 4) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR2101010:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_YUYV:
-   case DRM_FORMAT_UYVY:
-   case DRM_FORMAT_YVYU:
-   case DRM_FORMAT_VYUY:
-   if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   default:
-

[Intel-gfx] [PATCH v2 1/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjala]

From: Ville Syrjälä 

To make life easier for drivers, let's have the core check that the
requested pixel format is supported by at least one plane when creating
a new framebuffer.

v2: Accept anyformat if the driver doesn't do planes (Eric)
s/planes_have_format/any_plane_has_format/ (Eric)
Check the modifier as well since we already have a function
that does both

Cc: Eric Anholt 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 43 +++
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index c0530a1af5e3..b9a33e3f13e9 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -152,12 +152,37 @@ static int fb_plane_height(int height,
return DIV_ROUND_UP(height, format->vsub);
 }
 
+static bool any_plane_has_format(struct drm_device *dev,
+u32 format, u64 modifier)
+{
+   struct drm_plane *plane;
+
+   /* TODO: maybe maintain a device level format list? */
+   drm_for_each_plane(plane, dev) {
+   /*
+* In case the driver doesn't really do
+* planes we have to accept any format here.
+*/
+   if (plane->format_default)
+   return true;
+
+   if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
+   return true;
+   }
+
+   return false;
+}
+
 static int framebuffer_check(struct drm_device *dev,
 const struct drm_mode_fb_cmd2 *r)
 {
const struct drm_format_info *info;
+   u64 modifier = 0;
int i;
 
+   if (r->flags & DRM_MODE_FB_MODIFIERS)
+   modifier = r->modifier[0];
+
/* check if the format is supported at all */
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
@@ -168,6 +193,15 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
 
+   if (!any_plane_has_format(dev, r->pixel_format, modifier)) {
+   struct drm_format_name_buf format_name;
+
+   DRM_DEBUG_KMS("unsupported pixel format %s, modifier 0x%llx\n",
+ drm_get_format_name(r->pixel_format, 
_name),
+ modifier);
+   return -EINVAL;
+   }
+
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
 
@@ -202,14 +236,7 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
 
-   if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
-   DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
- r->modifier[i], i);
-   return -EINVAL;
-   }
-
-   if (r->flags & DRM_MODE_FB_MODIFIERS &&
-   r->modifier[i] != r->modifier[0]) {
+   if (r->modifier[i] != modifier) {
DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
  r->modifier[i], i);
return -EINVAL;
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Alex Deucher]

On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä
 wrote:
> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
>> Ville Syrjala  writes:
>>
>> > From: Ville Syrjälä 
>> >
>> > To make life easier for drivers, let's have the core check that the
>> > requested pixel format is supported by at least one plane when creating
>> > a new framebuffer.
>> >
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/drm_framebuffer.c | 26 ++
>> >  1 file changed, 26 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> > b/drivers/gpu/drm/drm_framebuffer.c
>> > index c0530a1af5e3..155b21e579c4 100644
>> > --- a/drivers/gpu/drm/drm_framebuffer.c
>> > +++ b/drivers/gpu/drm/drm_framebuffer.c
>> > @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
>> > return DIV_ROUND_UP(height, format->vsub);
>> >  }
>> >
>> > +static bool planes_have_format(struct drm_device *dev, u32 format)
>> > +{
>> > +   struct drm_plane *plane;
>> > +
>> > +   /* TODO: maybe maintain a device level format list? */
>> > +   drm_for_each_plane(plane, dev) {
>> > +   int i;
>> > +
>> > +   for (i = 0; i < plane->format_count; i++) {
>> > +   if (plane->format_types[i] == format)
>> > +   return true;
>> > +   }
>> > +   }
>> > +
>> > +   return false;
>> > +}
>> > +
>> >  static int framebuffer_check(struct drm_device *dev,
>> >  const struct drm_mode_fb_cmd2 *r)
>> >  {
>> > @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
>> > return -EINVAL;
>> > }
>> >
>> > +   if (!planes_have_format(dev, r->pixel_format)) {
>> > +   struct drm_format_name_buf format_name;
>> > +
>> > +   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
>> > + drm_get_format_name(r->pixel_format,
>> > + _name));
>> > +   return -EINVAL;
>> > +   }
>> > +
>>
>> Won't this break KMS on things like the radeon driver, which doesn't do
>> planes?  Maybe check if any universal planes have been registered and
>> only do the check in that case?
>
> Hmm. I thought we add the implicit planes always. Apparently
> drm_crtc_init() adds a primary with X/ARGB, but no more. So
> this would break all other formats, which is probably a bit too
> aggressive.
>
> I guess I could just skip the check in case any plane has
> plane->format_default set. That should be indicating that the driver
> doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
> Harry?

Probably leftover from DC bringup?

Alex

>
>>
>> Also, "any_planes_have_format()" might be slightly more descriptive.
>
> Or any_plane_has_format()? Is that more englishy? :)
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Question about latest skl_dmc_ver1_27.bin and kernel version.

[Paul Knopf]

I am trying to setup Intel's new open-source iHD driver on a Yocto
environment.

https://software.intel.com/en-us/articles/build-and-debug-open-source-media-stack

The documentation says that skl_dmc_ver1_27.bin is required. Their
documentation updates a symlink (skl_dmc_ver1.bin), as if the kernel loads
it, but starting at kernel 4.8, it stopped loading the symlink and instead
loads a specific version of the dmc (see here:
https://github.com/torvalds/linux/blob/v4.8/drivers/gpu/drm/i915/intel_csr.c#L48).
Is the Intel documentation accurate? It is confusing because the guide
refers to 4.14.16 specifically, which doesn't use the symlink file
skl_dmc_ver1.bin.

Any ways, I tried replacing skl_dmc_ver1_26.bin with skl_dmc_ver1_27.bin to
have the same effect, but I got a segfault on boot.

https://pastebin.com/amW9vDdC

Should I even bother updating the DMC? Should the iHD driver work on most
kernels, even with 1_26 version of DMC?

By the way, this is the kernel I am using (with Yocto).

https://github.com/intel/linux-intel-lts/tree/4.14/yocto/base/drivers/gpu/drm/i915

Any help would be greatly appreciated. There is no documentation on this
stuff.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjälä]

On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
> Ville Syrjala  writes:
> 
> > From: Ville Syrjälä 
> >
> > To make life easier for drivers, let's have the core check that the
> > requested pixel format is supported by at least one plane when creating
> > a new framebuffer.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_framebuffer.c | 26 ++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index c0530a1af5e3..155b21e579c4 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
> > return DIV_ROUND_UP(height, format->vsub);
> >  }
> >  
> > +static bool planes_have_format(struct drm_device *dev, u32 format)
> > +{
> > +   struct drm_plane *plane;
> > +
> > +   /* TODO: maybe maintain a device level format list? */
> > +   drm_for_each_plane(plane, dev) {
> > +   int i;
> > +
> > +   for (i = 0; i < plane->format_count; i++) {
> > +   if (plane->format_types[i] == format)
> > +   return true;
> > +   }
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >  static int framebuffer_check(struct drm_device *dev,
> >  const struct drm_mode_fb_cmd2 *r)
> >  {
> > @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
> > return -EINVAL;
> > }
> >  
> > +   if (!planes_have_format(dev, r->pixel_format)) {
> > +   struct drm_format_name_buf format_name;
> > +
> > +   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
> > + drm_get_format_name(r->pixel_format,
> > + _name));
> > +   return -EINVAL;
> > +   }
> > +
> 
> Won't this break KMS on things like the radeon driver, which doesn't do
> planes?  Maybe check if any universal planes have been registered and
> only do the check in that case?

Hmm. I thought we add the implicit planes always. Apparently
drm_crtc_init() adds a primary with X/ARGB, but no more. So
this would break all other formats, which is probably a bit too
aggressive.

I guess I could just skip the check in case any plane has
plane->format_default set. That should be indicating that the driver
doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
Harry?

> 
> Also, "any_planes_have_format()" might be slightly more descriptive.

Or any_plane_has_format()? Is that more englishy? :)

-- 
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 1/3] drm: Make sure at least one plane supports the fb format

[Eric Anholt]

Ville Syrjala  writes:

> From: Ville Syrjälä 
>
> To make life easier for drivers, let's have the core check that the
> requested pixel format is supported by at least one plane when creating
> a new framebuffer.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_framebuffer.c | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index c0530a1af5e3..155b21e579c4 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
>   return DIV_ROUND_UP(height, format->vsub);
>  }
>  
> +static bool planes_have_format(struct drm_device *dev, u32 format)
> +{
> + struct drm_plane *plane;
> +
> + /* TODO: maybe maintain a device level format list? */
> + drm_for_each_plane(plane, dev) {
> + int i;
> +
> + for (i = 0; i < plane->format_count; i++) {
> + if (plane->format_types[i] == format)
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
>  static int framebuffer_check(struct drm_device *dev,
>const struct drm_mode_fb_cmd2 *r)
>  {
> @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
>   return -EINVAL;
>   }
>  
> + if (!planes_have_format(dev, r->pixel_format)) {
> + struct drm_format_name_buf format_name;
> +
> + DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
> +   drm_get_format_name(r->pixel_format,
> +   _name));
> + return -EINVAL;
> + }
> +

Won't this break KMS on things like the radeon driver, which doesn't do
planes?  Maybe check if any universal planes have been registered and
only do the check in that case?

Also, "any_planes_have_format()" might be slightly more descriptive.


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm: Make sure at least one plane supports the fb format

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm: Make sure at least one plane supports 
the fb format
URL   : https://patchwork.freedesktop.org/series/39383/
State : failure

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-a-ts-continuation-modeset:
skip   -> PASS   (shard-snb)
Subgroup pipe-b-ts-continuation-suspend:
pass   -> INCOMPLETE (shard-snb)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-right-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +1
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
skip   -> PASS   (shard-snb) fdo#102670
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3468 pass:1827 dwarn:1   dfail:0   fail:7   skip:1633 
time:12186s
shard-hswtotal:3468 pass:1773 dwarn:1   dfail:0   fail:2   skip:1691 
time:11686s
shard-snbtotal:3387 pass:1335 dwarn:2   dfail:0   fail:1   skip:2048 
time:6917s
Blacklisted hosts:
shard-kbltotal:3387 pass:1915 dwarn:1   dfail:0   fail:7   skip:1463 
time:8970s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8232/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Check that the error state does hold the expected state

[Antonio Argenziano]

On 05/03/18 02:09, Chris Wilson wrote:

Actually check the error state exists (!"No error state captured") and
that it contains the expected engine dump.

v2: Throw in some debug clues.

Signed-off-by: Chris Wilson 
---
  tests/drv_hangman.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index 38cb20c3..fa7becf5 100644
--- a/tests/drv_hangman.c
+++ b/tests/drv_hangman.c
@@ -129,6 +129,14 @@ static void check_error_state(const char 
*expected_ring_name,
FILE *file = open_error();
char *line = NULL;
size_t line_size = 0;
+   bool found = false;
+
+   igt_debug("%s(expected ring name=%s, expected offset=%"PRIx64")\n",
+ __func__, expected_ring_name, expected_offset);
+   igt_debugfs_dump(device, "i915_error_state");
+
+   getline(, _size, file);
+   igt_assert(strcasecmp(line, "No error state captured"));
  
  	while (getline(, _size, file) > 0) {

char *dashes;
@@ -168,12 +176,16 @@ static void check_error_state(const char 
*expected_ring_name,
 4*i, batch[i]);
igt_assert(strstr(line, expected_line));
}
+
+   found = true;
break;
}
}
  
  	free(line);

fclose(file);
+
+   igt_assert(found);


Test changes look fine to me, failures on CI seems to be caused by the 
test not waiting for reset to happen only before we would have not 
caught it.


Reviwed-by: Antonio Argenziano 


  }
  
  static void test_error_state_capture(unsigned ring_id,



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

Re: [Intel-gfx] [PATCH 13/16] drm/i915: Add NV12 as supported format for primary plane

[Ville Syrjälä]

On Fri, Feb 23, 2018 at 10:08:25AM +, Srinivas, Vidya wrote:
> 
> 
> > -Original Message-
> > From: Juha-Pekka Heikkila [mailto:juhapekka.heikk...@gmail.com]
> > Sent: Friday, February 23, 2018 3:35 PM
> > To: Srinivas, Vidya ; intel-
> > g...@lists.freedesktop.org
> > Cc: Maarten Lankhorst 
> > Subject: Re: [Intel-gfx] [PATCH 13/16] drm/i915: Add NV12 as supported
> > format for primary plane
> > 
> > On 23.02.2018 05:06, Srinivas, Vidya wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Juha-Pekka Heikkila [mailto:juhapekka.heikk...@gmail.com]
> > >> Sent: Thursday, February 22, 2018 7:06 PM
> > >> To: Srinivas, Vidya ; intel-
> > >> g...@lists.freedesktop.org
> > >> Subject: Re: [Intel-gfx] [PATCH 13/16] drm/i915: Add NV12 as
> > >> supported format for primary plane
> > >>
> > >> On 22.02.2018 04:39, Srinivas, Vidya wrote:
> > >>>
> > >>>
> >  -Original Message-
> >  From: Juha-Pekka Heikkila [mailto:juhapekka.heikk...@gmail.com]
> >  Sent: Wednesday, February 21, 2018 7:52 PM
> >  To: Srinivas, Vidya ; intel-
> >  g...@lists.freedesktop.org
> >  Subject: Re: [Intel-gfx] [PATCH 13/16] drm/i915: Add NV12 as
> >  supported format for primary plane
> > 
> >  On 21.02.2018 12:20, Vidya Srinivas wrote:
> > > From: Chandra Konduru 
> > >
> > > This patch adds NV12 to list of supported formats for primary
> > > plane
> > >
> > > v2: Rebased (Chandra Konduru)
> > >
> > > v3: Rebased (me)
> > >
> > > v4: Review comments by Ville addressed Removed the
> > > skl_primary_formats_with_nv12 and added NV12 case in existing
> > > skl_primary_formats
> > >
> > > v5: Rebased (me)
> > >
> > > v6: Missed the Tested-by/Reviewed-by in the previous series Adding
> > > the same to commit message in this version.
> > >
> > > v7: Review comments by Ville addressed
> > >   Restricting the NV12 for BXT and on PIPE A and B Rebased (me)
> > >
> > > v8: Rebased (me)
> > > Modified restricting the NV12 support for both BXT and KBL.
> > >
> > > v9: Rebased (me)
> > >
> > > v10: Addressed review comments from Maarten.
> > >   Adding NV12 inside skl_primary_formats itself.
> > >
> > > v11: Adding Reviewed By tag from Shashank Sharma
> > >
> > > Tested-by: Clinton Taylor 
> > > Reviewed-by: Clinton Taylor 
> > > Reviewed-by: Shashank Sharma 
> > > Signed-off-by: Chandra Konduru 
> > > Signed-off-by: Nabendu Maiti 
> > > Signed-off-by: Vidya Srinivas 
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 142dfe0..1870366 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = {
> > >   DRM_FORMAT_YVYU,
> > >   DRM_FORMAT_UYVY,
> > >   DRM_FORMAT_VYUY,
> > > + DRM_FORMAT_NV12,
> > > };
> > >
> > > static const uint64_t skl_format_modifiers_noccs[] = { @@
> > > -13282,6
> > > +13283,10 @@ intel_primary_plane_create(struct drm_i915_private
> >  *dev_priv, enum pipe pipe)
> > >   intel_primary_formats = skl_primary_formats;
> > >   num_formats = ARRAY_SIZE(skl_primary_formats);
> > >
> > > + if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C)
> > &&
> > > + !IS_GEMINILAKE(dev_priv))
> > > + num_formats -= 1;
> > 
> >  This doesn't look future proof solution. This creates invisible
> >  dependency where it is required NV12 is last item in list of formats.
> > >>>
> > >>> Initially we had a different array for this. But as a part of one of
> > >>> the review comments, I made this change.
> > >>
> > >> I did see Maarten's comment on your older patch. In my opinion having
> > >> two lists would be more clear. Regardless of opinions on which is
> > >> better you maybe anyway want to reconsider this piece of code as this
> > >> expose
> > >> NV12 also for Skylake platform.
> > >
> > > Maarten, could you please add your inputs as well?
> > > I will change the patch according to what we decide.
> > > Thank you.
> > 
> > If other's see it better to keep it in one list I'm ok for that. To me it 
> > just feel
> > like accident waiting to happen if this list is changed at later time for 
> > different
> > reasons.
> > 
> > My other 

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_fbc parameter at runtime better.

[Rodrigo Vivi]

On Mon, Mar 05, 2018 at 01:36:08PM +0100, Maarten Lankhorst wrote:
> If i915.enable_fbc is cleared at runtime, but FBC was previously enabled
> then we don't disable FBC until the next time the crtc is disabled.
> 
> Make sure that if the module param is changed, we disable FBC in
> intel_fbc_post_update so we never have to worry about disabling.

What about switching this from a parameter to debugfs toggle like drrs?

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 62 
> +++-
>  1 file changed, 36 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index eaaa59b45707..5325b59c2f9c 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -949,6 +949,30 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
>   mutex_unlock(>lock);
>  }
>  
> +/**
> + * __intel_fbc_disable - disable FBC
> + * @dev_priv: i915 device instance
> + *
> + * This is the low level function that actually disables FBC. Callers should
> + * grab the FBC lock.
> + */
> +static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
> +{
> + struct intel_fbc *fbc = _priv->fbc;
> + struct intel_crtc *crtc = fbc->crtc;
> +
> + WARN_ON(!mutex_is_locked(>lock));
> + WARN_ON(!fbc->enabled);
> + WARN_ON(fbc->active);
> +
> + DRM_DEBUG_KMS("Disabling FBC on pipe %c\n", pipe_name(crtc->pipe));
> +
> + __intel_fbc_cleanup_cfb(dev_priv);
> +
> + fbc->enabled = false;
> + fbc->crtc = NULL;
> +}
> +
>  static void __intel_fbc_post_update(struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> @@ -960,6 +984,13 @@ static void __intel_fbc_post_update(struct intel_crtc 
> *crtc)
>   if (!fbc->enabled || fbc->crtc != crtc)
>   return;
>  
> + if (!i915_modparams.enable_fbc) {
> + intel_fbc_deactivate(dev_priv, "disabled at runtime per module 
> param");
> + __intel_fbc_disable(dev_priv);
> +
> + return;
> + }
> +
>   if (!intel_fbc_can_activate(crtc)) {
>   WARN_ON(fbc->active);
>   return;
> @@ -1163,31 +1194,6 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>   mutex_unlock(>lock);
>  }
>  
> -/**
> - * __intel_fbc_disable - disable FBC
> - * @dev_priv: i915 device instance
> - *
> - * This is the low level function that actually disables FBC. Callers should
> - * grab the FBC lock.
> - */
> -static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
> -{
> - struct intel_fbc *fbc = _priv->fbc;
> - struct intel_crtc *crtc = fbc->crtc;
> -
> - WARN_ON(!mutex_is_locked(>lock));
> - WARN_ON(!fbc->enabled);
> - WARN_ON(fbc->active);
> - WARN_ON(crtc->active);
> -
> - DRM_DEBUG_KMS("Disabling FBC on pipe %c\n", pipe_name(crtc->pipe));
> -
> - __intel_fbc_cleanup_cfb(dev_priv);
> -
> - fbc->enabled = false;
> - fbc->crtc = NULL;
> -}
> -
>  /**
>   * intel_fbc_disable - disable FBC if it's associated with crtc
>   * @crtc: the CRTC
> @@ -1202,6 +1208,8 @@ void intel_fbc_disable(struct intel_crtc *crtc)
>   if (!fbc_supported(dev_priv))
>   return;
>  
> + WARN_ON(crtc->active);
> +
>   mutex_lock(>lock);
>   if (fbc->crtc == crtc)
>   __intel_fbc_disable(dev_priv);
> @@ -1224,8 +1232,10 @@ void intel_fbc_global_disable(struct drm_i915_private 
> *dev_priv)
>   return;
>  
>   mutex_lock(>lock);
> - if (fbc->enabled)
> + if (fbc->enabled) {
> + WARN_ON(fbc->crtc->active);
>   __intel_fbc_disable(dev_priv);
> + }
>   mutex_unlock(>lock);
>  
>   cancel_work_sync(>work.work);
> -- 
> 2.16.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] drm: i915: Fix audio issue on BXT

[Pandiyan, Dhinakaran]

On Thu, 2018-01-04 at 00:48 +0530, Gaurav K Singh wrote:
> From: Gaurav Singh 
> 
> On Apollolake, with stress test warm reboot, audio card
> was not getting enumerated after reboot. This was a
> spurious issue happening on Apollolake. HW codec and
> HD audio controller link was going out of sync for which
> there was a fix in i915 driver but was not getting invoked
> for BXT. Extending this fix to BXT as well.
> 
> Tested on apollolake chromebook by stress test warm reboot
> with 2500 iterations.
> 
> Signed-off-by: Gaurav K Singh 

Might be worth adding

Bspec: 21829

to the commit message.
Reviewed-by: Dhinakaran Pandiyan 

Please rebase and send this patch to the list to CI it.


> ---
>  drivers/gpu/drm/i915/intel_audio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index f1502a0188eb..c71c04e1c3f6 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -729,7 +729,7 @@ static void 
> i915_audio_component_codec_wake_override(struct device *kdev,
>   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
>   u32 tmp;
>  
> - if (!IS_GEN9_BC(dev_priv))
> + if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv))
>   return;
>  
>   i915_audio_component_get_power(kdev);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.

[Maarten Lankhorst]

Only try to set those values if the properties are supported.
This fixes the kms_chameium tests to run on vc4 again.

Reported-by: Maxime Ripard 
Cc: Paul Kocialkowski 
Cc: Eric Anholt 
Cc: Boris Brezillon 
Signed-off-by: Maarten Lankhorst 
---
 tests/kms_chamelium.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
index 8855a8300049..2bc34d07788d 100644
--- a/tests/kms_chamelium.c
+++ b/tests/kms_chamelium.c
@@ -471,9 +471,12 @@ enable_output(data_t *data,
igt_output_override_mode(output, mode);
 
/* Clear any color correction values that might be enabled */
-   igt_pipe_obj_replace_prop_blob(primary->pipe, IGT_CRTC_DEGAMMA_LUT, 
NULL, 0);
-   igt_pipe_obj_replace_prop_blob(primary->pipe, IGT_CRTC_GAMMA_LUT, NULL, 
0);
-   igt_pipe_obj_replace_prop_blob(primary->pipe, IGT_CRTC_CTM, NULL, 0);
+   if (igt_pipe_obj_has_prop(primary->pipe, IGT_CRTC_DEGAMMA_LUT))
+   igt_pipe_obj_replace_prop_blob(primary->pipe, 
IGT_CRTC_DEGAMMA_LUT, NULL, 0);
+   if (igt_pipe_obj_has_prop(primary->pipe, IGT_CRTC_GAMMA_LUT))
+   igt_pipe_obj_replace_prop_blob(primary->pipe, 
IGT_CRTC_GAMMA_LUT, NULL, 0);
+   if (igt_pipe_obj_has_prop(primary->pipe, IGT_CRTC_CTM))
+   igt_pipe_obj_replace_prop_blob(primary->pipe, IGT_CRTC_CTM, 
NULL, 0);
 
igt_display_commit2(display, COMMIT_ATOMIC);
 
-- 
2.16.2

___
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: Remove GUC_CTL_DEVICE_INFO parameter

[Michel Thierry]

On 3/5/2018 5:13 AM, Piotr Piórkowski wrote:

It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter
where we are passing GT type and Core family values.
Lets stop setup this parameter and remove related definitions.

v2: (this time without squashed HAX)
   - New title and description
   - Remove also GUC_CORE_FAMILY_* definitions (Michel)

Signed-off-by: Piotr Piórkowski 
Cc: Sagar Arun Kamble 
Cc: Michał Winiarski 
Cc: John A Spotswood 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc.c  | 24 
  drivers/gpu/drm/i915/intel_guc_fwif.h |  7 ---
  2 files changed, 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index ff08ea0ebf49..efc413137a89 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -200,26 +200,6 @@ void intel_guc_fini(struct intel_guc *guc)
guc_shared_data_destroy(guc);
  }
  
-static u32 get_gt_type(struct drm_i915_private *dev_priv)

-{
-   /* XXX: GT type based on PCI device ID? field seems unused by fw */
-   return 0;
-}
-
-static u32 get_core_family(struct drm_i915_private *dev_priv)
-{
-   u32 gen = INTEL_GEN(dev_priv);
-
-   switch (gen) {
-   case 9:
-   return GUC_CORE_FAMILY_GEN9;
-
-   default:
-   MISSING_CASE(gen);
-   return GUC_CORE_FAMILY_UNKNOWN;
-   }
-}
-
  static u32 get_log_verbosity_flags(void)
  {
if (i915_modparams.guc_log_level > 0) {
@@ -246,10 +226,6 @@ void intel_guc_init_params(struct intel_guc *guc)
  
  	memset(params, 0, sizeof(params));
  
-	params[GUC_CTL_DEVICE_INFO] |=

-   (get_gt_type(dev_priv) << GUC_CTL_GT_TYPE_SHIFT) |
-   (get_core_family(dev_priv) << GUC_CTL_CORE_FAMILY_SHIFT);
-
/*
 * GuC ARAT increment is 10 ns. GuC default scheduler quantum is one
 * second. This ARAR is calculated by:
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 6a10aa6f04d3..5131e67e663f 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -23,9 +23,6 @@
  #ifndef _INTEL_GUC_FWIF_H
  #define _INTEL_GUC_FWIF_H
  
-#define GUC_CORE_FAMILY_GEN9		12

-#define GUC_CORE_FAMILY_UNKNOWN0x7fff
-
  #define GUC_CLIENT_PRIORITY_KMD_HIGH  0
  #define GUC_CLIENT_PRIORITY_HIGH  1
  #define GUC_CLIENT_PRIORITY_KMD_NORMAL2
@@ -81,10 +78,6 @@
  #define GUC_CTL_ARAT_HIGH 1
  #define GUC_CTL_ARAT_LOW  2
  
-#define GUC_CTL_DEVICE_INFO		3


I would keep GUC_CTL_DEVICE_INFO (still removing _GT_TYPE_SHIFT and 
_CORE_FAMILY_SHIFT). The reason is that these constants kindof also 
document what the guc_control is. Other people may even suggest to 
rename it GUC_CTL_RSRVD0.


That's why we have GUC_CTL_PAGE_FAULT_CONTROL and GUC_CTL_RSRVD defined 
but not used.



-#define   GUC_CTL_GT_TYPE_SHIFT0
-#define   GUC_CTL_CORE_FAMILY_SHIFT7
-
  #define GUC_CTL_LOG_PARAMS4
  #define   GUC_LOG_VALID   (1 << 0)
  #define   GUC_LOG_NOTIFY_ON_HALF_FULL (1 << 1)



I think the consensus was that gt_type and core_family are not needed 
now, and if someone needs them at some point in the very very distant 
future, then the same person can re-add them, so


Acked-by: Michel Thierry 
___
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: Don't initialize plane_to_crtc_mapping[] on SKL+

[Patchwork]

== Series Details ==

Series: drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+
URL   : https://patchwork.freedesktop.org/series/39393/
State : success

== Summary ==

Series 39393v1 drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+
https://patchwork.freedesktop.org/api/1.0/series/39393/revisions/1/mbox/

 Known issues:

Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:476s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:500s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:503s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:449s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:529s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s

4a3784737699f45784335e1c9446596bf7833606 drm-tip: 2018y-03m-05d-14h-32m-57s UTC 
integration manifest
1179eef185c2 drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8234/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+

[Ville Syrjala]

From: Ville Syrjälä 

We don't use the enum i9xx_plane_id namespace on SKL+ anymore, so
do not initialize the related plane_to_crtc_mapping[] table either.

Actually the only remaining user of that table is the pre-g4x
watermark code, but no harm in initializing the table on all
pre-SKL platforms.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb08590b4d40..435462bfc719 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13572,10 +13572,17 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
/* initialize shared scalers */
intel_crtc_init_scalers(intel_crtc, crtc_state);
 
-   BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
-  dev_priv->plane_to_crtc_mapping[primary->i9xx_plane] != NULL);
-   dev_priv->plane_to_crtc_mapping[primary->i9xx_plane] = intel_crtc;
-   dev_priv->pipe_to_crtc_mapping[intel_crtc->pipe] = intel_crtc;
+   BUG_ON(pipe >= ARRAY_SIZE(dev_priv->pipe_to_crtc_mapping) ||
+  dev_priv->pipe_to_crtc_mapping[pipe] != NULL);
+   dev_priv->pipe_to_crtc_mapping[pipe] = intel_crtc;
+
+   if (INTEL_GEN(dev_priv) < 9) {
+   enum i9xx_plane_id i9xx_plane = primary->i9xx_plane;
+
+   BUG_ON(i9xx_plane >= 
ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
+  dev_priv->plane_to_crtc_mapping[i9xx_plane] != NULL);
+   dev_priv->plane_to_crtc_mapping[i9xx_plane] = intel_crtc;
+   }
 
drm_crtc_helper_add(_crtc->base, _helper_funcs);
 
-- 
2.16.1

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

[Intel-gfx] [PATCH igt v3] igt/gen7_forcewake_mt: Make the mmio register as volatile

[Chris Wilson]

Prevent the compiler from caching reads/writes to the hw register as we
do want to perform mmio.

Whilst fixing up the mmio access, also ensure that we do not leave the
test with any other bits still set in the forcewake register to prevent
affecting other tests, as spotted by Tvrtko.

v2: Use intel_mmio_use_pci_bar() rather open code the ioremap
v3: Flip igt_wait() checking as it returns true on success, not errno.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/gen7_forcewake_mt.c | 75 +++
 1 file changed, 49 insertions(+), 26 deletions(-)

diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9..6818d7aa 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -41,12 +41,14 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround 
required for"
 " FORCEWAKE_MT.");
 
 #define FORCEWAKE_MT 0xa188
+#define READ_ONCE(x) (*(volatile typeof(x) *)(&(x)))
 
 struct thread {
pthread_t thread;
-   void *mmio;
+   volatile uint32_t *forcewake_mt;
int fd;
int bit;
+   bool done;
 };
 
 static const struct pci_id_match match[] = {
@@ -77,43 +79,38 @@ static struct pci_device *__igfx_get(void)
pci_iterator_destroy(iter);
}
 
+   pci_device_probe(dev);
return dev;
 }
 
-static void *igfx_get_mmio(void)
+static volatile uint32_t *igfx_mmio_forcewake_mt(void)
 {
struct pci_device *pci = __igfx_get();
-   void *mmio = NULL;
-   int error;
 
-   igt_skip_on(pci == NULL);
-   igt_skip_on(intel_gen(pci->device_id) != 7);
+   igt_require(pci && intel_gen(pci->device_id) == 7);
 
-   error = pci_device_probe(pci);
-   igt_assert_eq(error, 0);
+   intel_mmio_use_pci_bar(pci);
 
-   error = pci_device_map_range(pci,
-pci->regions[0].base_addr,
-2*1024*1024,
-PCI_DEV_MAP_FLAG_WRITABLE,
-);
-   igt_assert_eq(error, 0);
-   igt_assert(mmio != NULL);
-
-   return mmio;
+   return (volatile uint32_t *)((char *)igt_global_mmio + FORCEWAKE_MT);
 }
 
 static void *thread(void *arg)
 {
+   static const char acquire_error[] = "acquire";
+   static const char release_error[] = "release";
+
struct thread *t = arg;
-   uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
-   uint32_t bit = 1 << t->bit;
+   const uint32_t bit = 1 << t->bit;
+   volatile uint32_t *forcewake_mt = t->forcewake_mt;
 
-   while (1) {
+   while (!READ_ONCE(t->done)) {
*forcewake_mt = bit << 16 | bit;
-   igt_assert(*forcewake_mt & bit);
+   if (!igt_wait(*forcewake_mt & bit, 50, 1))
+   return (void *)acquire_error;
+
*forcewake_mt = bit << 16;
-   igt_assert((*forcewake_mt & bit) == 0);
+   if (!igt_wait((*forcewake_mt & bit) == 0, 50, 1))
+   return (void *)release_error;
}
 
return NULL;
@@ -124,10 +121,12 @@ static void *thread(void *arg)
 igt_simple_main
 {
struct thread t[16];
+   bool success = true;
int i;
 
t[0].fd = drm_open_driver(DRIVER_INTEL);
-   t[0].mmio = igfx_get_mmio();
+   t[0].forcewake_mt = igfx_mmio_forcewake_mt();
+   t[0].done = false;
 
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -137,7 +136,7 @@ igt_simple_main
 
sleep(2);
 
-   for (i = 0; i < 1000; i++) {
+   igt_until_timeout(2) {
uint32_t *p;
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 exec[2];
@@ -192,13 +191,37 @@ igt_simple_main
p = gem_mmap__gtt(t[0].fd, exec[0].handle, 4096, PROT_READ);
 
igt_info("[%d]={ %08x %08x }\n", i, p[0], p[1]);
-   igt_assert(p[0] & 2);
-   igt_assert((p[1] & 2) == 0);
+   if ((p[0] & 2) == 0) {
+   igt_warn("Failed to acquire forcewake BIT(1) from 
batch\n");
+   success = false;
+   }
+   if ((p[1] & 2)) {
+   igt_warn("Failed to release forcewake BIT(1) from 
batch\n");
+   success = false;
+   }
 
munmap(p, 4096);
gem_close(t[0].fd, exec[0].handle);
gem_close(t[0].fd, exec[1].handle);
+   if (!success)
+   break;
 
usleep(1000);
}
+
+   for (i = 2; i < 16; i++) {
+   void *result;
+
+   t[i].done = true;
+   pthread_join(t[i].thread, );
+   if (result) {
+   igt_warn("Thread BIT(%d) failed to %s forcewake\n", i, 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Some plane init cleanups

[Patchwork]

== Series Details ==

Series: drm/i915: Some plane init cleanups
URL   : https://patchwork.freedesktop.org/series/39390/
State : failure

== Summary ==

Series 39390v1 drm/i915: Some plane init cleanups
https://patchwork.freedesktop.org/api/1.0/series/39390/revisions/1/mbox/

 Possible new issues:

Test core_auth:
Subgroup basic-auth:
pass   -> INCOMPLETE (fi-bxt-j4205)
pass   -> INCOMPLETE (fi-cfl-8700k)
pass   -> INCOMPLETE (fi-cfl-s2)
pass   -> INCOMPLETE (fi-cfl-u)
pass   -> INCOMPLETE (fi-cnl-y3)
pass   -> INCOMPLETE (fi-glk-1)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-kbl-7560u)
pass   -> INCOMPLETE (fi-kbl-7567u)
pass   -> INCOMPLETE (fi-kbl-r)
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-skl-6600u)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-skl-6700k2)
pass   -> INCOMPLETE (fi-skl-6770hq)
pass   -> INCOMPLETE (fi-skl-guc)
pass   -> INCOMPLETE (fi-skl-gvtdvm)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-j4205 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-8700k total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-cfl-s2total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-cfl-u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-cnl-y3total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7560u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7567u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-r total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6600u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6700hqtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6700k2total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6770hqtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-guc   total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-gvtdvmtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
fi-bxt-dsi failed to collect. IGT log at Patchwork_8233/fi-bxt-dsi/run0.log

4a3784737699f45784335e1c9446596bf7833606 drm-tip: 2018y-03m-05d-14h-32m-57s UTC 
integration manifest
b3c15f19e6c7 drm/i915: s/intel_plane/plane/ in sprite init
a1b45d3a5842 drm/i915: Extract skl_universal_plane_init()
989cbe353f70 drm/i915: Introduce intel_plane_alloc()
73b10908f2d1 drm/i915: Move plane_state->scaler_id initialization into 
intel_create_plane_state()

Re: [Intel-gfx] [PATCH igt] Bump measure_ring_size() timer interval

[Antonio Argenziano]

On 05/03/18 03:03, Chris Wilson wrote:

It appears that waiting for a 100us period whereby we are unable to
submit another batch and proclaim the ring full, may have the false
positive where the scheduler intervenes and we are signalled twice
before having slept on ring space. Increasing the interval reduces the
likelihood of the scheduler stealing the cpu from us, but does not
eliminate it. Fortuitously it appears to be a rare false positive.

For the library routine, we can fork a RT process but that seems a bit
overkill!

References: https://bugs.freedesktop.org/show_bug.cgi?id=105343
Signed-off-by: Chris Wilson 
Cc: Antonio Argenziano 


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

[Intel-gfx] [PATCH 10/11] drm/i915: Extract skl_universal_plane_init()

[Ville Syrjala]

From: Ville Syrjälä 

There's not much point in following the primary vs. sprite
for the SKL+ universal plane init code. The only difference is
of our own doing in the form of the .check_plane(). Let's make
a small exception for that little detail and otherwise share
the same code to initialize all the universal planes.

Eventually we should eliminate the mess around .check_plane()
as well, but for now let's be happy with some code reduction.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 129 ++---
 drivers/gpu/drm/i915/intel_drv.h |   8 +--
 drivers/gpu/drm/i915/intel_sprite.c  | 133 ---
 3 files changed, 117 insertions(+), 153 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6a3a03db41b4..411722721488 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -73,39 +73,6 @@ static const uint64_t i9xx_format_modifiers[] = {
DRM_FORMAT_MOD_INVALID
 };
 
-static const uint32_t skl_primary_formats[] = {
-   DRM_FORMAT_C8,
-   DRM_FORMAT_RGB565,
-   DRM_FORMAT_XRGB,
-   DRM_FORMAT_XBGR,
-   DRM_FORMAT_ARGB,
-   DRM_FORMAT_ABGR,
-   DRM_FORMAT_XRGB2101010,
-   DRM_FORMAT_XBGR2101010,
-   DRM_FORMAT_YUYV,
-   DRM_FORMAT_YVYU,
-   DRM_FORMAT_UYVY,
-   DRM_FORMAT_VYUY,
-};
-
-static const uint64_t skl_format_modifiers_noccs[] = {
-   I915_FORMAT_MOD_Yf_TILED,
-   I915_FORMAT_MOD_Y_TILED,
-   I915_FORMAT_MOD_X_TILED,
-   DRM_FORMAT_MOD_LINEAR,
-   DRM_FORMAT_MOD_INVALID
-};
-
-static const uint64_t skl_format_modifiers_ccs[] = {
-   I915_FORMAT_MOD_Yf_TILED_CCS,
-   I915_FORMAT_MOD_Y_TILED_CCS,
-   I915_FORMAT_MOD_Yf_TILED,
-   I915_FORMAT_MOD_Y_TILED,
-   I915_FORMAT_MOD_X_TILED,
-   DRM_FORMAT_MOD_LINEAR,
-   DRM_FORMAT_MOD_INVALID
-};
-
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13032,41 +12999,9 @@ static bool i965_mod_supported(uint32_t format, 
uint64_t modifier)
}
 }
 
-static bool skl_mod_supported(uint32_t format, uint64_t modifier)
-{
-   switch (format) {
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_ARGB:
-   case DRM_FORMAT_ABGR:
-   if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
-   modifier == I915_FORMAT_MOD_Y_TILED_CCS)
-   return true;
-   /* fall through */
-   case DRM_FORMAT_RGB565:
-   case DRM_FORMAT_XRGB2101010:
-   case DRM_FORMAT_XBGR2101010:
-   case DRM_FORMAT_YUYV:
-   case DRM_FORMAT_YVYU:
-   case DRM_FORMAT_UYVY:
-   case DRM_FORMAT_VYUY:
-   if (modifier == I915_FORMAT_MOD_Yf_TILED)
-   return true;
-   /* fall through */
-   case DRM_FORMAT_C8:
-   if (modifier == DRM_FORMAT_MOD_LINEAR ||
-   modifier == I915_FORMAT_MOD_X_TILED ||
-   modifier == I915_FORMAT_MOD_Y_TILED)
-   return true;
-   /* fall through */
-   default:
-   return false;
-   }
-}
-
-static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
-uint32_t format,
-uint64_t modifier)
+static bool i9xx_plane_format_mod_supported(struct drm_plane *plane,
+   uint32_t format,
+   uint64_t modifier)
 {
struct drm_i915_private *dev_priv = to_i915(plane->dev);
 
@@ -13077,9 +13012,7 @@ static bool 
intel_primary_plane_format_mod_supported(struct drm_plane *plane,
modifier != DRM_FORMAT_MOD_LINEAR)
return false;
 
-   if (INTEL_GEN(dev_priv) >= 9)
-   return skl_mod_supported(format, modifier);
-   else if (INTEL_GEN(dev_priv) >= 4)
+   if (INTEL_GEN(dev_priv) >= 4)
return i965_mod_supported(format, modifier);
else
return i8xx_mod_supported(format, modifier);
@@ -13095,7 +13028,7 @@ static bool 
intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
return modifier == DRM_FORMAT_MOD_LINEAR && format == 
DRM_FORMAT_ARGB;
 }
 
-static const struct drm_plane_funcs intel_plane_funcs = {
+static const struct drm_plane_funcs i9xx_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = intel_plane_destroy,
@@ -13103,7 +13036,7 @@ static const struct drm_plane_funcs intel_plane_funcs = 
{
.atomic_set_property = intel_plane_atomic_set_property,
.atomic_duplicate_state = 

[Intel-gfx] [PATCH 07/11] drm/i915: Add missing pixel formats for skl+ "sprites"

[Ville Syrjala]

From: Ville Syrjälä 

All SKL+ universal planes support the same set of formats (with the
exception of NV12 which we don't expose yet). Make the format lists
for primary and sprites the same.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 6e4bb721d71c..9b0789ccd103 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1251,12 +1251,15 @@ static const uint32_t vlv_plane_formats[] = {
DRM_FORMAT_VYUY,
 };
 
-static uint32_t skl_plane_formats[] = {
+static const uint32_t skl_plane_formats[] = {
+   DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
-   DRM_FORMAT_ABGR,
-   DRM_FORMAT_ARGB,
-   DRM_FORMAT_XBGR,
DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
DRM_FORMAT_YUYV,
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
-- 
2.16.1

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

[Intel-gfx] [PATCH 08/11] drm/i915: Move plane_state->scaler_id initialization into intel_create_plane_state()

[Ville Syrjala]

From: Ville Syrjälä 

No point in having each caller of intel_create_plane_state() initialize
the scaler_id to -1. Instead just do it in intel_create_plane_state().

Previously we left scaler_id at 0 for pre-SKL platforms, but I can't
see how initializing it to -1 always would cause any harm.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 1 +
 drivers/gpu/drm/i915/intel_display.c  | 7 +--
 drivers/gpu/drm/i915/intel_sprite.c   | 1 -
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce85746b..860ade4fc322 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -56,6 +56,7 @@ intel_create_plane_state(struct drm_plane *plane)
 
state->base.plane = plane;
state->base.rotation = DRM_MODE_ROTATE_0;
+   state->scaler_id = -1;
 
return state;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 431d07c2aacd..773aa6247cd8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13284,10 +13284,8 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 
primary->can_scale = false;
primary->max_downscale = 1;
-   if (INTEL_GEN(dev_priv) >= 9) {
+   if (INTEL_GEN(dev_priv) >= 9)
primary->can_scale = true;
-   state->scaler_id = -1;
-   }
primary->pipe = pipe;
/*
 * On gen2/3 only plane A can do FBC, but the panel fitter and LVDS
@@ -13484,9 +13482,6 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv,
   DRM_MODE_ROTATE_0 |
   DRM_MODE_ROTATE_180);
 
-   if (INTEL_GEN(dev_priv) >= 9)
-   state->scaler_id = -1;
-
drm_plane_helper_add(>base, _plane_helper_funcs);
 
return cursor;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 9b0789ccd103..5402124d9f97 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1453,7 +1453,6 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
 
if (INTEL_GEN(dev_priv) >= 9) {
intel_plane->can_scale = true;
-   state->scaler_id = -1;
 
intel_plane->update_plane = skl_update_plane;
intel_plane->disable_plane = skl_disable_plane;
-- 
2.16.1

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

[Intel-gfx] [PATCH 05/11] drm/i915: Allow horizontal mirroring for cnl+ "sprite" planes

[Ville Syrjala]

From: Ville Syrjälä 

All CNL universal planes support horizontal mirroring. Currently
we expose the capability only for the primary plane. Expose it
for the overlay planes as well.

Cc: Joonas Lahtinen 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 8d0dbf53a1e2..af7470c6bd62 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1493,7 +1493,12 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
}
}
 
-   if (INTEL_GEN(dev_priv) >= 9) {
+   if (INTEL_GEN(dev_priv) >= 10) {
+   supported_rotations =
+   DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 |
+   DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270 |
+   DRM_MODE_REFLECT_X;
+   } else if (INTEL_GEN(dev_priv) >= 9) {
supported_rotations =
DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 |
DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270;
-- 
2.16.1

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

[Intel-gfx] [PATCH 11/11] drm/i915: s/intel_plane/plane/ in sprite init

[Ville Syrjala]

From: Ville Syrjälä 

Use a more familiar naming pattern for our variables in the sprite plane
init function.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 78 ++---
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index ec0bba810fe7..a4968ddd98cc 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1524,9 +1524,9 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
 
 struct intel_plane *
 intel_sprite_plane_create(struct drm_i915_private *dev_priv,
- enum pipe pipe, int plane)
+ enum pipe pipe, int sprite)
 {
-   struct intel_plane *intel_plane;
+   struct intel_plane *plane;
unsigned long possible_crtcs;
const uint32_t *plane_formats;
const uint64_t *modifiers;
@@ -1535,55 +1535,55 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
int ret;
 
if (INTEL_GEN(dev_priv) >= 9) {
-   intel_plane = skl_universal_plane_create(dev_priv, pipe,
-PLANE_SPRITE0 + plane);
-   if (IS_ERR(intel_plane))
-   return intel_plane;
+   plane = skl_universal_plane_create(dev_priv, pipe,
+  PLANE_SPRITE0 + sprite);
+   if (IS_ERR(plane))
+   return plane;
 
/* FIXME unify */
-   intel_plane->check_plane = intel_check_sprite_plane;
+   plane->check_plane = intel_check_sprite_plane;
 
-   return intel_plane;
+   return plane;
}
 
-   intel_plane = intel_plane_alloc();
-   if (IS_ERR(intel_plane))
-   return intel_plane;
+   plane = intel_plane_alloc();
+   if (IS_ERR(plane))
+   return plane;
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   intel_plane->can_scale = false;
-   intel_plane->max_downscale = 1;
+   plane->can_scale = false;
+   plane->max_downscale = 1;
 
-   intel_plane->update_plane = vlv_update_plane;
-   intel_plane->disable_plane = vlv_disable_plane;
-   intel_plane->get_hw_state = vlv_plane_get_hw_state;
+   plane->update_plane = vlv_update_plane;
+   plane->disable_plane = vlv_disable_plane;
+   plane->get_hw_state = vlv_plane_get_hw_state;
 
plane_formats = vlv_plane_formats;
num_plane_formats = ARRAY_SIZE(vlv_plane_formats);
modifiers = i9xx_plane_format_modifiers;
} else if (INTEL_GEN(dev_priv) >= 7) {
if (IS_IVYBRIDGE(dev_priv)) {
-   intel_plane->can_scale = true;
-   intel_plane->max_downscale = 2;
+   plane->can_scale = true;
+   plane->max_downscale = 2;
} else {
-   intel_plane->can_scale = false;
-   intel_plane->max_downscale = 1;
+   plane->can_scale = false;
+   plane->max_downscale = 1;
}
 
-   intel_plane->update_plane = ivb_update_plane;
-   intel_plane->disable_plane = ivb_disable_plane;
-   intel_plane->get_hw_state = ivb_plane_get_hw_state;
+   plane->update_plane = ivb_update_plane;
+   plane->disable_plane = ivb_disable_plane;
+   plane->get_hw_state = ivb_plane_get_hw_state;
 
plane_formats = snb_plane_formats;
num_plane_formats = ARRAY_SIZE(snb_plane_formats);
modifiers = i9xx_plane_format_modifiers;
} else {
-   intel_plane->can_scale = true;
-   intel_plane->max_downscale = 16;
+   plane->can_scale = true;
+   plane->max_downscale = 16;
 
-   intel_plane->update_plane = g4x_update_plane;
-   intel_plane->disable_plane = g4x_disable_plane;
-   intel_plane->get_hw_state = g4x_plane_get_hw_state;
+   plane->update_plane = g4x_update_plane;
+   plane->disable_plane = g4x_disable_plane;
+   plane->get_hw_state = g4x_plane_get_hw_state;
 
modifiers = i9xx_plane_format_modifiers;
if (IS_GEN6(dev_priv)) {
@@ -1604,27 +1604,27 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180;
}
 
-   intel_plane->pipe = pipe;
-   intel_plane->id = PLANE_SPRITE0 + plane;
-   intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, intel_plane->id);
-   

[Intel-gfx] [PATCH 09/11] drm/i915: Introduce intel_plane_alloc()

[Ville Syrjala]

From: Ville Syrjälä 

Pull the common plane+plane_state allocation into a small helper.
Reduces the amount of boilerplate in the plane initialization
functions.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 44 ---
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 drivers/gpu/drm/i915/intel_sprite.c  | 50 
 3 files changed, 47 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 773aa6247cd8..6a3a03db41b4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13259,8 +13259,7 @@ static bool skl_plane_has_fbc(struct drm_i915_private 
*dev_priv,
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
-   struct intel_plane *primary = NULL;
-   struct intel_plane_state *state = NULL;
+   struct intel_plane *primary;
const uint32_t *intel_primary_formats;
unsigned int supported_rotations;
unsigned int possible_crtcs;
@@ -13268,19 +13267,9 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
const uint64_t *modifiers;
int ret;
 
-   primary = kzalloc(sizeof(*primary), GFP_KERNEL);
-   if (!primary) {
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   state = intel_create_plane_state(>base);
-   if (!state) {
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   primary->base.state = >base;
+   primary = intel_plane_alloc();
+   if (IS_ERR(primary))
+   return primary;
 
primary->can_scale = false;
primary->max_downscale = 1;
@@ -13410,8 +13399,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
return primary;
 
 fail:
-   kfree(state);
-   kfree(primary);
+   intel_plane_free(primary);
 
return ERR_PTR(ret);
 }
@@ -13420,24 +13408,13 @@ static struct intel_plane *
 intel_cursor_plane_create(struct drm_i915_private *dev_priv,
  enum pipe pipe)
 {
-   struct intel_plane *cursor = NULL;
-   struct intel_plane_state *state = NULL;
unsigned int possible_crtcs;
+   struct intel_plane *cursor;
int ret;
 
-   cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
-   if (!cursor) {
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   state = intel_create_plane_state(>base);
-   if (!state) {
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   cursor->base.state = >base;
+   cursor = intel_plane_alloc();
+   if (IS_ERR(cursor))
+   return cursor;
 
cursor->can_scale = false;
cursor->max_downscale = 1;
@@ -13487,8 +13464,7 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv,
return cursor;
 
 fail:
-   kfree(state);
-   kfree(cursor);
+   intel_plane_free(cursor);
 
return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b728ac6726b0..d269d6263833 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2043,6 +2043,9 @@ void skl_disable_plane(struct intel_plane *plane, struct 
intel_crtc *crtc);
 bool skl_plane_get_hw_state(struct intel_plane *plane);
 bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
   enum pipe pipe, enum plane_id plane_id);
+struct intel_plane *intel_plane_alloc(void);
+void intel_plane_free(struct intel_plane *plane);
+
 
 /* intel_tv.c */
 void intel_tv_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 5402124d9f97..e6092f12e653 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1425,12 +1425,40 @@ bool skl_plane_has_ccs(struct drm_i915_private 
*dev_priv,
 plane_id == PLANE_SPRITE0);
 }
 
+struct intel_plane *intel_plane_alloc(void)
+{
+   struct intel_plane_state *plane_state;
+   struct intel_plane *plane;
+
+   plane = kzalloc(sizeof(*plane), GFP_KERNEL);
+   if (!plane)
+   return ERR_PTR(-ENOMEM);
+
+   plane_state = intel_create_plane_state(>base);
+   if (!plane_state) {
+   kfree(plane);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   plane->base.state = _state->base;
+
+   return plane;
+}
+
+void intel_plane_free(struct intel_plane *plane)
+{
+   struct intel_plane_state *plane_state =
+   to_intel_plane_state(plane->base.state);
+
+   kfree(plane_state);
+   kfree(plane);
+}
+
 struct intel_plane *
 intel_sprite_plane_create(struct drm_i915_private *dev_priv,
  enum pipe pipe, int 

[Intel-gfx] [PATCH 06/11] drm/i915: Disallow plane scaling with specific pixel formats

[Ville Syrjala]

From: Ville Syrjälä 

Plane scaling is not supported with specific pixel formats. Disallow
plane scaling when such a format is used. Currently the only such
pixel format we expose is C8, but in case we add more in the future
let's make it easy to deal with them.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_sprite.c  | 33 -
 3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 132640258491..431d07c2aacd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12882,7 +12882,7 @@ intel_check_primary_plane(struct intel_plane *plane,
 
if (INTEL_GEN(dev_priv) >= 9) {
/* use scaler when colorkey is not required */
-   if (!state->ckey.flags) {
+   if (!state->ckey.flags && intel_fb_scalable(state->base.fb)) {
min_scale = 1;
max_scale = skl_max_scale(to_intel_crtc(crtc), 
crtc_state);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1a7c5addcec3..b728ac6726b0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2027,6 +2027,7 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
 
 /* intel_sprite.c */
 bool intel_format_is_yuv(u32 format);
+bool intel_fb_scalable(const struct drm_framebuffer *fb);
 int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
 int usecs);
 struct intel_plane *intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index af7470c6bd62..6e4bb721d71c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -927,6 +927,19 @@ g4x_plane_get_hw_state(struct intel_plane *plane)
return ret;
 }
 
+bool intel_fb_scalable(const struct drm_framebuffer *fb)
+{
+   if (!fb)
+   return false;
+
+   switch (fb->format->format) {
+   case DRM_FORMAT_C8:
+   return false;
+   default:
+   return true;
+   }
+}
+
 static int
 intel_check_sprite_plane(struct intel_plane *plane,
 struct intel_crtc_state *crtc_state,
@@ -968,21 +981,23 @@ intel_check_sprite_plane(struct intel_plane *plane,
}
 
/* setup can_scale, min_scale, max_scale */
+   can_scale = false;
+   min_scale = DRM_PLANE_HELPER_NO_SCALING;
+   max_scale = DRM_PLANE_HELPER_NO_SCALING;
+
if (INTEL_GEN(dev_priv) >= 9) {
/* use scaler when colorkey is not required */
-   if (!state->ckey.flags) {
-   can_scale = 1;
+   if (!state->ckey.flags && intel_fb_scalable(fb)) {
+   can_scale = true;
min_scale = 1;
max_scale = skl_max_scale(crtc, crtc_state);
-   } else {
-   can_scale = 0;
-   min_scale = DRM_PLANE_HELPER_NO_SCALING;
-   max_scale = DRM_PLANE_HELPER_NO_SCALING;
}
} else {
-   can_scale = plane->can_scale;
-   max_scale = plane->max_downscale << 16;
-   min_scale = plane->can_scale ? 1 : (1 << 16);
+   if (intel_fb_scalable(fb)) {
+   can_scale = plane->can_scale;
+   max_scale = plane->max_downscale << 16;
+   min_scale = plane->can_scale ? 1 : (1 << 16);
+   }
}
 
/*
-- 
2.16.1

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

[Intel-gfx] [PATCH 01/11] drm/i915: Constify intel_plane_funcs

[Ville Syrjala]

From: Ville Syrjälä 

intel_plane funcs can be cosnt. Make it so.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb08590b4d40..f28c0bef89d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13095,7 +13095,7 @@ static bool 
intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
return modifier == DRM_FORMAT_MOD_LINEAR && format == 
DRM_FORMAT_ARGB;
 }
 
-static struct drm_plane_funcs intel_plane_funcs = {
+static const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = intel_plane_destroy,
-- 
2.16.1

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

[Intel-gfx] [PATCH 04/11] drm/i915: Don't populate plane->i9xx_plane for sprites

[Ville Syrjala]

From: Ville Syrjälä 

enum i9xx_plane_id namespace is not valid for any sprite plane,
so let's not even populate plane->i9xx_plane.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 73e39083429f..8d0dbf53a1e2 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1507,7 +1507,6 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
}
 
intel_plane->pipe = pipe;
-   intel_plane->i9xx_plane = plane;
intel_plane->id = PLANE_SPRITE0 + plane;
intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, intel_plane->id);
intel_plane->check_plane = intel_check_sprite_plane;
-- 
2.16.1

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

[Intel-gfx] [PATCH 02/11] drm/i915: Fix tabs vs. spaces

[Ville Syrjala]

From: Ville Syrjälä 

The sprite code has a bunch of spaces where tabs should be used. Fix it
up.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index dbdcf85032df..d9954e440396 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1357,8 +1357,8 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
 }
 
 static bool intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
-uint32_t format,
-uint64_t modifier)
+   uint32_t format,
+   uint64_t modifier)
 {
struct drm_i915_private *dev_priv = to_i915(plane->dev);
 
@@ -1380,14 +1380,14 @@ static bool 
intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
 }
 
 static const struct drm_plane_funcs intel_sprite_plane_funcs = {
-.update_plane = drm_atomic_helper_update_plane,
-.disable_plane = drm_atomic_helper_disable_plane,
-.destroy = intel_plane_destroy,
-.atomic_get_property = intel_plane_atomic_get_property,
-.atomic_set_property = intel_plane_atomic_set_property,
-.atomic_duplicate_state = intel_plane_duplicate_state,
-.atomic_destroy_state = intel_plane_destroy_state,
-.format_mod_supported = intel_sprite_plane_format_mod_supported,
+   .update_plane = drm_atomic_helper_update_plane,
+   .disable_plane = drm_atomic_helper_disable_plane,
+   .destroy = intel_plane_destroy,
+   .atomic_get_property = intel_plane_atomic_get_property,
+   .atomic_set_property = intel_plane_atomic_set_property,
+   .atomic_duplicate_state = intel_plane_duplicate_state,
+   .atomic_destroy_state = intel_plane_destroy_state,
+   .format_mod_supported = intel_sprite_plane_format_mod_supported,
 };
 
 bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
-- 
2.16.1

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

[Intel-gfx] [PATCH 03/11] drm/i915: Populate possible_crtcs for primary/cursor planes

[Ville Syrjala]

From: Ville Syrjälä 

We're currently not providing the possible_crtcs mask to
drm_universal_plane_init() for primary/cursor planes. While that does
work on account of drm_crtc_init_with_planes() filling those up
for us, it's inconsisten with what we're doing for sprite planes.

Let's just always pass the possible_crtcs bitmask to
drm_universal_plane_init(). This does assume that crtc->index
== pipe. But we're already making that assumption elsewhere so
it doesn't seem like a very big sin here.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 14 ++
 drivers/gpu/drm/i915/intel_sprite.c  |  2 +-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f28c0bef89d1..132640258491 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13263,6 +13263,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
struct intel_plane_state *state = NULL;
const uint32_t *intel_primary_formats;
unsigned int supported_rotations;
+   unsigned int possible_crtcs;
unsigned int num_formats;
const uint64_t *modifiers;
int ret;
@@ -13345,23 +13346,25 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
primary->get_hw_state = i9xx_plane_get_hw_state;
}
 
+   possible_crtcs = BIT(pipe);
+
if (INTEL_GEN(dev_priv) >= 9)
ret = drm_universal_plane_init(_priv->drm, >base,
-  0, _plane_funcs,
+  possible_crtcs, 
_plane_funcs,
   intel_primary_formats, 
num_formats,
   modifiers,
   DRM_PLANE_TYPE_PRIMARY,
   "plane 1%c", pipe_name(pipe));
else if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
ret = drm_universal_plane_init(_priv->drm, >base,
-  0, _plane_funcs,
+  possible_crtcs, 
_plane_funcs,
   intel_primary_formats, 
num_formats,
   modifiers,
   DRM_PLANE_TYPE_PRIMARY,
   "primary %c", pipe_name(pipe));
else
ret = drm_universal_plane_init(_priv->drm, >base,
-  0, _plane_funcs,
+  possible_crtcs, 
_plane_funcs,
   intel_primary_formats, 
num_formats,
   modifiers,
   DRM_PLANE_TYPE_PRIMARY,
@@ -13421,6 +13424,7 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv,
 {
struct intel_plane *cursor = NULL;
struct intel_plane_state *state = NULL;
+   unsigned int possible_crtcs;
int ret;
 
cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
@@ -13462,8 +13466,10 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv,
if (IS_I845G(dev_priv) || IS_I865G(dev_priv) || HAS_CUR_FBC(dev_priv))
cursor->cursor.size = ~0;
 
+   possible_crtcs = BIT(pipe);
+
ret = drm_universal_plane_init(_priv->drm, >base,
-  0, _cursor_plane_funcs,
+  possible_crtcs, 
_cursor_plane_funcs,
   intel_cursor_formats,
   ARRAY_SIZE(intel_cursor_formats),
   cursor_format_modifiers,
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index d9954e440396..73e39083429f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1512,7 +1512,7 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, intel_plane->id);
intel_plane->check_plane = intel_check_sprite_plane;
 
-   possible_crtcs = (1 << pipe);
+   possible_crtcs = BIT(pipe);
 
if (INTEL_GEN(dev_priv) >= 9)
ret = drm_universal_plane_init(_priv->drm, 
_plane->base,
-- 
2.16.1

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

[Intel-gfx] [PATCH 00/11] drm/i915: Some plane init cleanups

[Ville Syrjala]

From: Ville Syrjälä 

Attempt at cleaning up some of plane init stuff. The main attraction is
removing some of the code duplication in SKL+ "primary" vs. "sprite" init.

Ville Syrjälä (11):
  drm/i915: Constify intel_plane_funcs
  drm/i915: Fix tabs vs. spaces
  drm/i915: Populate possible_crtcs for primary/cursor planes
  drm/i915: Don't populate plane->i9xx_plane for sprites
  drm/i915: Allow horizontal mirroring for cnl+ "sprite" planes
  drm/i915: Disallow plane scaling with specific pixel formats
  drm/i915: Add missing pixel formats for skl+ "sprites"
  drm/i915: Move plane_state->scaler_id initialization into
intel_create_plane_state()
  drm/i915: Introduce intel_plane_alloc()
  drm/i915: Extract skl_universal_plane_init()
  drm/i915: s/intel_plane/plane/ in sprite init

 drivers/gpu/drm/i915/intel_atomic_plane.c |   1 +
 drivers/gpu/drm/i915/intel_display.c  | 184 ---
 drivers/gpu/drm/i915/intel_drv.h  |  12 +-
 drivers/gpu/drm/i915/intel_sprite.c   | 292 +++---
 4 files changed, 237 insertions(+), 252 deletions(-)

-- 
2.16.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Test the plane formats on the Chamelium

[Patchwork]

== Series Details ==

Series: Test the plane formats on the Chamelium
URL   : https://patchwork.freedesktop.org/series/39380/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
23f7da18a92059610792299cfdb03d2c922a9948 lib/igt_pm: Restore runtime pm state 
on test exit

with latest DRM-Tip kernel build CI_DRM_3872
4a3784737699 drm-tip: 2018y-03m-05d-14h-32m-57s UTC integration manifest

Testlist changes:
+igt@kms_chamelium_formats@hdmi-frame-dump

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:484s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:463s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:394s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:493s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:293s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:449s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:451s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:494s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1061/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle changing enable_fbc parameter at runtime better.

[Patchwork]

== Series Details ==

Series: drm/i915: Handle changing enable_fbc parameter at runtime better.
URL   : https://patchwork.freedesktop.org/series/39375/
State : success

== Summary ==

 Possible new issues:

Test drv_suspend:
Subgroup forcewake:
skip   -> PASS   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +2
Subgroup pipe-c-128x128-bottom-edge:
pass   -> FAIL   (shard-apl) fdo#104671
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#103167 +1
Test kms_plane_multiple:
Subgroup atomic-pipe-b-tiling-yf:
fail   -> PASS   (shard-apl) fdo#103166
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3468 pass:1824 dwarn:1   dfail:0   fail:9   skip:1633 
time:12250s
shard-hswtotal:3468 pass:1774 dwarn:1   dfail:0   fail:1   skip:1691 
time:11739s
shard-snbtotal:3468 pass:1362 dwarn:3   dfail:0   fail:2   skip:2101 
time:7058s
Blacklisted hosts:
shard-kbltotal:3326 pass:1868 dwarn:4   dfail:0   fail:7   skip:1444 
time:8320s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8229/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Tell vga_switcheroo whether runtime PM is used

[Jani Nikula]

On Mon, 05 Mar 2018, Imre Deak  wrote:
> On Mon, Feb 26, 2018 at 04:57:11PM +0100, Lukas Wunner wrote:
>> On Mon, Feb 26, 2018 at 04:41:09PM +0200, Imre Deak wrote:
>> > On Sun, Feb 25, 2018 at 12:42:30AM +0100, Lukas Wunner wrote:
>> > > DRM drivers need to tell vga_switcheroo whether they use runtime PM.
>> > > If they do use it, vga_switcheroo lets them autosuspend at their own
>> > > discretion.  If on the other hand they do not use it, vga_switcheroo
>> > > allows the user to suspend and resume the GPU manually via the
>> > > ->set_gpu_state hook.
>> > > 
>> > > i915 currently tells vga_switcheroo that it never uses runtime PM, even
>> > > though it does use it on HSW and newer.  The result is that users may
>> > > interfere with the driver's runtime PM on those platforms.  Avoid by
>> > > reporting runtime PM support correctly to vga_switcheroo.
>> > > 
>> > > Cc: Imre Deak 
>> > > Signed-off-by: Lukas Wunner 
>> > 
>> > AFAICS this also needs calling vga_switcheroo_set_dynamic_switch() from
>> > the i915 runtime suspend/resume handlers.
>> 
>> I've posted a series a week ago which removes that call and haven't seen
>> any major objections.  Assuming that series goes into 4.17, there's no
>> point in adding calls to vga_switcheroo_set_dynamic_switch() now:
>> https://lists.freedesktop.org/archives/nouveau/2018-February/029851.html
>
> Ok, read through it and not adding the call to i915 makes sense then.
>
>> 
>> If you have an Optimus/ATPX machine handy, please consider testing the
>> series.
>
> I don't have one.
>
>> > Also after this we can remove i915_switcheroo_set_state() ?
>> 
>> Not yet.  That's still needed for manual power control on chips
>> where you're not supporting runtime PM yet and which are known to
>> be built into hybrid graphics laptops.  (On the MacBook Pro, that's
>> ILK, SNB, IVB, can't speak for non-Macs.)
>
> Err, forgot about the old i915 platforms w/o runtime PM support. So ok,
> I see why we still do need i915_switcheroo_set_state().
>
>> Manual power control was a stopgap according to Dave Airlie that
>> he implemented before he got runtime PM up and running:
>> http://lkml.iu.edu/hypermail/linux/kernel/1603.1/01935.html
>> 
>> It will be removed eventually, but right now it can't because runtime PM
>> on i915 doesn't yet cover all platforms and isn't yet working on muxed
>> laptops such as the MacBook Pro.  (I'm working on fixing the latter,
>> the series I've linked above gets us one step closer.)
>> 
>> 
>> > It's probably worth mentioning in the commit message that this changes
>> > the semantics of the switching: while atm you can't open the the DRM
>> > file for an inactive device (switched off from with IGD/DIS/DIGD/DDIS)
>> > after this change you can. I suppose that's not a problem, it just means
>> > display probing will fail on inactive devices (the same way it's with
>> > MIGD/MDIS currently).
>> 
>> Sorry, I don't understand the last sentence in that paragraph at all.
>
> I meant that before this change if i915 was not the active device (since
> the discrete card was made active for instance by 'echo DIS >
> /sys/kernel/debug/vgaswitcheroo') then trying to open the i915
> /dev/dri/cardX device file failed due to the corresponding check in
> drm_open_helper() and the i915 drm_device::switch_power_state being now
> DRM_SWITCH_POWER_OFF.
>
> After this change if i915 is not active opening the i915 /dev/dri/cardX
> will succeed, since drm_device::switch_power_state will be permanently
> kept at DRM_SWITCH_POWER_ON. But now since the display signals
> (including the DDC and DP AUX pins) could have been switched over to the
> discrete card doing display probing on i915 with
> DRM_IOCTL_MODE_GETCONNECTOR will fail. This is a change in semantics
> that's worth mentioning in the commit message.
>
> I'm not sure how this patch affects the workaround in
> intel_panel_disable_backlight(). Atm during switching we keep the
> backlight enabled since the discrete card depends on this. That won't
> work after this patch, since we won't call i915_switcheroo_set_state
> (except on old platforms) and so won't set
> drm_device::switch_power_state. Not sure what happens even now if i915
> disabled the panel before or after the switcheroo switch to the discrete
> card, but would be good to resolve this issue before your change. Maybe
> i915 would still need a notification about the switch and enable/disable
> the backlight accordingly? Adding Jani.

I guess the reference is 3f577573cd54 ("drm/i915: do not disable
backlight on vgaswitcheroo switch off") which I had happily forgotten
about. Not sure we would've added it like that had it not been a
regression fix way back when.

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 v14 6/6] drm/i915: expose rcs topology through query uAPI

[Joonas Lahtinen]

Quoting Lionel Landwerlin (2018-02-22 19:53:59)
> With the introduction of asymmetric slices in CNL, we cannot rely on
> the previous SUBSLICE_MASK getparam to tell userspace what subslices
> are available. Here we introduce a more detailed way of querying the
> Gen's GPU topology that doesn't aggregate numbers.
> 
> This is essential for monitoring parts of the GPU with the OA unit,
> because counters need to be normalized to the number of
> EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
> not gives us sufficient information.
> 
> As a bonus we can draw representations of the GPU :
> 
> https://imgur.com/a/vuqpa
> 
> v2: Rename uapi struct s/_mask/_info/ (Tvrtko)
> Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko)
> Add uapi macros to read data from *_info structs (Tvrtko)
> 
> v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom shifts 
> (Tvrtko)
> 
> v4: factorize query item writting (Tvrtko)
> tweak uapi struct/define names (Tvrtko)
> 
> v5: Replace ALIGN() macro (Chris)
> 
> v6: Updated uapi comments (Tvrtko)
> Moved flags != 0 checks into vfuncs (Tvrtko)
> 
> v7: Use access_ok() before copying anything, to avoid overflows (Chris)
> Switch BUG_ON() to GEM_WARN_ON() (Tvrtko)
> 
> v8: Tweak uapi comments style to match the coding style (Lionel)
> 
> v9: Fix error in comment about computation of enabled subslice (Tvrtko)
> 
> v10: Fix/update comments in uAPI (Sagar)
> 
> v11: Drop drm_i915_query_(slice|subslice|eu)_info in favor of a single
>  drm_i915_query_topology_info (Joonas)
> 
> v12: Add subslice_stride/eu_stride in drm_i915_query_topology_info (Joonas)
> 
> Signed-off-by: Lionel Landwerlin 
> Acked-by: Chris Wilson 



> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -7,8 +7,90 @@
>  #include "i915_drv.h"
>  #include 
>  
> +static int query_topology_info(struct drm_i915_private *dev_priv,
> +  struct drm_i915_query_item *query_item)
> +{
> +   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
> +   struct drm_i915_query_topology_info topo_info;

Just like sseu is just sseu, topo_info could be topo...

Same goes for query, there's really no confusion within a function.

> +   u32 slice_length, subslice_length, eu_length, total_length;
> +
> +   if (query_item->flags != 0)
> +   return -EINVAL;
> +
> +   if (sseu->max_slices == 0)
> +   return -ENODEV;
> +
> +   /*
> +* If we ever change the internal slice mask data type, we'll need to
> +* update this function.
> +*/

That's pretty self evident from next line, so comment can be thrown away.

> +   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));



> +/*
> + * Data written by the kernel with query DRM_I915_QUERY_TOPOLOGY_INFO :
> + *
> + * data: contains the 3 pieces of information :
> + *
> + * - the slice mask with one bit per slice telling whether a slice is
> + *   available. The availability of slice X can be queried with the following
> + *   formula :
> + *
> + *   (data[X / 8] >> (X % 8)) & 1
> + *
> + * - the subslice mask for each slice with one bit per subslice telling
> + *   whether a subslice is available. The availability of subslice Y in slice
> + *   X can be queried with the following formula :
> + *
> + *   (data[subslice_offset +
> + * X * subslice_stride +
> + * Y / 8] >> (Y % 8)) & 1
> + *
> + * - the EU mask for each subslice in each slice with one bit per EU telling
> + *   whether an EU is available. The availability of EU Z in subslice Y in
> + *   slice X can be queried with the following formula :
> + *
> + *   (data[eu_offset +
> + * (X * max_subslices Y) * eu_stride +

s/Y/+ Y/

> + * Z / 8] >> (Z % 8)) & 1
> + */
> +struct drm_i915_query_topology_info {
> +   /*
> +* Unused for now.

+ "Must be cleared to zero."

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
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/3] drm: Make sure at least one plane supports the fb format

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm: Make sure at least one plane supports 
the fb format
URL   : https://patchwork.freedesktop.org/series/39383/
State : success

== Summary ==

Series 39383v1 series starting with [1/3] drm: Make sure at least one plane 
supports the fb format
https://patchwork.freedesktop.org/api/1.0/series/39383/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:480s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:394s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:492s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:411s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:447s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:453s
fi-kbl-7560u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:420s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:389s

4a3784737699f45784335e1c9446596bf7833606 drm-tip: 2018y-03m-05d-14h-32m-57s UTC 
integration manifest
90f13ce75e41 drm: Fix some coding style issues
91d199eeba2a drm/i915: Eliminate the horrendous format check code
2c14c910a7ca drm: Make sure at least one plane supports the fb format

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8232/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Tell vga_switcheroo whether runtime PM is used

[Imre Deak]

On Mon, Feb 26, 2018 at 04:57:11PM +0100, Lukas Wunner wrote:
> On Mon, Feb 26, 2018 at 04:41:09PM +0200, Imre Deak wrote:
> > On Sun, Feb 25, 2018 at 12:42:30AM +0100, Lukas Wunner wrote:
> > > DRM drivers need to tell vga_switcheroo whether they use runtime PM.
> > > If they do use it, vga_switcheroo lets them autosuspend at their own
> > > discretion.  If on the other hand they do not use it, vga_switcheroo
> > > allows the user to suspend and resume the GPU manually via the
> > > ->set_gpu_state hook.
> > > 
> > > i915 currently tells vga_switcheroo that it never uses runtime PM, even
> > > though it does use it on HSW and newer.  The result is that users may
> > > interfere with the driver's runtime PM on those platforms.  Avoid by
> > > reporting runtime PM support correctly to vga_switcheroo.
> > > 
> > > Cc: Imre Deak 
> > > Signed-off-by: Lukas Wunner 
> > 
> > AFAICS this also needs calling vga_switcheroo_set_dynamic_switch() from
> > the i915 runtime suspend/resume handlers.
> 
> I've posted a series a week ago which removes that call and haven't seen
> any major objections.  Assuming that series goes into 4.17, there's no
> point in adding calls to vga_switcheroo_set_dynamic_switch() now:
> https://lists.freedesktop.org/archives/nouveau/2018-February/029851.html

Ok, read through it and not adding the call to i915 makes sense then.

> 
> If you have an Optimus/ATPX machine handy, please consider testing the
> series.

I don't have one.

> > Also after this we can remove i915_switcheroo_set_state() ?
> 
> Not yet.  That's still needed for manual power control on chips
> where you're not supporting runtime PM yet and which are known to
> be built into hybrid graphics laptops.  (On the MacBook Pro, that's
> ILK, SNB, IVB, can't speak for non-Macs.)

Err, forgot about the old i915 platforms w/o runtime PM support. So ok,
I see why we still do need i915_switcheroo_set_state().

> Manual power control was a stopgap according to Dave Airlie that
> he implemented before he got runtime PM up and running:
> http://lkml.iu.edu/hypermail/linux/kernel/1603.1/01935.html
> 
> It will be removed eventually, but right now it can't because runtime PM
> on i915 doesn't yet cover all platforms and isn't yet working on muxed
> laptops such as the MacBook Pro.  (I'm working on fixing the latter,
> the series I've linked above gets us one step closer.)
> 
> 
> > It's probably worth mentioning in the commit message that this changes
> > the semantics of the switching: while atm you can't open the the DRM
> > file for an inactive device (switched off from with IGD/DIS/DIGD/DDIS)
> > after this change you can. I suppose that's not a problem, it just means
> > display probing will fail on inactive devices (the same way it's with
> > MIGD/MDIS currently).
> 
> Sorry, I don't understand the last sentence in that paragraph at all.

I meant that before this change if i915 was not the active device (since
the discrete card was made active for instance by 'echo DIS >
/sys/kernel/debug/vgaswitcheroo') then trying to open the i915
/dev/dri/cardX device file failed due to the corresponding check in
drm_open_helper() and the i915 drm_device::switch_power_state being now
DRM_SWITCH_POWER_OFF.

After this change if i915 is not active opening the i915 /dev/dri/cardX
will succeed, since drm_device::switch_power_state will be permanently
kept at DRM_SWITCH_POWER_ON. But now since the display signals
(including the DDC and DP AUX pins) could have been switched over to the
discrete card doing display probing on i915 with
DRM_IOCTL_MODE_GETCONNECTOR will fail. This is a change in semantics
that's worth mentioning in the commit message.

I'm not sure how this patch affects the workaround in
intel_panel_disable_backlight(). Atm during switching we keep the
backlight enabled since the discrete card depends on this. That won't
work after this patch, since we won't call i915_switcheroo_set_state
(except on old platforms) and so won't set
drm_device::switch_power_state. Not sure what happens even now if i915
disabled the panel before or after the switcheroo switch to the discrete
card, but would be good to resolve this issue before your change. Maybe
i915 would still need a notification about the switch and enable/disable
the backlight accordingly? Adding Jani.

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Assert that the request is indeed complete when signaled from irq

[Patchwork]

== Series Details ==

Series: drm/i915: Assert that the request is indeed complete when signaled from 
irq
URL   : https://patchwork.freedesktop.org/series/39369/
State : success

== Summary ==

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +1
Subgroup pipe-c-128x128-bottom-edge:
pass   -> FAIL   (shard-apl) fdo#104671
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#103167
Subgroup fbc-suspend:
skip   -> PASS   (shard-hsw) fdo#103540
Test kms_vblank:
Subgroup pipe-b-ts-continuation-dpms-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#105054
Subgroup pipe-c-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#105054 https://bugs.freedesktop.org/show_bug.cgi?id=105054
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583

shard-apltotal:3452 pass:1813 dwarn:1   dfail:0   fail:8   skip:1629 
time:11714s
shard-hswtotal:3417 pass:1745 dwarn:1   dfail:0   fail:3   skip:1666 
time:11409s
shard-snbtotal:3468 pass:1365 dwarn:1   dfail:0   fail:1   skip:2101 
time:7115s
Blacklisted hosts:
shard-kbltotal:3270 pass:1810 dwarn:33  dfail:0   fail:7   skip:1416 
time:8184s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8228/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path

[Patchwork]

== Series Details ==

Series: drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path
URL   : https://patchwork.freedesktop.org/series/39367/
State : success

== Summary ==

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +1
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#103167
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3452 pass:1813 dwarn:1   dfail:0   fail:7   skip:1629 
time:11782s
shard-hswtotal:3468 pass:1772 dwarn:1   dfail:0   fail:2   skip:1692 
time:11698s
shard-snbtotal:3468 pass:1365 dwarn:1   dfail:0   fail:1   skip:2101 
time:7106s
Blacklisted hosts:
shard-kbltotal:3371 pass:1899 dwarn:1   dfail:0   fail:7   skip:1462 
time:8660s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8227/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v14 5/6] drm/i915: add query uAPI

[Lionel Landwerlin]

On 05/03/18 14:54, Joonas Lahtinen wrote:

Quoting Lionel Landwerlin (2018-02-22 19:53:58)

There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die recovery).

At the moment the GET_PARAM ioctl covers some basic needs, but
generally is only able to return a single value for each defined
parameter. This is a bit problematic with topology descriptions which
are array/maps of available units.

This change introduces a new ioctl that can deal with requests to fill
structures of potentially variable lengths. The user is expected fill
a query with length fields set at 0 on the first call, the kernel then
sets the length fields to the their expected values. A second call to
the kernel with length fields at their expected values will trigger a
copy of the data to the pointed memory locations.

The scope of this uAPI is only to provide information to userspace,
not to allow configuration of the device.

v2: Simplify dispatcher code iteration (Tvrtko)
 Tweak uapi drm_i915_query_item structure (Tvrtko)

v3: Rename pad fields into flags (Chris)
 Return error on flags field != 0 (Chris)
 Only copy length back to userspace in drm_i915_query_item (Chris)

v4: Use array of functions instead of switch (Chris)

v5: More comments in uapi (Tvrtko)
 Return query item errors in length field (All)

v6: Tweak uapi comments style to match the coding style (Lionel)

v7: Add i915_query.h (Joonas)

v8: (Lionel) Change the behavior of the item iterator to report
 invalid queries into the query item rather than stopping the
 iteration. This enables userspace applications to query newer
 items on older kernels and only have failure on the items that are
 not supported.

v9: Edit copyright headers (Joonas)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
Acked-by: Chris Wilson 




@@ -1615,6 +1617,44 @@ struct drm_i915_perf_oa_config {
 __u64 flex_regs_ptr;
  };
  
+struct drm_i915_query_item {

+   __u64 query_id;
+
+   /*
+* When set to zero by userspace, this is filled with the size of the
+* data to be written at the data_ptr pointer. The kernel set this

"sets"


+* value to a negative value to signal an error on a particular query
+* item.
+*/
+   __s32 length;
+
+   /*
+* Unused for now.

"now. Must be cleared to zero."


+*/
+   __u32 flags;
+
+   /*
+* Data will be written at the location pointed by data_ptr when the
+* value of length matches the length of the data to be written by the
+* kernel.
+*/
+   __u64 data_ptr;
+};
+
+struct drm_i915_query {
+   __u32 num_items;
+
+   /*
+* Unused for now.

Ditto.


+*/
+   __u32 flags;
+
+   /*
+* This point to an array of num_items drm_i915_query_item structures.

"points"

Reviewed-by: Joonas Lahtinen 

Lets wait for the Mesa patch review still before merging.

Regards, Joonas


Thanks, applied locally.

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

Re: [Intel-gfx] [PATCH v14 5/6] drm/i915: add query uAPI

[Joonas Lahtinen]

Quoting Lionel Landwerlin (2018-02-22 19:53:58)
> There are a number of information that are readable from hardware
> registers and that we would like to make accessible to userspace. One
> particular example is the topology of the execution units (how are
> execution units grouped in subslices and slices and also which ones
> have been fused off for die recovery).
> 
> At the moment the GET_PARAM ioctl covers some basic needs, but
> generally is only able to return a single value for each defined
> parameter. This is a bit problematic with topology descriptions which
> are array/maps of available units.
> 
> This change introduces a new ioctl that can deal with requests to fill
> structures of potentially variable lengths. The user is expected fill
> a query with length fields set at 0 on the first call, the kernel then
> sets the length fields to the their expected values. A second call to
> the kernel with length fields at their expected values will trigger a
> copy of the data to the pointed memory locations.
> 
> The scope of this uAPI is only to provide information to userspace,
> not to allow configuration of the device.
> 
> v2: Simplify dispatcher code iteration (Tvrtko)
> Tweak uapi drm_i915_query_item structure (Tvrtko)
> 
> v3: Rename pad fields into flags (Chris)
> Return error on flags field != 0 (Chris)
> Only copy length back to userspace in drm_i915_query_item (Chris)
> 
> v4: Use array of functions instead of switch (Chris)
> 
> v5: More comments in uapi (Tvrtko)
> Return query item errors in length field (All)
> 
> v6: Tweak uapi comments style to match the coding style (Lionel)
> 
> v7: Add i915_query.h (Joonas)
> 
> v8: (Lionel) Change the behavior of the item iterator to report
> invalid queries into the query item rather than stopping the
> iteration. This enables userspace applications to query newer
> items on older kernels and only have failure on the items that are
> not supported.
> 
> v9: Edit copyright headers (Joonas)
> 
> Signed-off-by: Lionel Landwerlin 
> Reviewed-by: Tvrtko Ursulin 
> Acked-by: Chris Wilson 



> @@ -1615,6 +1617,44 @@ struct drm_i915_perf_oa_config {
> __u64 flex_regs_ptr;
>  };
>  
> +struct drm_i915_query_item {
> +   __u64 query_id;
> +
> +   /*
> +* When set to zero by userspace, this is filled with the size of the
> +* data to be written at the data_ptr pointer. The kernel set this

"sets"

> +* value to a negative value to signal an error on a particular query
> +* item.
> +*/
> +   __s32 length;
> +
> +   /*
> +* Unused for now.

"now. Must be cleared to zero."

> +*/
> +   __u32 flags;
> +
> +   /*
> +* Data will be written at the location pointed by data_ptr when the
> +* value of length matches the length of the data to be written by the
> +* kernel.
> +*/
> +   __u64 data_ptr;
> +};
> +
> +struct drm_i915_query {
> +   __u32 num_items;
> +
> +   /*
> +* Unused for now.

Ditto.

> +*/
> +   __u32 flags;
> +
> +   /*
> +* This point to an array of num_items drm_i915_query_item structures.

"points"

Reviewed-by: Joonas Lahtinen 

Lets wait for the Mesa patch review still before merging.

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/2] drm/i915/uc: Start preparing GuC/HuC for reset

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915/uc: Start preparing GuC/HuC for 
reset
URL   : https://patchwork.freedesktop.org/series/39381/
State : failure

== Summary ==

Series 39381v1 series starting with [v3,1/2] drm/i915/uc: Start preparing 
GuC/HuC for reset
https://patchwork.freedesktop.org/api/1.0/series/39381/revisions/1/mbox/

 Possible new issues:

Test core_auth:
Subgroup basic-auth:
pass   -> INCOMPLETE (fi-bdw-5557u)
pass   -> INCOMPLETE (fi-bdw-gvtdvm)
pass   -> INCOMPLETE (fi-bsw-n3050)
pass   -> INCOMPLETE (fi-bxt-dsi)
pass   -> INCOMPLETE (fi-byt-j1900)
pass   -> INCOMPLETE (fi-byt-n2820)
pass   -> INCOMPLETE (fi-cfl-8700k)
pass   -> INCOMPLETE (fi-cfl-s2)
pass   -> INCOMPLETE (fi-cnl-y3)
pass   -> INCOMPLETE (fi-glk-1)
pass   -> INCOMPLETE (fi-hsw-4770)
pass   -> INCOMPLETE (fi-ilk-650)
pass   -> INCOMPLETE (fi-ivb-3520m)
pass   -> INCOMPLETE (fi-ivb-3770)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-kbl-7560u)
pass   -> INCOMPLETE (fi-kbl-7567u)
pass   -> INCOMPLETE (fi-kbl-r)
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-skl-6600u)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-skl-6700k2)
pass   -> INCOMPLETE (fi-skl-6770hq)
pass   -> INCOMPLETE (fi-skl-gvtdvm)
pass   -> INCOMPLETE (fi-snb-2520m)
pass   -> INCOMPLETE (fi-snb-2600)

fi-bdw-5557u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-bdw-gvtdvmtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-byt-j1900 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-byt-n2820 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-cfl-8700k total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-cfl-s2total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-cnl-y3total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:294s
fi-glk-1 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-hsw-4770  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ilk-650   total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ivb-3520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ivb-3770  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7500u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7560u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7567u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-r total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6600u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6700hqtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6700k2total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6770hqtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-skl-gvtdvmtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  

276a88800a08604e3f617f084f59aeef75d5a01a drm-tip: 2018y-03m-05d-12h-15m-50s UTC 
integration manifest
dd0e68d34742 HAX: Enable GuC for CI
b963c685ed40 drm/i915/uc: Start preparing GuC/HuC for reset

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8231/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm: Fix some coding style issues

[Ville Syrjala]

From: Ville Syrjälä 

Put an empty line between the variable declarations and the code, and
use tabs for alignment.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 155b21e579c4..6aa86a6549a0 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -179,9 +179,10 @@ static int framebuffer_check(struct drm_device *dev,
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
+
DRM_DEBUG_KMS("bad framebuffer format %s\n",
- drm_get_format_name(r->pixel_format,
- _name));
+ drm_get_format_name(r->pixel_format,
+ _name));
return -EINVAL;
}
 
-- 
2.16.1

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

[Intel-gfx] [PATCH 2/3] drm/i915: Eliminate the horrendous format check code

[Ville Syrjala]

From: Ville Syrjälä 

Now that the core makes sure that the pixel format is supported
by at least one plane, we can eliminate the hand rolled code for the
same thing in i915. The way we were doing was extremely inconvenient
because not only did you have to add the format to the plane's format
list, but you also had to come up with the correct platform checks
for this code.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 55 
 1 file changed, 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb08590b4d40..9b03d50d2d53 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13991,7 +13991,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = _fb->base;
-   struct drm_format_name_buf format_name;
u32 pitch_limit;
unsigned int tiling, stride;
int ret = -EINVAL;
@@ -14083,60 +14082,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
 
-   /* Reject formats not supported by any plane early. */
-   switch (mode_cmd->pixel_format) {
-   case DRM_FORMAT_C8:
-   case DRM_FORMAT_RGB565:
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
-   break;
-   case DRM_FORMAT_XRGB1555:
-   if (INTEL_GEN(dev_priv) > 3) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
-   INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_XRGB2101010:
-   case DRM_FORMAT_XBGR2101010:
-   if (INTEL_GEN(dev_priv) < 4) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR2101010:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_YUYV:
-   case DRM_FORMAT_UYVY:
-   case DRM_FORMAT_YVYU:
-   case DRM_FORMAT_VYUY:
-   if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   default:
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   goto err;
-   }
-
/* FIXME need to adjust LINOFF/TILEOFF accordingly. */
if (mode_cmd->offsets[0] != 0)
goto err;
-- 
2.16.1

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

[Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjala]

From: Ville Syrjälä 

To make life easier for drivers, let's have the core check that the
requested pixel format is supported by at least one plane when creating
a new framebuffer.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index c0530a1af5e3..155b21e579c4 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -152,6 +152,23 @@ static int fb_plane_height(int height,
return DIV_ROUND_UP(height, format->vsub);
 }
 
+static bool planes_have_format(struct drm_device *dev, u32 format)
+{
+   struct drm_plane *plane;
+
+   /* TODO: maybe maintain a device level format list? */
+   drm_for_each_plane(plane, dev) {
+   int i;
+
+   for (i = 0; i < plane->format_count; i++) {
+   if (plane->format_types[i] == format)
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int framebuffer_check(struct drm_device *dev,
 const struct drm_mode_fb_cmd2 *r)
 {
@@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
 
+   if (!planes_have_format(dev, r->pixel_format)) {
+   struct drm_format_name_buf format_name;
+
+   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
+ drm_get_format_name(r->pixel_format,
+ _name));
+   return -EINVAL;
+   }
+
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
 
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/uc: Start preparing GuC/HuC for reset

[Chris Wilson]

Quoting Michal Wajdeczko (2018-03-05 14:29:16)
> Right after GPU reset there will be a small window of time during which
> some of GuC/HuC fields will still show state before reset. Let's start
> to fix that by sanitizing firmware status as we will use it shortly.
> 
> v2: s/reset_prepare/prepare_to_reset (Michel)
> don't forget about gem_sanitize path (Daniele)
> v3: rebased
> 
> Suggested-by: Daniele Ceraolo Spurio 
> Signed-off-by: Michal Wajdeczko 
> Cc: Daniele Ceraolo Spurio 
> Cc: Sagar Arun Kamble 
> Cc: Chris Wilson 
> Cc: Michel Thierry 
> Reviewed-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/i915_gem.c|  5 -
>  drivers/gpu/drm/i915/intel_guc.h   |  5 +
>  drivers/gpu/drm/i915/intel_huc.h   |  5 +
>  drivers/gpu/drm/i915/intel_uc.c| 14 ++
>  drivers/gpu/drm/i915/intel_uc.h|  1 +
>  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
>  6 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a5bd073..aedb17d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct drm_i915_private 
> *dev_priv)
> }
>  
> i915_gem_revoke_fences(dev_priv);
> +   intel_uc_prepare_to_reset(dev_priv);
>  
> return err;
>  }
> @@ -4882,8 +4883,10 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
>  * it may impact the display and we are uncertain about the stability
>  * of the reset, so this could be applied to even earlier gen.
>  */
> -   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
> +   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) {
> +   intel_uc_prepare_to_reset(i915);
> WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));

This still feels wrong. If we accept that we will have to reload the fw
on resume, why are we not just sanitzing the uc state and forcing the
reload?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt 01/16] igt/gem_sync: Exercise and measure idle requests

[Chris Wilson]

Quoting Joonas Lahtinen (2018-03-05 13:43:33)
> For some reason, I've reviewed these from the middle of the series
> (maybe transport delay?). Are the rest still applicable or refreshed
> somewhere?

Virtually all, baring a couple have landed. The current unreviewed pile
now has 7 patches, so in the meantime another 5 have been added...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2 03/14] lib/igt_kms: Rework pipe properties to be more atomic, v7.

[Maxime Ripard]

Hi,

On Thu, Oct 12, 2017 at 01:54:24PM +0200, Maarten Lankhorst wrote:
> In the future I want to allow tests to commit more properties,
> but for this to work I have to fix all properties to work better
> with atomic commit. Instead of special casing each
> property make a bitmask for all property changed flags, and try to
> commit all properties.
> 
> This has been the most involved one, since legacy pipe commit still
> handles a lot of the properties differently from the rest.
> 
> Changes since v1:
> - Dump all changed properties on commit.
> - Fix bug in igt_pipe_refresh().
> Changes since v2:
> - Set pipe ACTIVE property changed flag on init.
> Changes since v3:
> - Add a missing igt_pipe_refresh() to kms_atomic_interruptible.
> Changes since v4:
> - Perform error handling when setting custom crtc properties.
> Changes since v5:
> - Only attempt to commit changes properties.
> Changes since v6:
> - Clear OUT_FENCE_PTR on succesful commit.
> 
> Signed-off-by: Maarten Lankhorst 

I'm a bit late to the party on this one, but this commit broke the
chamelium tests on vc4, with every kernel since at least 4.12.

This is the error message:
http://code.bulix.org/32fw1l-293842

From the stack trace, it looks like the atomic commit was failing, and
indeed it fails here:
https://elixir.bootlin.com/linux/v4.16-rc4/source/drivers/gpu/drm/drm_atomic.c#L2319

with prop_id being 0 for some reason.

I had a look at that patch, but I can't see anything wrong with it. Do
you have any ideas?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

[Chris Wilson]

Quoting Chris Wilson (2018-03-05 14:34:42)
> Quoting Mika Kuoppala (2018-03-05 13:59:43)
> > Chris Wilson  writes:
> > 
> > > Similar to the staging around handling of engine->submit_request, we
> > > need to stop adding to the execlists->queue prior to calling
> > > engine->cancel_requests. cancel_requests will move requests from the
> > > queue onto the timeline, so if we add a request onto the queue after that
> > > point, it will be lost.
> > >
> > > Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in 
> > > set_wedged")
> > > Signed-off-by: Chris Wilson 
> > > Cc: Mika Kuoppala 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem.c | 13 +++--
> > >  drivers/gpu/drm/i915/i915_request.c |  2 ++
> > >  2 files changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index a5bd07338b46..8d913d833ab9 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -471,10 +471,11 @@ static void __fence_set_priority(struct dma_fence 
> > > *fence, int prio)
> > >  
> > >   rq = to_request(fence);
> > >   engine = rq->engine;
> > > - if (!engine->schedule)
> > > - return;
> > >  
> > > - engine->schedule(rq, prio);
> > > + rcu_read_lock();
> > > + if (engine->schedule)
> > > + engine->schedule(rq, prio);
> > > + rcu_read_unlock();
> > >  }
> > >  
> > >  static void fence_set_priority(struct dma_fence *fence, int prio)
> > > @@ -3214,8 +3215,11 @@ void i915_gem_set_wedged(struct drm_i915_private 
> > > *i915)
> > >*/
> > >   for_each_engine(engine, i915, id) {
> > >   i915_gem_reset_prepare_engine(engine);
> > > +
> > >   engine->submit_request = nop_submit_request;
> > > + engine->schedule = NULL;
> > 
> > Why we are not using rcu_assign_pointer and rcu_deference pair
> > in the upper part where we check the schedule?
> 
> We are not using RCU protection. RCU here is being abused as a
> free-flowing stop-machine.

I'm sorely tempted to put it back to stop_machine as the races are just
plain weird and proving hard to fix :(
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

[Chris Wilson]

Quoting Mika Kuoppala (2018-03-05 13:59:43)
> Chris Wilson  writes:
> 
> > Similar to the staging around handling of engine->submit_request, we
> > need to stop adding to the execlists->queue prior to calling
> > engine->cancel_requests. cancel_requests will move requests from the
> > queue onto the timeline, so if we add a request onto the queue after that
> > point, it will be lost.
> >
> > Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in 
> > set_wedged")
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 13 +++--
> >  drivers/gpu/drm/i915/i915_request.c |  2 ++
> >  2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index a5bd07338b46..8d913d833ab9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -471,10 +471,11 @@ static void __fence_set_priority(struct dma_fence 
> > *fence, int prio)
> >  
> >   rq = to_request(fence);
> >   engine = rq->engine;
> > - if (!engine->schedule)
> > - return;
> >  
> > - engine->schedule(rq, prio);
> > + rcu_read_lock();
> > + if (engine->schedule)
> > + engine->schedule(rq, prio);
> > + rcu_read_unlock();
> >  }
> >  
> >  static void fence_set_priority(struct dma_fence *fence, int prio)
> > @@ -3214,8 +3215,11 @@ void i915_gem_set_wedged(struct drm_i915_private 
> > *i915)
> >*/
> >   for_each_engine(engine, i915, id) {
> >   i915_gem_reset_prepare_engine(engine);
> > +
> >   engine->submit_request = nop_submit_request;
> > + engine->schedule = NULL;
> 
> Why we are not using rcu_assign_pointer and rcu_deference pair
> in the upper part where we check the schedule?

We are not using RCU protection. RCU here is being abused as a
free-flowing stop-machine.
 
> Further, is there are risk that we lose sync between the two
> assigments. In another words, should we combine both callbaks
> behind a single deferensable pointer in the engine struct?

They are only tied together by how the backend uses them, not by request
flow, so I don't think so.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/2] HAX: Enable GuC for CI

[Michal Wajdeczko]

v2: except running with HYPERVISOR

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 8a64ff5..aaaeb61 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 1/2] drm/i915/uc: Start preparing GuC/HuC for reset

[Michal Wajdeczko]

Right after GPU reset there will be a small window of time during which
some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will use it shortly.

v2: s/reset_prepare/prepare_to_reset (Michel)
don't forget about gem_sanitize path (Daniele)
v3: rebased

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gem.c|  5 -
 drivers/gpu/drm/i915/intel_guc.h   |  5 +
 drivers/gpu/drm/i915/intel_huc.h   |  5 +
 drivers/gpu/drm/i915/intel_uc.c| 14 ++
 drivers/gpu/drm/i915/intel_uc.h|  1 +
 drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
 6 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a5bd073..aedb17d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
}
 
i915_gem_revoke_fences(dev_priv);
+   intel_uc_prepare_to_reset(dev_priv);
 
return err;
 }
@@ -4882,8 +4883,10 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 * it may impact the display and we are uncertain about the stability
 * of the reset, so this could be applied to even earlier gen.
 */
-   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
+   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) {
+   intel_uc_prepare_to_reset(i915);
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+   }
 }
 
 int i915_gem_suspend(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424ac..bdb0777 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,9 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
 u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
 
+static inline void intel_guc_prepare_to_reset(struct intel_guc *guc)
+{
+   intel_uc_fw_prepare_to_reset(>fw);
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 5d6e804..6f21424 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,9 @@ struct intel_huc {
 void intel_huc_init_early(struct intel_huc *huc);
 int intel_huc_auth(struct intel_huc *huc);
 
+static inline void intel_huc_prepare_to_reset(struct intel_huc *huc)
+{
+   intel_uc_fw_prepare_to_reset(>fw);
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index e5bf0d3..8a64ff5 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -490,3 +490,17 @@ int intel_uc_resume(struct drm_i915_private *i915)
 
return 0;
 }
+
+void intel_uc_prepare_to_reset(struct drm_i915_private *i915)
+{
+   struct intel_huc *huc = >huc;
+   struct intel_guc *guc = >guc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   intel_huc_prepare_to_reset(huc);
+   intel_guc_prepare_to_reset(guc);
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index f76d51d..182a2de 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -41,6 +41,7 @@
 void intel_uc_fini(struct drm_i915_private *dev_priv);
 int intel_uc_suspend(struct drm_i915_private *dev_priv);
 int intel_uc_resume(struct drm_i915_private *dev_priv);
+void intel_uc_prepare_to_reset(struct drm_i915_private *dev_priv);
 
 static inline bool intel_uc_is_using_guc(void)
 {
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..f1ee653 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
 }
 
+static inline void intel_uc_fw_prepare_to_reset(struct intel_uc_fw *uc_fw)
+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
 void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   struct intel_uc_fw *uc_fw);
 int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Extend partial vma coverage to check parallel creation

[Joonas Lahtinen]

+ Abdiel

Quoting Chris Wilson (2018-02-22 11:48:40)
> Quoting Chris Wilson (2018-01-16 10:11:43)
> > One important use of partial vma is to provide mappable access to the
> > object while it is being used elsewhere (pinned entirely into the
> > unmappable portion of the Global GTT, i.e. for use as a display scanout).
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> 
> Hi Joonas, you made a request for this selftest once upon a time.
> -Chris
> 
> > ---
> >  drivers/gpu/drm/i915/selftests/i915_vma.c | 59 
> > +++
> >  1 file changed, 52 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c 
> > b/drivers/gpu/drm/i915/selftests/i915_vma.c
> > index eb89e301b602..ea48bac16927 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
> > @@ -606,11 +606,17 @@ static int igt_vma_partial(void *arg)
> > struct drm_i915_private *i915 = arg;
> > struct i915_address_space *vm = >ggtt.base;
> > const unsigned int npages = 1021; /* prime! */
> > -   struct drm_i915_gem_object *obj;
> > +   struct drm_i915_gem_object *obj = NULL;
> > const struct phase {
> > const char *name;
> > +   unsigned int flags;
> > +#define CREATE BIT(0)
> > +#define WHOLE  BIT(1)
> > } phases[] = {
> > -   { "create" },
> > +   { "create", CREATE },
> > +   { "lookup" },
> > +   { "whole", WHOLE },
> > +   { "recreate", CREATE | WHOLE },
> > { "lookup" },
> > { },
> > }, *p;
> > @@ -618,17 +624,44 @@ static int igt_vma_partial(void *arg)
> > struct i915_vma *vma;
> > int err = -ENOMEM;
> >  
> > -   /* Create lots of different VMA for the object and check that
> > +   /*
> > +* Create lots of different VMA for the object and check that
> >  * we are returned the same VMA when we later request the same 
> > range.
> >  */
> >  
> > -   obj = i915_gem_object_create_internal(i915, npages*PAGE_SIZE);
> > -   if (IS_ERR(obj))
> > -   goto out;
> > -
> > for (p = phases; p->name; p++) { /* exercise both create/lookup */
> > unsigned int count, nvma;
> >  
> > +   if (p->flags & CREATE) {
> > +   if (obj)
> > +   i915_gem_object_put(obj);
> > +
> > +   obj = i915_gem_object_create_internal(i915,
> > + 
> > npages*PAGE_SIZE);
> > +   if (IS_ERR(obj))
> > +   goto out;
> > +   }
> > +
> > +   if (p->flags & WHOLE) {
> > +   /*
> > +* Make sure we can create mappable partial vma
> > +* while the whole object is in use elsewhere.
> > +*/
> > +   vma = i915_vma_instance(obj, vm, NULL);
> > +   if (IS_ERR(vma)) {
> > +   err = PTR_ERR(vma);
> > +   goto out_object;
> > +   }
> > +
> > +   err = i915_vma_unbind(vma);
> > +   if (err)
> > +   goto out_object;
> > +
> > +   err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | 
> > PIN_HIGH);
> > +   if (err)
> > +   goto out_object;
> > +   }
> > +
> > nvma = 0;
> > for_each_prime_number_from(sz, 1, npages) {
> > for_each_prime_number_from(offset, 0, npages - sz) {
> > @@ -707,12 +740,24 @@ static int igt_vma_partial(void *arg)
> > err = -EINVAL;
> > goto out_object;
> > }
> > +
> > +   if (p->flags & WHOLE) {
> > +   vma = i915_vma_instance(obj, vm, NULL);
> > +   if (IS_ERR(vma)) {
> > +   err = PTR_ERR(vma);
> > +   goto out_object;
> > +   }
> > +
> > +   i915_vma_unpin(vma);
> > +   }
> > }
> >  
> >  out_object:
> > i915_gem_object_put(obj);
> >  out:
> > return err;
> > +#undef CREATE
> > +#undef WHOLE
> >  }
> >  
> >  int i915_vma_mock_selftests(void)
> > -- 
> > 2.15.1
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/breadcrumbs: Assert all missed breadcrumbs were signaled

[Joonas Lahtinen]

Quoting Chris Wilson (2018-02-22 11:25:45)
> When parking the engines and their breadcrumbs, if we have waiters left
> then they missed their wakeup. Verify that each waiter's seqno did
> complete.
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/breadcrumbs: Reduce signaler rbtree to a sorted list

[Joonas Lahtinen]

Quoting Chris Wilson (2018-02-22 11:25:44)
> The goal here is to try and reduce the latency of signaling additional
> requests following the wakeup from interrupt by reducing the list of
> to-be-signaled requests from an rbtree to a sorted linked list. The
> original choice of using an rbtree was to facilitate random insertions
> of request into the signaler while maintaining a sorted list. However,
> if we assume that most new requests are added when they are submitted,
> we see those new requests in execution order making a insertion sort
> fast, and the reduction in overhead of each signaler iteration
> significant.
> 
> Since commit 56299fb7d904 ("drm/i915: Signal first fence from irq handler
> if complete"), we signal most fences directly from notify_ring() in the
> interrupt handler greatly reducing the amount of work that actually
> needs to be done by the signaler kthread. All the thread is then
> required to do is operate as the bottom-half, cleaning up after the
> interrupt handler and preparing the next waiter. This includes signaling
> all later completed fences in a saturated system, but on a mostly idle
> system we only have to rebuild the wait rbtree in time for the next
> interrupt. With this de-emphasis of the signaler's role, we want to
> rejig it's datastructures to reduce the amount of work we require to
> both setup the signal tree and maintain it on every interrupt.
> 
> References: 56299fb7d904 ("drm/i915: Signal first fence from irq handler if 
> complete")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> Cc: Joonas Lahtinen 

"rb_lock" is now bit of a misleading name. We could generally improve a
lot on documenting which locks apply to which data.

As a pre-existing condition it's bit surprising that intel_breadcrumbs_busy()
kicks the signaler as a side-effect.

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] [RFC PATCH i-g-t 3/3] tests: Add vc4 test suite

[Maxime Ripard]

Add some various test suites relevant for the vc4 drm driver.

Signed-off-by: Maxime Ripard 
---
 tests/vc4_ci/vc4-chamelium-fast.testlist |  4 
 tests/vc4_ci/vc4-chamelium.testlist  |  9 
 tests/vc4_ci/vc4.testlist| 35 
 3 files changed, 48 insertions(+)
 create mode 100644 tests/vc4_ci/vc4-chamelium-fast.testlist
 create mode 100644 tests/vc4_ci/vc4-chamelium.testlist
 create mode 100644 tests/vc4_ci/vc4.testlist

diff --git a/tests/vc4_ci/vc4-chamelium-fast.testlist 
b/tests/vc4_ci/vc4-chamelium-fast.testlist
new file mode 100644
index ..964167b82d00
--- /dev/null
+++ b/tests/vc4_ci/vc4-chamelium-fast.testlist
@@ -0,0 +1,4 @@
+igt@kms_chamelium@hdmi-crc-fast
+igt@kms_chamelium@hdmi-edid-read
+igt@kms_chamelium@hdmi-hpd
+igt@kms_chamelium@hdmi-hpd-fast
diff --git a/tests/vc4_ci/vc4-chamelium.testlist 
b/tests/vc4_ci/vc4-chamelium.testlist
new file mode 100644
index ..2651d03b6ceb
--- /dev/null
+++ b/tests/vc4_ci/vc4-chamelium.testlist
@@ -0,0 +1,9 @@
+igt@kms_chamelium@hdmi-crc-single
+igt@kms_chamelium@hdmi-crc-multiple
+igt@kms_chamelium@hdmi-frame-dump
+igt@kms_chamelium@hdmi-hpd-storm
+igt@kms_chamelium@hdmi-hpd-storm-disable
+igt@kms_chamelium@hdmi-crc-fast
+igt@kms_chamelium@hdmi-edid-read
+igt@kms_chamelium@hdmi-hpd
+igt@kms_chamelium@hdmi-hpd-fast
diff --git a/tests/vc4_ci/vc4.testlist b/tests/vc4_ci/vc4.testlist
new file mode 100644
index ..e86d4c815c56
--- /dev/null
+++ b/tests/vc4_ci/vc4.testlist
@@ -0,0 +1,35 @@
+igt@vc4_create_bo@create-bo-0
+igt@vc4_create_bo@create-bo-4096
+igt@vc4_create_bo@create-bo-zeroed
+igt@vc4_dmabuf_poll@poll-read-waits-until-write-done
+igt@vc4_dmabuf_poll@poll-write-waits-until-write-done
+igt@vc4_label_bo@set-label
+igt@vc4_label_bo@set-bad-handle
+igt@vc4_label_bo@set-bad-name
+igt@vc4_label_bo@set-kernel-name
+igt@vc4_lookup_fail@bad-color-write
+igt@vc4_purgeable_bo@mark-willneed
+igt@vc4_purgeable_bo@mark-purgeable
+igt@vc4_purgeable_bo@mark-purgeable-twice
+igt@vc4_purgeable_bo@access-purgeable-bo-mem
+igt@vc4_purgeable_bo@access-purged-bo-mem
+igt@vc4_purgeable_bo@mark-unpurgeable-check-retained
+igt@vc4_purgeable_bo@mark-unpurgeable-purged
+igt@vc4_purgeable_bo@free-purged-bo
+igt@vc4_tiling@get-bad-handle
+igt@vc4_tiling@set-bad-handle
+igt@vc4_tiling@get-bad-flags
+igt@vc4_tiling@set-bad-flags
+igt@vc4_tiling@get-bad-modifier
+igt@vc4_tiling@set-bad-modifier
+igt@vc4_tiling@set-get
+igt@vc4_tiling@get-after-free
+igt@vc4_wait_bo@bad-bo
+igt@vc4_wait_bo@bad-pad
+igt@vc4_wait_bo@unused-bo-0ns
+igt@vc4_wait_bo@unused-bo-1ns
+igt@vc4_wait_bo@used-bo
+igt@vc4_wait_bo@used-bo-0ns
+igt@vc4_wait_bo@used-bo-1ns
+igt@vc4_wait_seqno@bad-seqno-0ns
+igt@vc4_wait_seqno@bad-seqno-1ns
-- 
2.14.3

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

[Intel-gfx] [RFC PATCH i-g-t 2/3] tests/chamelium: Add test case for plane formats

[Maxime Ripard]

KMS can support a lot of different plane formats that are not being tested
by the current chamelium tests.

Add some preliminary tests to exert the RGB formats exposed by the KMS
planes.

Signed-off-by: Maxime Ripard 
---
 tests/Makefile.am |   1 +
 tests/Makefile.sources|   5 +
 tests/kms_chamelium_formats.c | 305 ++
 tests/meson.build |   1 +
 4 files changed, 312 insertions(+)
 create mode 100644 tests/kms_chamelium_formats.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8472a6bf0a73..becc23de895b 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -17,6 +17,7 @@ endif
 if HAVE_CHAMELIUM
 TESTS_progs += \
kms_chamelium \
+   kms_chamelium_formats \
$(NULL)
 endif
 
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c27226fc96c9..8476b63a245c 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -280,6 +280,11 @@ kms_chamelium_SOURCES = \
helpers_chamelium.h \
helpers_chamelium.c
 
+kms_chamelium_formats_SOURCES = \
+   kms_chamelium_formats.c \
+   helpers_chamelium.h \
+   helpers_chamelium.c
+
 testdisplay_SOURCES = \
testdisplay.c \
testdisplay.h \
diff --git a/tests/kms_chamelium_formats.c b/tests/kms_chamelium_formats.c
new file mode 100644
index ..6d61f2fa34d8
--- /dev/null
+++ b/tests/kms_chamelium_formats.c
@@ -0,0 +1,305 @@
+/*
+ * Copyright © 2016 Red Hat Inc.
+ *
+ * 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.
+ *
+ * Authors:
+ *Lyude Paul 
+ */
+
+#include "config.h"
+#include "helpers_chamelium.h"
+#include "igt.h"
+
+#include 
+#include 
+#include 
+
+struct formats {
+   uint32_tdrm_fmt;
+   pixman_format_code_tpixman_fmt;
+} formats_map[] = {
+   { DRM_FORMAT_XRGB, PIXMAN_x8r8g8b8 },
+   { DRM_FORMAT_ARGB, PIXMAN_a8r8g8b8 },
+   { DRM_FORMAT_ABGR, PIXMAN_a8b8g8r8 },
+   { DRM_FORMAT_RGB565, PIXMAN_r5g6b5 },
+   { DRM_FORMAT_BGR565, PIXMAN_b5g6r5 },
+   { DRM_FORMAT_ARGB1555, PIXMAN_a1r5g5b5 },
+   { DRM_FORMAT_XRGB1555, PIXMAN_x1r5g5b5 },
+};
+
+static pixman_image_t *paint_ar24_pattern(size_t width, size_t height)
+{
+   uint32_t colors[] = { 0xff00,
+ 0x,
+ 0xff00ff00,
+ 0xffff,
+ 0x };
+   unsigned i, j;
+   uint32_t *data;
+
+   data = malloc(width * height * sizeof(*data));
+   igt_assert(data);
+
+   for (i = 0; i < height; i++)
+   for (j = 0; j < width; j++)
+   *(data + i * width + j) = colors[((j / 64) + (i / 64)) 
% 5];
+
+   return pixman_image_create_bits(PIXMAN_a8r8g8b8, width, height,
+   data, width * 4);
+}
+
+static void free_pattern(pixman_image_t *pattern)
+{
+   void *data = pixman_image_get_data(pattern);
+
+   pixman_image_unref(pattern);
+   free(data);
+}
+
+static pixman_image_t *pattern_to_fb(pixman_image_t *pattern, struct igt_fb 
*fb,
+pixman_format_code_t pixman_fmt)
+{
+   pixman_image_t *converted;
+   void *ptr;
+
+   igt_assert(fb->is_dumb);
+
+   ptr = kmstest_dumb_map_buffer(fb->fd, fb->gem_handle, fb->size,
+ PROT_READ | PROT_WRITE);
+   igt_assert(ptr);
+
+   converted = pixman_image_create_bits(pixman_fmt, fb->width, fb->height,
+ptr, fb->stride);
+   pixman_image_composite(PIXMAN_OP_ADD, pattern, NULL, converted,
+  0, 0, 0, 0, 0, 0, fb->width, fb->height);
+
+   return converted;
+}
+
+static pixman_image_t *convert_frame_format(pixman_image_t *src,
+ 

[Intel-gfx] [RFC PATCH i-g-t 1/3] tests/chamelium: Move some functions and structures to a common place

[Maxime Ripard]

We are going to use a few functions already defined in kms_chamelium in
other tests. Let's move them out in a separate file / header.

Signed-off-by: Maxime Ripard 
---
 tests/Makefile.sources|   5 ++
 tests/helpers_chamelium.c | 165 
 tests/helpers_chamelium.h |  65 ++
 tests/kms_chamelium.c | 170 +-
 4 files changed, 236 insertions(+), 169 deletions(-)
 create mode 100644 tests/helpers_chamelium.c
 create mode 100644 tests/helpers_chamelium.h

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 23f859beecef..c27226fc96c9 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -275,6 +275,11 @@ scripts = \
 
 IMAGES = pass.png 1080p-left.png 1080p-right.png
 
+kms_chamelium_SOURCES = \
+   kms_chamelium.c \
+   helpers_chamelium.h \
+   helpers_chamelium.c
+
 testdisplay_SOURCES = \
testdisplay.c \
testdisplay.h \
diff --git a/tests/helpers_chamelium.c b/tests/helpers_chamelium.c
new file mode 100644
index ..2d60a8c5f944
--- /dev/null
+++ b/tests/helpers_chamelium.c
@@ -0,0 +1,165 @@
+/*
+ * Copyright © 2016 Red Hat Inc.
+ *
+ * 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.
+ *
+ * Authors:
+ *Lyude Paul 
+ */
+#include "helpers_chamelium.h"
+
+void require_connector_present(data_t *data, unsigned int type)
+{
+   int i;
+   bool found = false;
+
+   for (i = 0; i < data->port_count && !found; i++) {
+   if (chamelium_port_get_type(data->ports[i]) == type)
+   found = true;
+   }
+
+   igt_require_f(found, "No port of type %s was found\n",
+ kmstest_connector_type_str(type));
+}
+
+drmModeConnection reprobe_connector(data_t *data, struct chamelium_port *port)
+{
+   drmModeConnector *connector;
+   drmModeConnection status;
+
+   igt_debug("Reprobing %s...\n", chamelium_port_get_name(port));
+   connector = chamelium_port_get_connector(data->chamelium, port, true);
+   igt_assert(connector);
+   status = connector->connection;
+
+   drmModeFreeConnector(connector);
+   return status;
+}
+
+void wait_for_connector(data_t *data, struct chamelium_port *port,
+   drmModeConnection status)
+{
+   bool finished = false;
+
+   igt_debug("Waiting for %s to %sconnect...\n",
+ chamelium_port_get_name(port),
+ status == DRM_MODE_DISCONNECTED ? "dis" : "");
+
+   /*
+* Rely on simple reprobing so we don't fail tests that don't require
+* that hpd events work in the event that hpd doesn't work on the system
+*/
+   igt_until_timeout(HOTPLUG_TIMEOUT) {
+   if (reprobe_connector(data, port) == status) {
+   finished = true;
+   return;
+   }
+
+   usleep(5);
+   }
+
+   igt_assert(finished);
+}
+
+void reset_state(data_t *data, struct chamelium_port *port)
+{
+   int p;
+
+   chamelium_reset(data->chamelium);
+
+   if (port) {
+   wait_for_connector(data, port, DRM_MODE_DISCONNECTED);
+   } else {
+   for (p = 0; p < data->port_count; p++) {
+   port = data->ports[p];
+   wait_for_connector(data, port, DRM_MODE_DISCONNECTED);
+   }
+   }
+}
+
+igt_output_t *prepare_output(data_t *data, struct chamelium_port *port)
+{
+   igt_display_t *display = >display;
+   igt_output_t *output;
+   drmModeRes *res;
+   drmModeConnector *connector =
+   chamelium_port_get_connector(data->chamelium, port, false);
+   enum pipe pipe;
+   bool found = false;
+
+   igt_assert(res = drmModeGetResources(data->drm_fd));
+
+   /* The chamelium's 

[Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium

[Maxime Ripard]

Hi,

Here is an RFC at starting to test the plane formats using the
Chamelium over the HDMI. This was tested using the vc4 DRM driver
found on the RaspberryPi.

This is still pretty rough around the edges at this point, but I'd
like to get feedback on a few issues before getting any further.

  * I've used pixman for now to convert back and forth the pattern and
the captured frame. While this worked quite well for the RGB
formats since pixman supports most (but not all) of them. However,
the long term plan is to also test YUV and more exotic (like
vendor specific) formats that pixman has 0 support for. So I
really wonder whether this is the right approach compared to:
- Using something else (but what?)?
- Rolling our own format conversion library?

  * I've so far had a single big test that will test all the formats
exposed by the planes that have a pixman representation. I wonder
whether this is preferrable, or if we want to have a subtest per
format. I guess the latter will be slightly better since we would
be able to catch regressions in the number of formats exposed that
we wouldn't be able to with the former.

  * Kind of related, I'm not sure what is the policy when it comes to
tests, and whether I should merge this tests with kms_chamelium or
leave it as a separate file.

  * One of the biggest challenge of the serie is to support formats
that have less bits than the reference frame. Indeed, the flow of
patterns is this one: the pattern will first be generated in
ARGB. It will then be converted to whatever format we want to
test, be fed into the display engine, that will output it, and the
Chamelium will capture it in ARGB.
However, when the plane format has less than 8 bits per color,
some upsampling will happen, where the less significant bits will
be filled with values that probably depend on the display
engine. Another side effect is that the CRC used in the Chamelium
tests cannot be used anymore.
The way I'm testing currently is that I'm retrieving the frame,
and then compare each pixels on their most significant bits. This
sounds inefficient, and it is, especially on the RPi that doesn't
have the best networking throughput out there.
I guess we could also generate a CRC for both an upsampling with
the lowest bits set to 1, and one for the lowest bits set to 0,
and try to see if one of them match. I guess this should cover
most of the situation.

Let me know what you think,
Thanks!
Maxime

Maxime Ripard (3):
  tests/chamelium: Move some functions and structures to a common place
  tests/chamelium: Add test case for plane formats
  tests: Add vc4 test suite

 tests/Makefile.am|   1 +
 tests/Makefile.sources   |  10 +
 tests/helpers_chamelium.c| 165 +
 tests/helpers_chamelium.h|  65 +++
 tests/kms_chamelium.c| 170 +
 tests/kms_chamelium_formats.c| 305 +++
 tests/meson.build|   1 +
 tests/vc4_ci/vc4-chamelium-fast.testlist |   4 +
 tests/vc4_ci/vc4-chamelium.testlist  |   9 +
 tests/vc4_ci/vc4.testlist|  35 
 10 files changed, 596 insertions(+), 169 deletions(-)
 create mode 100644 tests/helpers_chamelium.c
 create mode 100644 tests/helpers_chamelium.h
 create mode 100644 tests/kms_chamelium_formats.c
 create mode 100644 tests/vc4_ci/vc4-chamelium-fast.testlist
 create mode 100644 tests/vc4_ci/vc4-chamelium.testlist
 create mode 100644 tests/vc4_ci/vc4.testlist

-- 
2.14.3

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

Re: [Intel-gfx] [PATCH 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

[Michał Winiarski]

On Mon, Mar 05, 2018 at 04:01:18PM +0530, Sagar Arun Kamble wrote:
> 
> 
> On 2/27/2018 6:22 PM, Michał Winiarski wrote:
> > Currently, we're treating relay and mapping of GuC log as a separate
> > concepts. We're also using inconsistent locking, sometimes using
> > relay_lock, sometimes using struct mutex.
> > Let's correct that. Anything touching the runtime is now serialized
> > using runtime.lock, while we're still using struct mutex as inner lock
> > for mapping.
> > We're still racy in setting the log level - but we'll take care of that
> > in the following patches.
> > 
> > Signed-off-by: Michał Winiarski 
> > Cc: Chris Wilson 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Sagar Arun Kamble 
> > Cc: Michal Wajdeczko 
> > ---
> >   drivers/gpu/drm/i915/intel_guc_log.c | 110 
> > ++-
> >   drivers/gpu/drm/i915/intel_guc_log.h |   3 +-
> >   drivers/gpu/drm/i915/intel_uc.c  |  14 +++--
> >   3 files changed, 42 insertions(+), 85 deletions(-)
> > 

[SNIP]

> > @@ -372,8 +349,6 @@ static void guc_read_update_log_buffer(struct intel_guc 
> > *guc)
> > }
> > guc_move_to_next_buf(guc);
> > -
> > -   mutex_unlock(>log.runtime.relay_lock);
> >   }
> >   static void capture_logs_work(struct work_struct *work)
> > @@ -381,7 +356,9 @@ static void capture_logs_work(struct work_struct *work)
> > struct intel_guc *guc =
> > container_of(work, struct intel_guc, log.runtime.flush_work);
> > +   mutex_lock(>log.runtime.lock);
> > guc_log_capture_logs(guc);
> I think we should just lock guc_read_update_log_buffer as
> guc_log_flush_complete is independent action

Agreed - I'll change this and apply all the other suggestions to the locking.

> > +   mutex_unlock(>log.runtime.lock);
> >   }
> >   static bool guc_log_has_runtime(struct intel_guc *guc)
> > @@ -389,19 +366,16 @@ static bool guc_log_has_runtime(struct intel_guc *guc)
> > return guc->log.runtime.buf_addr != NULL;
> >   }
> > -static int guc_log_runtime_create(struct intel_guc *guc)
> > +static int guc_log_map(struct intel_guc *guc)
> >   {
> > struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > void *vaddr;
> > int ret;
> > -   lockdep_assert_held(_priv->drm.struct_mutex);
> > -
> lockdep_assert for runtime.lock here?
> > if (!guc->log.vma)
> > return -ENODEV;
> > -   GEM_BUG_ON(guc_log_has_runtime(guc));
> > -
> > +   mutex_lock(_priv->drm.struct_mutex);
> > ret = i915_gem_object_set_to_wc_domain(guc->log.vma->obj, true);
> > if (ret)
> mutex not unlocked
> > return ret;
> > @@ -416,20 +390,16 @@ static int guc_log_runtime_create(struct intel_guc 
> > *guc)
> > DRM_ERROR("Couldn't map log buffer pages %d\n", ret);
> mutex not unlocked
> > return PTR_ERR(vaddr);
> > }
> > +   mutex_unlock(_priv->drm.struct_mutex);
> > guc->log.runtime.buf_addr = vaddr;
> > return 0;
> >   }
> > -static void guc_log_runtime_destroy(struct intel_guc *guc)
> > +static void guc_log_unmap(struct intel_guc *guc)
> >   {
> > -   /*
> > -* It's possible that the runtime stuff was never allocated because
> > -* GuC log was disabled at the boot time.
> > -*/
> > -   if (!guc_log_has_runtime(guc))
> > -   return;
> > +   lockdep_assert_held(>log.runtime.lock);
> struct_mutex locking here?

Except this one. AFACT, we don't really need struct mutex here. We need it only
for set_domain - I'll reduce the scope to set_domain on the map path.

> > i915_gem_object_unpin_map(guc->log.vma->obj);
> > guc->log.runtime.buf_addr = NULL;
> > @@ -437,7 +407,7 @@ static void guc_log_runtime_destroy(struct intel_guc 
> > *guc)
> >   void intel_guc_log_init_early(struct intel_guc *guc)
> >   {
> > -   mutex_init(>log.runtime.relay_lock);
> > +   mutex_init(>log.runtime.lock);
> rename and move of members from runtime to log can precede this patch?

How strongly do you feel about this one?
I wanted to tidy first (decouple things), rename later.

> > INIT_WORK(>log.runtime.flush_work, capture_logs_work);
> >   }
> > @@ -448,12 +418,7 @@ int guc_log_relay_create(struct intel_guc *guc)
> > size_t n_subbufs, subbuf_size;
> > int ret;
> > -   if (!i915_modparams.guc_log_level)
> > -   return 0;
> > -
> > -   mutex_lock(>log.runtime.relay_lock);
> > -
> > -   GEM_BUG_ON(guc_log_has_relay(guc));
> > +   lockdep_assert_held(>log.runtime.lock);
> >  /* Keep the size of sub buffers same as shared log buffer */
> > subbuf_size = GUC_LOG_SIZE;
> > @@ -483,12 +448,9 @@ int guc_log_relay_create(struct intel_guc *guc)
> > GEM_BUG_ON(guc_log_relay_chan->subbuf_size < subbuf_size);
> > guc->log.runtime.relay_chan = guc_log_relay_chan;
> > -   mutex_unlock(>log.runtime.relay_lock);
> > -
> > return 0;
> >   err:
> > -   mutex_unlock(>log.runtime.relay_lock);
> >