[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Extend KBL platform support in GVT-g

2017-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915/gvt: Extend KBL platform support in GVT-g
URL   : https://patchwork.freedesktop.org/series/27546/
State : success

== Summary ==

Series 27546v1 drm/i915/gvt: Extend KBL platform support in GVT-g
https://patchwork.freedesktop.org/api/1.0/series/27546/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) k.org#196399
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:439s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:430s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:355s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:528s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:501s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:486s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:595s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:430s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:497s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:570s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:580s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:564s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:581s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:468s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:478s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:432s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:405s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
3d570fb drm/i915/gvt: Extend KBL platform support in GVT-g

== Logs ==

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


[Intel-gfx] [PATCH v2 1/2] drm/i915: Add perf property support for context HW id

2017-07-18 Thread Zhenyu Wang
In order to support profiling for special context e.g vGPU context,
we can expose vGPU context hw id and enable i915 perf property to
get target context for profiling. This adds new perf property to
assign target context with hw id.

Jiao Pengyuan has helped to fix context reference bug in original code.

v2:
- new function for context lookup with hw id
- always require priviledged op
- fix error return value

Cc: Lionel Landwerlin 
Cc: Chris Wilson 
Cc: Jiao Pengyuan 
Cc: Niu Bing 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_perf.c | 83 
 include/uapi/drm/i915_drm.h  |  5 +++
 2 files changed, 72 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 96682fd86f82..a80a3959bc3b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -334,7 +334,9 @@ static struct i915_oa_format 
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
  * struct perf_open_properties - for validated properties given to open a 
stream
  * @sample_flags: `DRM_I915_PERF_PROP_SAMPLE_*` properties are tracked as flags
  * @single_context: Whether a single or all gpu contexts should be monitored
+ * @single_context_hw: Set for special context with hw id e.g vGPU
  * @ctx_handle: A gem ctx handle for use with @single_context
+ * @ctx_hw_id: A ctx hw id for use with @single_context_hw
  * @metrics_set: An ID for an OA unit metric set advertised via sysfs
  * @oa_format: An OA unit HW report format
  * @oa_periodic: Whether to enable periodic OA unit sampling
@@ -348,7 +350,9 @@ struct perf_open_properties {
u32 sample_flags;
 
u64 single_context:1;
+   u64 single_context_hw:1;
u64 ctx_handle;
+   u64 ctx_hw_id;
 
/* OA sampling state */
int metrics_set;
@@ -2482,6 +2486,29 @@ static const struct file_operations fops = {
.unlocked_ioctl = i915_perf_ioctl,
 };
 
+static struct i915_gem_context *
+lookup_context_hw_id(struct drm_i915_private *dev_priv, unsigned int hw_id)
+{
+   struct i915_gem_context *ctx;
+   int ret;
+
+   ret = i915_mutex_lock_interruptible(_priv->drm);
+   if (ret)
+   return ERR_PTR(ret);
+
+   list_for_each_entry(ctx, _priv->contexts.list, link) {
+   if (!i915_gem_context_is_default(ctx))
+   continue;
+
+   if (ctx->hw_id == hw_id) {
+   ret = 1;
+   i915_gem_context_get(ctx);
+   break;
+   }
+   }
+   mutex_unlock(_priv->drm.struct_mutex);
+   return ret ? ctx : NULL;
+}
 
 /**
  * i915_perf_open_ioctl_locked - DRM ioctl() for userspace to open a stream FD
@@ -2531,24 +2558,35 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
ret = -ENOENT;
goto err;
}
+
+   /*
+* On Haswell the OA unit supports clock gating off for a 
specific
+* context and in this mode there's no visibility of metrics 
for the
+* rest of the system, which we consider acceptable for a
+* non-privileged client.
+*
+* For Gen8+ the OA unit no longer supports clock gating off 
for a
+* specific context and the kernel can't securely stop the 
counters
+* from updating as system-wide / global values. Even though we 
can
+* filter reports based on the included context ID we can't 
block
+* clients from seeing the raw / global counter values via
+* MI_REPORT_PERF_COUNT commands and so consider it a 
privileged op to
+* enable the OA unit by default.
+*/
+   if (IS_HASWELL(dev_priv) && specific_ctx)
+   privileged_op = false;
}
 
-   /*
-* On Haswell the OA unit supports clock gating off for a specific
-* context and in this mode there's no visibility of metrics for the
-* rest of the system, which we consider acceptable for a
-* non-privileged client.
-*
-* For Gen8+ the OA unit no longer supports clock gating off for a
-* specific context and the kernel can't securely stop the counters
-* from updating as system-wide / global values. Even though we can
-* filter reports based on the included context ID we can't block
-* clients from seeing the raw / global counter values via
-* MI_REPORT_PERF_COUNT commands and so consider it a privileged op to
-* enable the OA unit by default.
-*/
-   if (IS_HASWELL(dev_priv) && specific_ctx)
-   privileged_op = false;
+   if (props->single_context_hw) {
+   

[Intel-gfx] [PATCH v2 2/2] drm/i915/gvt: expose vGPU context hw id

2017-07-18 Thread Zhenyu Wang
This exposes vGPU context hw id in mdev sysfs which is used to
do vGPU based profiling. Retrieved vGPU context hw id can be set
through i915 perf ioctl to set profiling for target vGPU.

Cc: Lionel Landwerlin 
Cc: Chris Wilson 
Cc: Jiao Pengyuan 
Cc: Niu Bing 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index fd0c85f9ef3c..83e88c70272a 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1170,10 +1170,27 @@ vgpu_id_show(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "\n");
 }
 
+static ssize_t
+hw_id_show(struct device *dev, struct device_attribute *attr,
+  char *buf)
+{
+   struct mdev_device *mdev = mdev_from_dev(dev);
+
+   if (mdev) {
+   struct intel_vgpu *vgpu = (struct intel_vgpu *)
+   mdev_get_drvdata(mdev);
+   return sprintf(buf, "%u\n",
+  vgpu->shadow_ctx->hw_id);
+   }
+   return sprintf(buf, "\n");
+}
+
 static DEVICE_ATTR_RO(vgpu_id);
+static DEVICE_ATTR_RO(hw_id);
 
 static struct attribute *intel_vgpu_attrs[] = {
_attr_vgpu_id.attr,
+   _attr_hw_id.attr,
NULL
 };
 
-- 
2.13.2

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


[Intel-gfx] [PATCH v2] drm/i915/gvt: Extend KBL platform support in GVT-g

2017-07-18 Thread Jian Jun Chen
Extend KBL platform support in GVT-g. Validation tests
are done on KBL server and KBL NUC. Both show the same
quality.

Signed-off-by: Jian Jun Chen 
Cc: Zhenyu Wang 
---
 drivers/gpu/drm/i915/intel_gvt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 52d5b82790d9..c17ed0e62b67 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -45,7 +45,7 @@ static bool is_supported_device(struct drm_i915_private 
*dev_priv)
return true;
if (IS_SKYLAKE(dev_priv))
return true;
-   if (IS_KABYLAKE(dev_priv) && INTEL_DEVID(dev_priv) == 0x591D)
+   if (IS_KABYLAKE(dev_priv))
return true;
return false;
 }
-- 
2.13.0

___
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/gvt: Enable KBL platform support

2017-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915/gvt: Enable KBL platform support
URL   : https://patchwork.freedesktop.org/series/27545/
State : success

== Summary ==

Series 27545v1 drm/i915/gvt: Enable KBL platform support
https://patchwork.freedesktop.org/api/1.0/series/27545/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) k.org#196399
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:437s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:433s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:523s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:493s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:487s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:597s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:415s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:414s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:497s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:571s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:581s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:566s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:588s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:473s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:469s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:410s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
e1ceb86 drm/i915/gvt: Enable KBL platform support

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915/gvt: Enable KBL platform support

2017-07-18 Thread Zhenyu Wang

On 2017.07.19 12:52:17 +0800, Jian Jun Chen wrote:
> Enable KBL platform support in GVT-g. Validation tests
> are done on KBL server and KBL NUC. Both show the same
> quality.
> 
> Signed-off-by: Jian Jun Chen 
> ---

hmm, better to change title as this is not first try for KBL enabling,
that might just confuse people..

>  drivers/gpu/drm/i915/intel_gvt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_gvt.c 
> b/drivers/gpu/drm/i915/intel_gvt.c
> index 52d5b82790d9..c17ed0e62b67 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -45,7 +45,7 @@ static bool is_supported_device(struct drm_i915_private 
> *dev_priv)
>   return true;
>   if (IS_SKYLAKE(dev_priv))
>   return true;
> - if (IS_KABYLAKE(dev_priv) && INTEL_DEVID(dev_priv) == 0x591D)
> + if (IS_KABYLAKE(dev_priv))
>   return true;
>   return false;
>  }
> -- 
> 2.13.0
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Open Source Technology Center, Intel ltd.

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


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


[Intel-gfx] [PATCH] drm/i915/gvt: Enable KBL platform support

2017-07-18 Thread Jian Jun Chen
Enable KBL platform support in GVT-g. Validation tests
are done on KBL server and KBL NUC. Both show the same
quality.

Signed-off-by: Jian Jun Chen 
---
 drivers/gpu/drm/i915/intel_gvt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 52d5b82790d9..c17ed0e62b67 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -45,7 +45,7 @@ static bool is_supported_device(struct drm_i915_private 
*dev_priv)
return true;
if (IS_SKYLAKE(dev_priv))
return true;
-   if (IS_KABYLAKE(dev_priv) && INTEL_DEVID(dev_priv) == 0x591D)
+   if (IS_KABYLAKE(dev_priv))
return true;
return false;
 }
-- 
2.13.0

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


Re: [Intel-gfx] [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation

2017-07-18 Thread Zhenyu Wang
On 2017.07.19 00:55:19 +, Zhang, Tina wrote:
> > 
> > Of course we need that modifier for complete format info. Don't just think 
> > for
> > i915 usage, there's possible modifier for other vendor driver, and it's 
> > required
> > for e.g ADDFB2 in drm kms. Pls add it back in next version.
> We definitely can add it back if it is thought to be useful. Just some 
> curious, as we don't produce the content in the GEM buffer (a.k.a we just 
> expose it here), why we need to know the tile mode. In addition, DRM API can 
> support the functionality to get the tile mode ot GEM buffer. 
> 

That's vendor driver specific ioctl API instead of DRM API.
And besides tiling there could be other vendor's modifiers
which need to be kept for complete info.

-- 
Open Source Technology Center, Intel ltd.

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


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


[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

2017-07-18 Thread Stephen Rothwell
Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/vboxvideo/vbox_drv.c:235:2: error: unknown field 'set_busid' 
specified in initializer
  .set_busid = drm_pci_set_busid,
  ^
drivers/staging/vboxvideo/vbox_drv.c:235:15: error: 'drm_pci_set_busid' 
undeclared here (not in a function)
  .set_busid = drm_pci_set_busid,
   ^
drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_init':
drivers/staging/vboxvideo/vbox_drv.c:273:9: error: implicit declaration of 
function 'drm_pci_init' [-Werror=implicit-function-declaration]
  return drm_pci_init(, _pci_driver);
 ^
drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_exit':
drivers/staging/vboxvideo/vbox_drv.c:278:2: error: implicit declaration of 
function 'drm_pci_exit' [-Werror=implicit-function-declaration]
  drm_pci_exit(, _pci_driver);
  ^

Caused by commits

  5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook")
  10631d724def ("drm/pci: Deprecate drm_pci_init/exit completely")

interacting with commit

  dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")

from the staging.current tree.

I have applied the following merge fix patch - please check that it
is correct.

From: Stephen Rothwell 
Date: Wed, 19 Jul 2017 11:41:01 +1000
Subject: [PATCH] drm: fixes for staging due to API changes in the drm core

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/vboxvideo/vbox_drv.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_drv.c 
b/drivers/staging/vboxvideo/vbox_drv.c
index 92ae1560a16d..6d0600c37c0c 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -232,7 +232,6 @@ static struct drm_driver driver = {
.lastclose = vbox_driver_lastclose,
.master_set = vbox_master_set,
.master_drop = vbox_master_drop,
-   .set_busid = drm_pci_set_busid,
 
.fops = _fops,
.irq_handler = vbox_irq_handler,
@@ -270,12 +269,12 @@ static int __init vbox_init(void)
if (vbox_modeset == 0)
return -EINVAL;
 
-   return drm_pci_init(, _pci_driver);
+   return pci_register_driver(_pci_driver);
 }
 
 static void __exit vbox_exit(void)
 {
-   drm_pci_exit(, _pci_driver);
+   pci_unregister_driver(_pci_driver);
 }
 
 module_init(vbox_init);
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell
___
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 drm-misc tree with Linus' tree

2017-07-18 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/i915_reg.h

between commit:

  c379b897ba1a ("drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing 
Programming")

from Linus' tree and commit:

  5a8dd2af31a7 ("drm/i915/cnl: Fix RMW on ddi vswing sequence.")
(which is also commit 33b92c1e1f27 in Linus' tree)

from the drm-misc tree.

I fixed it up (I just used the version from Linus' tree) 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation

2017-07-18 Thread Zhang, Tina


> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Zhenyu Wang
> Sent: Monday, July 17, 2017 10:27 AM
> To: Zhang, Tina 
> Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org;
> kwankh...@nvidia.com; zhen...@linux.intel.com; ch...@chris-wilson.co.uk;
> alex.william...@redhat.com; Lv, Zhiyuan ;
> dan...@ffwll.ch; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> ; Gerd Hoffmann 
> Subject: Re: [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation
> 
> On 2017.07.17 01:10:03 +, Zhang, Tina wrote:
> > > > +struct vfio_device_gfx_plane_info {
> > > > +   __u32 argsz;
> > > > +   __u32 flags;
> > > > +   /* in */
> > > > +   __u32 drm_plane_type;   /* type of plane:
> > > > DRM_PLANE_TYPE_* */
> > > > +   /* out */
> > > > +   __u32 drm_format;   /* drm format of plane */
> > >
> > > DRM_FORMAT_*
> > >
> > > drm_format_mod is gone?  Not needed?
> > > How tiled buffers are handled then?
> > Drm_format_mod is used as one of the plane's characteristics when judging
> the dma-buf of the plane is new to expose or an old exposed one. As from V10
> we leave this comparing logic to kernel, user mode might not need this field 
> any
> more. If user mode wants, this can be also got though drm APIs. For example,
> eglCreateImageKHR() uses drm APIs to get the tiling format, without asking the
> invoker to explicitly use it as a parameter.
> > Do you think this field is still needed?
> >
> 
> Of course we need that modifier for complete format info. Don't just think for
> i915 usage, there's possible modifier for other vendor driver, and it's 
> required
> for e.g ADDFB2 in drm kms. Pls add it back in next version.
We definitely can add it back if it is thought to be useful. Just some curious, 
as we don't produce the content in the GEM buffer (a.k.a we just expose it 
here), why we need to know the tile mode. In addition, DRM API can support the 
functionality to get the tile mode ot GEM buffer. 

Thanks,
Tina
> 
> --
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v10] vfio: ABI for mdev display dma-buf operation

2017-07-18 Thread Zhang, Tina


> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Monday, July 17, 2017 7:03 PM
> To: Kirti Wankhede ; Zhang, Tina
> ; Tian, Kevin ; linux-
> ker...@vger.kernel.org; intel-gfx@lists.freedesktop.org;
> alex.william...@redhat.com; zhen...@linux.intel.com; chris@chris-
> wilson.co.uk; Lv, Zhiyuan ; intel-gvt-
> d...@lists.freedesktop.org; Wang, Zhi A 
> Subject: Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation
> 
>   Hi,
> 
> > No need of flag here. If vGPU driver is not loaded in the guest, there
> > is no surface being managed by vGPU, in that case this size will be
> > zero.
> 
> Ok, we certainly have the same situation with intel.  When the guest driver 
> is not
> loaded (yet) there is no valid surface.
> 
> We should cleanly define what the ioctl should do in that case, so all drivers
> behave the same way.
> 
> I'd suggest that all fields defining the surface (drm_format, width, height, 
> stride,
> size) should be set to zero in that case.
Yeah, it's reasonable. How about the return value? Currently, the ioctl also 
returns "-ENODEV" in that situation.
 
thanks,
Tina
> 
> cheers,
>   Gerd

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


Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

2017-07-18 Thread Eric Anholt
Daniel Vetter  writes:

> There's a bunch of reasons why I think we should formalize and enforce
> our review rules for igt patches:
>
> - We have a lot of new engineers joining and review helps enormously
>   with mentoring and learning. But right now only patches from
>   contributors without commit rights are consistently subjected to
>   review, which makes this imbalanced and removes senior contributors
>   from the review pool.
>
> - We have a much bigger team and we need to make sure we're aligned on
>   where igt as a tool and testsuite needs to head towards. Getting
>   that alignment happens through reviewing each other's submission.
>   Pushing a contentious patch and then dealing with a heated irc
>   discussion is much less effective.
>
> - Finally igt becomes ever more important for our testing, making sure
>   the code quality is high is important. Review helps with that.
>
> v2: Improve wording a bit (Imre).
>
> Acked-by: Daniel Stone 
> Acked-by: Jani Nikula 
> Acked-by: Joonas Lahtinen 
> Acked-by: Maarten Lankhorst 
> Acked-by: Petri Latvala 
> Acked-by: Imre Deak 
> Acked-by: Robert Foss 
> Acked-by: Ben Widawsky 
> Acked-by: Tvrtko Ursulin 
> Acked-by: Mika Kuoppala 
> Signed-off-by: Daniel Vetter 
> ---
>  CONTRIBUTING | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index d2adcf03b7c3..561c5dd80bba 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -26,10 +26,11 @@ A short list of contribution guidelines:
>convenience macros provided by the igt library. The semantic patch 
> lib/igt.cocci
>can help with the more automatic conversions.
>  
> -- There is no formal review requirement and regular contributors with commit
> -  access can push patches right after submitting them to the mailing lists. 
> But
> -  invasive changes, new helper libraries and contributions from newcomers 
> should
> -  go through a proper review to ensure overall consistency in the codebase.
> +- Patches need to be reviewed on the mailing list. Exceptions only apply for
> +  testcases and tooling for drivers with just a single contributor (e.g. 
> vc4).
> +  In this case patches must still be submitted to the mailing list first.
> +  Testcase should preferrably be cross-reviewed by the same people who write 
> and
> +  review the kernel feature itself.

Thanks for considering my case here :)

Acked-by: Eric Anholt 


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


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

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

v2: * Reduce number of retries when reading the sink CRC (Jani)
* Refactor to minimize changes to the code (Jani)
* Rebase
v3: * Rebase
v4: * Switch from do-while to for loop when reading CRC values (Jani)
* Rebase
Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_dp.c | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2d42d09..c90ca1c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3906,6 +3906,11 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
u8 buf;
int count, ret;
int attempts = 6;
+   u8 old_crc[6];
+
+   if (crc == NULL) {
+   return -ENOMEM;
+   }
 
ret = intel_dp_sink_crc_start(intel_dp);
if (ret)
@@ -3929,11 +3934,33 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
*crc)
goto stop;
}
 
-   if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
-   ret = -EIO;
-   goto stop;
+   /*
+* Sometimes it takes a while for the "real" CRC values to land in
+* the DPCD, so try several times until we get two reads in a row
+* that are the same.  If we're an eDP panel, delay between reads
+* for a while since the values take a bit longer to propagate.
+*/
+   for (attempts = 0; attempts < 6; attempts++) {
+   intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR,
+crc, 6) < 0) {
+   ret = -EIO;
+   break;
+   }
+
+   if (attempts && memcmp(old_crc, crc, 6) == 0)
+   break;
+   memcpy(old_crc, crc, 6);
+
+   if (is_edp(intel_dp))
+   usleep_range(2, 25000);
}
 
+   if (attempts == 6) {
+   DRM_DEBUG_KMS("Failed to get CRC after 6 attempts.\n");
+   ret = -ETIMEDOUT;
+   }
 stop:
intel_dp_sink_crc_stop(intel_dp);
return ret;
-- 
2.7.4

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


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

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

v2 and v3: Rebase
v4: * Fix up some leaky mode stuff (Chris)
* Rebase

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7c0e530..c9db0e6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1606,6 +1606,19 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
return bpp;
 }
 
+static bool intel_edp_compare_alt_mode(struct drm_display_mode *m1,
+  struct drm_display_mode *m2)
+{
+   return (m1->hdisplay == m2->hdisplay &&
+   m1->hsync_start == m2->hsync_start &&
+   m1->hsync_end == m2->hsync_end &&
+   m1->htotal == m2->htotal &&
+   m1->vdisplay == m2->vdisplay &&
+   m1->vsync_start == m2->vsync_start &&
+   m1->vsync_end == m2->vsync_end &&
+   m1->vtotal == m2->vtotal);
+}
+
 bool
 intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -1652,8 +1665,16 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_audio = intel_conn_state->force_audio == 
HDMI_AUDIO_ON;
 
if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
-   intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
-  adjusted_mode);
+   struct drm_display_mode *panel_mode =
+   intel_connector->panel.alt_fixed_mode;
+   struct drm_display_mode *req_mode = _config->base.mode;
+
+   if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
+   panel_mode = intel_connector->panel.fixed_mode;
+
+   drm_mode_debug_printmodeline(panel_mode);
+
+   intel_fixed_panel_mode(panel_mode, adjusted_mode);
 
if (INTEL_GEN(dev_priv) >= 9) {
int ret;
@@ -5810,6 +5831,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_display_mode *fixed_mode = NULL;
+   struct drm_display_mode *alt_fixed_mode = NULL;
struct drm_display_mode *downclock_mode = NULL;
bool has_dpcd;
struct drm_display_mode *scan;
@@ -5865,13 +5887,14 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
}
intel_connector->edid = edid;
 
-   /* prefer fixed mode from EDID if available */
+   /* prefer fixed mode from EDID if available, save an alt mode also */
list_for_each_entry(scan, >probed_modes, head) {
if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
fixed_mode = drm_mode_duplicate(dev, scan);
downclock_mode = intel_dp_drrs_init(
intel_connector, fixed_mode);
-   break;
+   } else if (!alt_fixed_mode) {
+   alt_fixed_mode = drm_mode_duplicate(dev, scan);
}
}
 
@@ -5908,7 +5931,8 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
  pipe_name(pipe));
}
 
-   intel_panel_init(_connector->panel, fixed_mode, downclock_mode);
+   intel_panel_init(_connector->panel, fixed_mode, alt_fixed_mode,
+downclock_mode);
intel_connector->panel.backlight.power = intel_edp_backlight_power;
intel_panel_setup_backlight(connector, pipe);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e45163a..3bd11e2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -265,6 +265,7 @@ struct intel_encoder {
 
 struct intel_panel {
struct drm_display_mode *fixed_mode;
+   struct drm_display_mode *alt_fixed_mode;
struct drm_display_mode *downclock_mode;
 
/* backlight 

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

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

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

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

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

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


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

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

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

which were eventually hand-reverted by

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

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

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

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

v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier reading. (Chris)
* Rebase

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c90ca1c..7c0e530 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 27, 54 
};
  * If a CPU or PCH DP output is attached to an eDP panel, this function
  * will return true, and false otherwise.
  */
-static bool is_edp(struct intel_dp *intel_dp)
+bool is_edp(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 
@@ -4738,6 +4738,7 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
 
intel_dp->reset_link_params = false;
+   intel_dp->train_set_valid = false;
}
 
intel_dp_print_rates(intel_dp);
@@ -6008,6 +6009,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_dp_set_source_rates(intel_dp);
 
intel_dp->reset_link_params = true;
+   intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index b79c1c0..d12200d 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
 {
-   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+   if (!intel_dp->train_set_valid)
+   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
 }
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
   DP_TRAINING_PATTERN_1 |
   DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+   intel_dp->train_set_valid = false;
return false;
}
 
+   /*
+* The initial set of link parameters are set by this point, so go
+* ahead and set intel_dp->train_set_valid to false in case any of
+* the succeeding steps fail.  It will be set back to true if we were
+* able to achieve clock recovery in the specified configuration.
+*/
+   intel_dp->train_set_valid = false;
+
voltage_tries = 1;
max_vswing_tries = 0;
   

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

2017-07-18 Thread Chris Wilson
Quoting Paul Kocialkowski (2017-07-18 16:16:26)
> It may occur that a hotplug uevent is detected at resume, even though it
> does not indicate that an actual hotplug happened. This is the case when
> link training fails on any other connector.
> 
> There is currently no way to distinguish what connector caused a hotplug
> uevent, nor what the reason for that uevent really is. This makes it
> impossible to find out whether the test actually passed or not.

And you may get more than one and then this skips even though the test
passed. Looks like the patch is overcompensating. What you can do is
repeat the test a few times, and then look at all the different errors
you get. If the connector remains (no mst disappareance) once it goes
bad, it should remain bad and so not generate any new uevent. Or you
only repeat the test whilst link_status[old] != link_status[new].
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

2017-07-18 Thread Pandiyan, Dhinakaran



On Tue, 2017-07-18 at 19:35 +0100, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2017-07-18 19:28:00)
> > INTEL_GEN() appears to be the new way of doing these platform checks, so
> > convert this i915_irq.c too.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Chris Wilson 
> -Chris


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


Re: [Intel-gfx] [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders

2017-07-18 Thread Matthias Kaehlcke
Hi Daniel,

El Tue, Jul 18, 2017 at 08:39:50AM +0200 Daniel Vetter ha dit:

> On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote:
> > The current code uses in some instances enum transcoder for PCH
> > transcoders and enum pipe in others. This is error prone and clang
> > raises warnings like this:
> > 
> > drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
> >   from enumeration type 'enum pipe' to different enumeration type
> >   'enum transcoder' [-Wenum-conversion]
> > intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
> > 
> > Consistently use the type enum pipe for PCH transcoders.
> > 
> > Signed-off-by: Matthias Kaehlcke 
> 
> Somehow git apply-mbox could parse it, but manually applying using patch
> worked. Not sure what's going on, maybe double-check it's all right.

Not sure what happened, one of the patch fragments only has one '@'
instead of two, with that fixed the patch applies.

Unfortunately the manual application missed some fragments:

drivers/gpu/drm/i915/intel_display.c:5350:51: warning: implicit
  conversion from enumeration type 'enum transcoder' to different
  enumeration type 'enum pipe' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
~   ^~~~
drivers/gpu/drm/i915/intel_display.c:5436:51: warning: implicit
  conversion from enumeration type 'enum transcoder' to different
  enumeration type 'enum pipe' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
~   ^~~~
drivers/gpu/drm/i915/intel_display.c:5534:51: warning: implicit
  conversion from enumeration type 'enum transcoder' to different
  enumeration type 'enum pipe' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
~   ^~~~
drivers/gpu/drm/i915/intel_display.c:5563:51: warning: implicit
  conversion from enumeration type 'enum transcoder' to different
  enumeration type 'enum pipe' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,


What would be the best way forward from here? Revert the manual
application and apply again, or a fixup patch?

Matthias

> > ---
> > Changes in v2:
> > - rebased on drm-intel/drm-intel-next-queued
> > 
> >  drivers/gpu/drm/i915/i915_irq.c| 10 +-
> >  drivers/gpu/drm/i915/intel_display.c   | 24 ++--
> >  drivers/gpu/drm/i915/intel_drv.h   |  6 +++---
> >  drivers/gpu/drm/i915/intel_fifo_underrun.c |  6 +++---
> >  4 files changed, 21 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 1d33cea01a1b..0b6f310101ee 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2086,10 +2086,10 @@ static void ibx_irq_handler(struct drm_i915_private 
> > *dev_priv, u32 pch_iir)
> > DRM_DEBUG_DRIVER("PCH transcoder CRC error interrupt\n");
> >  
> > if (pch_iir & SDE_TRANSA_FIFO_UNDER)
> > -   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
> > +   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
> >  
> > if (pch_iir & SDE_TRANSB_FIFO_UNDER)
> > -   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
> > +   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
> >  }
> >  
> >  static void ivb_err_int_handler(struct drm_i915_private *dev_priv)
> > @@ -2123,13 +2123,13 @@ static void cpt_serr_int_handler(struct 
> > drm_i915_private *dev_priv)
> > DRM_ERROR("PCH poison interrupt\n");
> >  
> > if (serr_int & SERR_INT_TRANS_A_FIFO_UNDERRUN)
> > -   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
> > +   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
> >  
> > if (serr_int & SERR_INT_TRANS_B_FIFO_UNDERRUN)
> > -   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
> > +   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
> >  
> > if (serr_int & SERR_INT_TRANS_C_FIFO_UNDERRUN)
> > -   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_C);
> > +   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_C);
> >  
> > I915_WRITE(SERR_INT, serr_int);
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bb9c9c3c391f..5c7054c3be0e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1777,7 +1777,7 @@ static void lpt_enable_pch_transcoder(struct 
> > drm_i915_private *dev_priv,
> >  
> > /* FDI must be feeding us bits for PCH ports */
> > assert_fdi_tx_enabled(dev_priv, (enum 

Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

2017-07-18 Thread Daniel Vetter
On Tue, Jul 18, 2017 at 10:34 PM, Lionel Landwerlin
 wrote:
> Acked-by: Lionel Landwerlin 
>
> I assume review cannot be provided by someone who doesn't already contribute
> or has a number of patches in already.
>
> What's the criteria to become a reviewer?
> Is there is going to be a list of people to go to for review?

Just going out and getting the first r-b tag from the lowest bidder
would indeed be a bit silly, but I don't see any issue with new
contributors (who might not yet have pushed anything) doing review.

Imo review is about a lot more than just code correctess, it's also
really great tool for aligning a team on the ideas in a code, for
mentoring and learning and all that stuff. So someone new reviewing
code of someone experienced, and making the code and docs better by
asking questions, sounds pretty perfect to me.

Ofc two completely new contributors reviewing each another's stuff
would again defeat that, but then they need at least someone slightly
more experienced as committer again.

tldr; totally not worried nor seeing a need for criteria for reviewers.

Cheers, Daniel

> -
> Lionel
>
>
> On 18/07/17 17:00, Daniel Vetter wrote:
>>
>> There's a bunch of reasons why I think we should formalize and enforce
>> our review rules for igt patches:
>>
>> - We have a lot of new engineers joining and review helps enormously
>>with mentoring and learning. But right now only patches from
>>contributors without commit rights are consistently subjected to
>>review, which makes this imbalanced and removes senior contributors
>>from the review pool.
>>
>> - We have a much bigger team and we need to make sure we're aligned on
>>where igt as a tool and testsuite needs to head towards. Getting
>>that alignment happens through reviewing each other's submission.
>>Pushing a contentious patch and then dealing with a heated irc
>>discussion is much less effective.
>>
>> - Finally igt becomes ever more important for our testing, making sure
>>the code quality is high is important. Review helps with that.
>>
>> v2: Improve wording a bit (Imre).
>>
>> Acked-by: Daniel Stone 
>> Acked-by: Jani Nikula 
>> Acked-by: Joonas Lahtinen 
>> Acked-by: Maarten Lankhorst 
>> Acked-by: Petri Latvala 
>> Acked-by: Imre Deak 
>> Acked-by: Robert Foss 
>> Acked-by: Ben Widawsky 
>> Acked-by: Tvrtko Ursulin 
>> Acked-by: Mika Kuoppala 
>> Signed-off-by: Daniel Vetter 
>> ---
>>   CONTRIBUTING | 9 +
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/CONTRIBUTING b/CONTRIBUTING
>> index d2adcf03b7c3..561c5dd80bba 100644
>> --- a/CONTRIBUTING
>> +++ b/CONTRIBUTING
>> @@ -26,10 +26,11 @@ A short list of contribution guidelines:
>> convenience macros provided by the igt library. The semantic patch
>> lib/igt.cocci
>> can help with the more automatic conversions.
>>   -- There is no formal review requirement and regular contributors with
>> commit
>> -  access can push patches right after submitting them to the mailing
>> lists. But
>> -  invasive changes, new helper libraries and contributions from newcomers
>> should
>> -  go through a proper review to ensure overall consistency in the
>> codebase.
>> +- Patches need to be reviewed on the mailing list. Exceptions only apply
>> for
>> +  testcases and tooling for drivers with just a single contributor (e.g.
>> vc4).
>> +  In this case patches must still be submitted to the mailing list first.
>> +  Testcase should preferrably be cross-reviewed by the same people who
>> write and
>> +  review the kernel feature itself.
>> - When patches from new contributors (without commit access) are
>> stuck, for
>> anything related to the regular releases, issues with packaging and
>
>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 i-g-t] CONTRIBUTING: formalize review rules

2017-07-18 Thread Lionel Landwerlin

Acked-by: Lionel Landwerlin 

I assume review cannot be provided by someone who doesn't already 
contribute or has a number of patches in already.


What's the criteria to become a reviewer?
Is there is going to be a list of people to go to for review?

-
Lionel

On 18/07/17 17:00, Daniel Vetter wrote:

There's a bunch of reasons why I think we should formalize and enforce
our review rules for igt patches:

- We have a lot of new engineers joining and review helps enormously
   with mentoring and learning. But right now only patches from
   contributors without commit rights are consistently subjected to
   review, which makes this imbalanced and removes senior contributors
   from the review pool.

- We have a much bigger team and we need to make sure we're aligned on
   where igt as a tool and testsuite needs to head towards. Getting
   that alignment happens through reviewing each other's submission.
   Pushing a contentious patch and then dealing with a heated irc
   discussion is much less effective.

- Finally igt becomes ever more important for our testing, making sure
   the code quality is high is important. Review helps with that.

v2: Improve wording a bit (Imre).

Acked-by: Daniel Stone 
Acked-by: Jani Nikula 
Acked-by: Joonas Lahtinen 
Acked-by: Maarten Lankhorst 
Acked-by: Petri Latvala 
Acked-by: Imre Deak 
Acked-by: Robert Foss 
Acked-by: Ben Widawsky 
Acked-by: Tvrtko Ursulin 
Acked-by: Mika Kuoppala 
Signed-off-by: Daniel Vetter 
---
  CONTRIBUTING | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index d2adcf03b7c3..561c5dd80bba 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -26,10 +26,11 @@ A short list of contribution guidelines:
convenience macros provided by the igt library. The semantic patch 
lib/igt.cocci
can help with the more automatic conversions.
  
-- There is no formal review requirement and regular contributors with commit

-  access can push patches right after submitting them to the mailing lists. But
-  invasive changes, new helper libraries and contributions from newcomers 
should
-  go through a proper review to ensure overall consistency in the codebase.
+- Patches need to be reviewed on the mailing list. Exceptions only apply for
+  testcases and tooling for drivers with just a single contributor (e.g. vc4).
+  In this case patches must still be submitted to the mailing list first.
+  Testcase should preferrably be cross-reviewed by the same people who write 
and
+  review the kernel feature itself.
  
  - When patches from new contributors (without commit access) are stuck, for

anything related to the regular releases, issues with packaging and



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


Re: [Intel-gfx] [PATCH i-g-t 0/2] Unrelated hotplug uevent masking out actual test result

2017-07-18 Thread Lyude Paul
For the whole series

Reviewed-by: Lyude 

will push in just a sec

On Tue, 2017-07-18 at 18:16 +0300, Paul Kocialkowski wrote:
> This patch introduces a workaround for a case where a uevent is
> issued
> by the kernel because of DP link training failing on a connector
> unrelated to the current test. Since the test depends on receiving a
> hotplug uevent, it previously passed even though it should not have.
> 
> False positives also occur due to the plug/unplug events being
> delayed
> and issued at resume time. This is mitigated by catching and flushing
> hotplugs everytime a change is made on connectors, but it is not
> enough
> to ensure that all hotplug events were caught and not delayed.
> 
> The problem here is that it is not possible to find out the exact
> reason
> why a uevent is issued by the kernel. A possible way to fix this
> would
> be to introduce more fields (the connector name and some reason why
> the
> event is triggered would probably be sufficient).
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Cheers,
Lyude
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

2017-07-18 Thread Imre Deak
On Wed, Jul 19, 2017 at 12:46:37AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/18/2017 11:42 PM, Imre Deak wrote:
> > On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote:
> > > To get HDMI YCBCR420 output, the PIPEMISC register should be
> > > programmed to:
> > > - Generate YCBCR output (bit 11)
> > > - In case of YCBCR420 outputs, it should be programmed in full
> > >blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
> > > 
> > > This patch:
> > > - Adds definition of these bits.
> > > - Programs PIPEMISC for YCBCR420 outputs.
> > > - Adds readouts to compare HW and SW states.
> > > 
> > > V2: rebase
> > > V3: rebase
> > > V4: rebase
> > > V5: added r-b from Ander
> > > V6: Handle only YCBCR420 outputs (ville)
> > > V7: rebase
> > > V8: Addressed review comments from Ville
> > >  - Add readouts for state->ycbcr420 and 420 pixel_clock.
> > >  - Handle warning due to mismatch in clock for ycbcr420 clock.
> > >  - Rename PIPEMISC macros to match the Bspec.
> > >  - Add a debug print stating if YCBCR 4:2:0 output enabled.
> > >  Added r-b from Ville
> > > 
> > > Cc: Ville Syrjala 
> > > Cc: Ander Conselvan de Oliveira 
> > > Cc: Daniel Vetter 
> > > 
> > > Reviewed-by: Ander Conselvan de Oliveira 
> > > Reviewed-by: Ville Syrjala 
> > > Signed-off-by: Shashank Sharma 
> > > ---
> > >   drivers/gpu/drm/i915/i915_reg.h  |  3 ++
> > >   drivers/gpu/drm/i915/intel_display.c | 55 
> > > ++--
> > >   2 files changed, 55 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index c712d01..6dfcdd3 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5227,6 +5227,9 @@ enum {
> > >   #define _PIPE_MISC_A0x70030
> > >   #define _PIPE_MISC_B0x71030
> > > +#define   PIPEMISC_YUV420_ENABLE (1<<27)
> > > +#define   PIPEMISC_YUV420_MODE_BLEND (1<<26)
> > > +#define   PIPEMISC_OUTPUT_YUV(1<<11)
> > Missing the rename here requested by Ville.
> Ah, I thought it was more strict on changing YCBCR->YUV, will get this done.
> > >   #define   PIPEMISC_DITHER_BPC_MASK  (7<<5)
> > >   #define   PIPEMISC_DITHER_8_BPC (0<<5)
> > >   #define   PIPEMISC_DITHER_10_BPC(1<<5)
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index d78f1c2..788502a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6216,7 +6216,6 @@ static uint32_t ilk_pipe_pixel_rate(const struct 
> > > intel_crtc_state *pipe_config)
> > >* We only use IF-ID interlacing. If we ever use
> > >* PF-ID we'll need to adjust the pixel_rate here.
> > >*/
> > > -
> > Extra w/s change.
> Got it.
> > 
> > >   if (pipe_config->pch_pfit.enabled) {
> > >   uint64_t pipe_w, pipe_h, pfit_w, pfit_h;
> > >   uint32_t pfit_size = pipe_config->pch_pfit.size;
> > > @@ -8076,6 +8075,7 @@ static void haswell_set_pipemisc(struct drm_crtc 
> > > *crtc)
> > >   {
> > >   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > + struct intel_crtc_state *config = intel_crtc->config;
> > >   if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
> > >   u32 val = 0;
> > > @@ -8101,6 +8101,12 @@ static void haswell_set_pipemisc(struct drm_crtc 
> > > *crtc)
> > >   if (intel_crtc->config->dither)
> > >   val |= PIPEMISC_DITHER_ENABLE | 
> > > PIPEMISC_DITHER_TYPE_SP;
> > > + if (config->ycbcr420) {
> > > + val |= PIPEMISC_OUTPUT_YUV |
> > > + PIPEMISC_YUV420_ENABLE |
> > > + PIPEMISC_YUV420_MODE_BLEND;
> > > + }
> > > +
> > >   I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
> > >   }
> > >   }
> > > @@ -9170,6 +9176,10 @@ static bool haswell_get_pipe_config(struct 
> > > intel_crtc *crtc,
> > >   pipe_config->scaler_state.scaler_users &= ~(1 << 
> > > SKL_CRTC_INDEX);
> > >   }
> > > + if (IS_GEMINILAKE(dev_priv))
> > > + pipe_config->ycbcr420 = I915_READ(PIPEMISC(crtc->pipe)) &
> > > + PIPEMISC_YUV420_ENABLE;
> > > +
> > >   power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> > >   if (intel_display_power_get_if_enabled(dev_priv, power_domain)) 
> > > {
> > >   power_domain_mask |= BIT_ULL(power_domain);
> > > @@ -11377,6 +11387,9 @@ static void intel_dump_pipe_config(struct 
> > > 

[Intel-gfx] drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

2017-07-18 Thread David Binderman

Hello there,

drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean 
expression with an integer other than 0 or 1.

Source code is

else if ((ddb_allocation && ddb_allocation /
fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 1)

Regards

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


Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

2017-07-18 Thread Sharma, Shashank

Regards

Shashank


On 7/18/2017 11:42 PM, Imre Deak wrote:

On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote:

To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
   blend mode to use the scaler in 5x3 ratio (bits 26 and 27)

This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR420 outputs.
- Adds readouts to compare HW and SW states.

V2: rebase
V3: rebase
V4: rebase
V5: added r-b from Ander
V6: Handle only YCBCR420 outputs (ville)
V7: rebase
V8: Addressed review comments from Ville
 - Add readouts for state->ycbcr420 and 420 pixel_clock.
 - Handle warning due to mismatch in clock for ycbcr420 clock.
 - Rename PIPEMISC macros to match the Bspec.
 - Add a debug print stating if YCBCR 4:2:0 output enabled.
 Added r-b from Ville

Cc: Ville Syrjala 
Cc: Ander Conselvan de Oliveira 
Cc: Daniel Vetter 

Reviewed-by: Ander Conselvan de Oliveira 
Reviewed-by: Ville Syrjala 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/i915_reg.h  |  3 ++
  drivers/gpu/drm/i915/intel_display.c | 55 ++--
  2 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..6dfcdd3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5227,6 +5227,9 @@ enum {
  
  #define _PIPE_MISC_A			0x70030

  #define _PIPE_MISC_B  0x71030
+#define   PIPEMISC_YUV420_ENABLE   (1<<27)
+#define   PIPEMISC_YUV420_MODE_BLEND   (1<<26)
+#define   PIPEMISC_OUTPUT_YUV  (1<<11)

Missing the rename here requested by Ville.

Ah, I thought it was more strict on changing YCBCR->YUV, will get this done.

  #define   PIPEMISC_DITHER_BPC_MASK(7<<5)
  #define   PIPEMISC_DITHER_8_BPC   (0<<5)
  #define   PIPEMISC_DITHER_10_BPC  (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d78f1c2..788502a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6216,7 +6216,6 @@ static uint32_t ilk_pipe_pixel_rate(const struct 
intel_crtc_state *pipe_config)
 * We only use IF-ID interlacing. If we ever use
 * PF-ID we'll need to adjust the pixel_rate here.
 */
-

Extra w/s change.

Got it.



if (pipe_config->pch_pfit.enabled) {
uint64_t pipe_w, pipe_h, pfit_w, pfit_h;
uint32_t pfit_size = pipe_config->pch_pfit.size;
@@ -8076,6 +8075,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
  {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *config = intel_crtc->config;
  
  	if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {

u32 val = 0;
@@ -8101,6 +8101,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
  
+		if (config->ycbcr420) {

+   val |= PIPEMISC_OUTPUT_YUV |
+   PIPEMISC_YUV420_ENABLE |
+   PIPEMISC_YUV420_MODE_BLEND;
+   }
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
  }
@@ -9170,6 +9176,10 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
pipe_config->scaler_state.scaler_users &= ~(1 << 
SKL_CRTC_INDEX);
}
  
+	if (IS_GEMINILAKE(dev_priv))

+   pipe_config->ycbcr420 = I915_READ(PIPEMISC(crtc->pipe)) &
+   PIPEMISC_YUV420_ENABLE;
+
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
power_domain_mask |= BIT_ULL(power_domain);
@@ -11377,6 +11387,9 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
  pipe_config->fdi_lanes,
  _config->fdi_m_n);
  
+	if (pipe_config->ycbcr420)

+   DRM_DEBUG_KMS("YCbCr 4:2:0 output enabled\n");
+
if (intel_crtc_has_dp_encoder(pipe_config)) {
intel_dump_m_n_config(pipe_config, "dp m_n",
pipe_config->lane_count, _config->dp_m_n);
@@ -11704,6 +11717,22 @@ intel_modeset_update_crtc_state(struct 
drm_atomic_state *state)
}
  }
  
+static bool intel_420_clock_check(int clock1, int clock2)

+{
+   int diff;
+
+   if (clock1 == clock2 * 2)
+   return true;
+
+   clock2 *= 2;
+   diff = 

Re: [Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result

2017-07-18 Thread Manasi Navare
On Tue, Jul 18, 2017 at 05:25:36PM +0300, Paul Kocialkowski wrote:
> This adds the connector name when printing a debug message about the DP
> link training result. It is useful to figure out what connector is
> failing when multiple DP connectors are used.
>

Thanks for the patch, this does make sense during the link training
failure debugging to know the connector name.
While at it feel free to change "Failed", "Link Rate, Lane Count", to upper case
in the failure_handling case to be consistent with the pass case.

Reviewed-by: Manasi Navare 

Manasi

> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index b79c1c0e404c..05907fa8a553 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -321,12 +321,16 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>   if (!intel_dp_link_training_channel_equalization(intel_dp))
>   goto failure_handling;
>  
> - DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate = 
> %d, Lane count = %d",
> +   intel_connector->base.base.id,
> +   intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
>   return;
>  
>   failure_handling:
> - DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = 
> %d, lane count = %d",
> +   intel_connector->base.base.id,
> +   intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
>   if (!intel_dp_get_link_train_fallback_values(intel_dp,
>intel_dp->link_rate,
> -- 
> 2.13.2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable FBC for non X-tiled FBs (rev5)

2017-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915: Enable FBC for non X-tiled FBs (rev5)
URL   : https://patchwork.freedesktop.org/series/21264/
State : success

== Summary ==

Series 21264v5 drm/i915: Enable FBC for non X-tiled FBs
https://patchwork.freedesktop.org/api/1.0/series/21264/revisions/5/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

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

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:443s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:429s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:355s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:532s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:510s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:491s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:487s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:594s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:441s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:585s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:577s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:564s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:586s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:465s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:472s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:432s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:468s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:409s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
ee3e000 drm/i915: Fix FBC cfb stride programming for non X-tiled FB

== Logs ==

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


Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"

2017-07-18 Thread Puthikorn Voravootivat
May be the older panel might not work well with this feature.
David/Jani, what do you think about adding check that the panel is eDP
1.4 or later in the heuristic?

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index b25cd88fc1c5..e63f2296fd34 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -292,7 +292,7 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
  * via PWM pin or using AUX is better than using PWM pin.
  *
  * The heuristic to determine that using AUX pin is better than using
PWM pin is
- * that the panel support any of the feature list here.
+ * that the panel is eDP 1.4 or later and support any of the feature list here.
  * - Regional backlight brightness adjustment
  * - Backlight PWM frequency set
  * - More than 8 bits resolution of brightness level
@@ -310,6 +310,10 @@ intel_dp_aux_display_control_heuristic(struct
intel_connector *connector)
if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
return true;

+   /* Enable this for eDP 1.4 panel or later. */
+   if (intel_dp->edp_dpcd[0] < DP_EDP_14)
+   return false;
+
/* Panel supports regional backlight brightness adjustment */
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_GENERAL_CAP_3,
  _val) != 1) {

On Mon, Jul 10, 2017 at 7:23 AM, David Weinehall
 wrote:
> This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
>
> This patch has been identified to introduce a backlight regression
> on at least two different platforms; either the heuristic is broken
> (if so the patch needs to be reworked) or the in-kernel DPCD backlight
> support is broken (if so it's premature to enable DPCD backlight
> even if the platforms support it).
>
> Signed-off-by: David Weinehall 
> ---
>  drivers/gpu/drm/i915/i915_params.c|  7 ++-
>  drivers/gpu/drm/i915/i915_params.h|  1 -
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 61 
> ++-
>  3 files changed, 6 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 88b9d3e6713a..bec5ade371b0 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
> .huc_firmware_path = NULL,
> .enable_dp_mst = true,
> .inject_load_failure = 0,
> -   .enable_dpcd_backlight = -1,
> +   .enable_dpcd_backlight = false,
> .enable_gvt = false,
> .enable_dbc = true,
>  };
> @@ -247,10 +247,9 @@ MODULE_PARM_DESC(enable_dp_mst,
>  module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, 
> uint, 0400);
>  MODULE_PARM_DESC(inject_load_failure,
> "Force an error after a number of failure check points (0:disabled 
> (default), N:force failure at the Nth failure check point)");
> -module_param_named_unsafe(enable_dpcd_backlight, i915.enable_dpcd_backlight, 
> int, 0600);
> +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
> 0600);
>  MODULE_PARM_DESC(enable_dpcd_backlight,
> -   "Enable support for DPCD backlight control "
> -   "(-1:auto (default), 0:force disable, 1:force enabled if supported");
> +   "Enable support for DPCD backlight control (default:false)");
>
>  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
>  MODULE_PARM_DESC(enable_gvt,
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 057e203e6bda..6a88c76664db 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -53,7 +53,6 @@
> func(int, edp_vswing); \
> func(int, reset); \
> func(unsigned int, inject_load_failure); \
> -   func(int, enable_dpcd_backlight); \
> /* leave bools at the end to not create holes */ \
> func(bool, alpha_support); \
> func(bool, enable_cmd_parser); \
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index b25cd88fc1c5..f32dec02e540 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -277,66 +277,15 @@ intel_dp_aux_display_control_capable(struct 
> intel_connector *connector)
> /* Check the eDP Display control capabilities registers to determine 
> if
>  * the panel can support backlight control over the aux channel
>  */
> -   if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
> -   (intel_dp->edp_dpcd[2] & 
> DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
> +   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> +   (intel_dp->edp_dpcd[2] 

Re: [Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result

2017-07-18 Thread Pandiyan, Dhinakaran



On Tue, 2017-07-18 at 17:25 +0300, Paul Kocialkowski wrote:
> This adds the connector name when printing a debug message about the DP
> link training result. It is useful to figure out what connector is
> failing when multiple DP connectors are used.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index b79c1c0e404c..05907fa8a553 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -321,12 +321,16 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>   if (!intel_dp_link_training_channel_equalization(intel_dp))
>   goto failure_handling;
>  
> - DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate = 
> %d, Lane count = %d",
> +   intel_connector->base.base.id,
> +   intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
>   return;
>  
>   failure_handling:
> - DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = 
> %d, lane count = %d",
> +   intel_connector->base.base.id,
> +   intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
>   if (!intel_dp_get_link_train_fallback_values(intel_dp,
>intel_dp->link_rate,


Reviewed-by: Dhinakaran Pandiyan 

The choice of upper v/s lower case letters in these debug messages is a
bit odd.

Passed/failed
Link rate/link rate
Lane count/lane count
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2017-07-18 Thread Sean Paul
On Tue, Jul 18, 2017 at 2:42 PM, Sean Paul  wrote:
> Hi Dave,
> Here's the first -misc-next pull for 4.13

err, 4.14.



> , definitely the largest one I've
> sent to you. There's nothing too disruptive, a bunch of clean-up series which
> tidy up atomic macros, return value fixes, etc. New functionality includes 2 
> new dsi
> bridge drivers, async atomic commits, YCBCR 4:2:0 support, and RK3399 support 
> in
> dw_hdmi.
>
> Note that there will be conflicts with Al's tree that went directly to Linus.
> Laurent posted a patch to fix this:
> Subject: [PATCH] drm: compat: Fix compilation breakage due to drm_vblank_wait
> Message-Id: <20170710234235.25334-1-laurent.pinchart+rene...@ideasonboard.com>
>
> Feel free to add my Acked-by or Reviewed-by when you apply if you'd like.
>
>
> drm-misc-next-2017-07-18:
> UAPI Changes:
> - Fail commits which request an event without including a crtc (Andrey)
>
> Core Changes:
> - Add YCBCR 4:2:0 support (Shashank)
> - s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter)
> - Add proper base class for private objs instead of using void* (Ville)
> - Remove pending_read/write_domains from drm_gem_object (Chris)
> - Add async plane update support (ie: cursor) to atomic helpers (Gustavo)
> - Add old state to .enable and rename to .atomic_enable (Laurent)
> - Add drm_atomic_helper_wait_for_flip_done() (Boris)
> - Remove drm_driver->set_busid hook (Daniel)
> - Migrate vblank documentation into the source files (Daniel)
> - Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel)
>
> Driver Changes:
> - stm: Add STM32 DSI controller driver (Phillipe)
> - amdgpu: Numerous small/misc fixes
> - bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe)
> - tinydrm: Add support for Pervasive Displays RePaper displays (Noralf)
> - misc: Replace for_each_[obj]_in_state to prep for removal (Maarten)
> - misc: Use .atomic_disable for atomic drivers (Laurent)
> - vgem: Pin pages when mapped/exported (Chris)
> - dw_hdmi: Add support for Rockchip RK3399 (Mark)
> - atmel-hlcdc: Add 8-bit color look-up table format (Peter)
> - vc4: Send vblank event when disabling a crtc (Boris)
> - vc4: Use atomic helpers for fence waits (Eric)
> - misc: drop drm_vblank_cleanup cargo-cult (Daniel)
>
> Cc: Daniel Vetter 
> Cc: Boris Brezillon 
> Cc: Eric Anholt 
> Cc: Peter Rosin 
> Cc: Mark Yao 
> Cc: Chris Wilson 
> Cc: Andrey Grodzovsky 
> Cc: Laurent Pinchart 
> Cc: Gustavo Padovan 
> Cc: Thierry Reding 
> Cc: Ville Syrjälä 
> Cc: Peter Rosin 
> Cc: Shashank Sharma 
> Cc: Philippe CORNU 
>
> Thanks, Sean
>
>
> The following changes since commit 6d61e70ccc21606ffb8a0a03bd3aba24f659502b:
>
>   Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-07-18
>
> for you to fetch changes up to b1332aaabbdada327f2daffc7d69161cbf210ebf:
>
>   drm: stm: remove "default y" in Kconfig (2017-07-18 10:03:25 +0200)
>
> 
> UAPI Changes:
> - Fail commits which request an event without including a crtc (Andrey)
>
> Core Changes:
> - Add YCBCR 4:2:0 support (Shashank)
> - s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter)
> - Add proper base class for private objs instead of using void* (Ville)
> - Remove pending_read/write_domains from drm_gem_object (Chris)
> - Add async plane update support (ie: cursor) to atomic helpers (Gustavo)
> - Add old state to .enable and rename to .atomic_enable (Laurent)
> - Add drm_atomic_helper_wait_for_flip_done() (Boris)
> - Remove drm_driver->set_busid hook (Daniel)
> - Migrate vblank documentation into the source files (Daniel)
> - Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel)
>
> Driver Changes:
> - stm: Add STM32 DSI controller driver (Phillipe)
> - amdgpu: Numerous small/misc fixes
> - bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe)
> - tinydrm: Add support for Pervasive Displays RePaper displays (Noralf)
> - misc: Replace for_each_[obj]_in_state to prep for removal (Maarten)
> - misc: Use .atomic_disable for atomic drivers (Laurent)
> - vgem: Pin pages when mapped/exported (Chris)
> - dw_hdmi: Add support for Rockchip RK3399 (Mark)
> - atmel-hlcdc: Add 8-bit color look-up table format (Peter)
> - vc4: Send vblank event when disabling a crtc (Boris)
> - vc4: Use atomic helpers for fence waits (Eric)
> - misc: drop drm_vblank_cleanup cargo-cult (Daniel)
>
> Cc: Daniel Vetter 
> Cc: Boris 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

2017-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq
URL   : https://patchwork.freedesktop.org/series/27510/
State : success

== Summary ==

Series 27510v1 drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in 
i915_irq
https://patchwork.freedesktop.org/api/1.0/series/27510/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) k.org#196399
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101705 +1

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399
fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:440s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:426s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:354s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:530s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-byt-j1900 total:279  pass:255  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:489s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:605s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:436s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:422s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:574s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:579s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:559s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:458s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:585s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:469s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:481s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:435s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:471s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:401s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
3029bd6 drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

== Logs ==

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


[Intel-gfx] [PATCH v5] drm/i915: Fix FBC cfb stride programming for non X-tiled FB

2017-07-18 Thread Praveen Paneri
When FBC is enabled for linear, legacy Y-tiled and Yf-tiled
surfaces on gen9, the cfb stride must be programmed by SW as

cfb_stride = ceiling[(at least plane width in pixels)/
 (32 * compression limit factor)] * 8

v2: Minor fix for a build error
v3: Fixed subject, register name and platform check (Ville)
v4: Added WA details in comment (Paulo)
v5:
 - Read modified reg write to preserve other bit values (Paulo)
 - Store modified stride value in reg_params (Paulo)
 - Keep GLK out of the WA (Paulo)

Cc: Paulo Zanoni 
Signed-off-by: Praveen Paneri 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_fbc.c | 19 +++
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..9e65f34 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6710,6 +6710,9 @@ enum {
 #define CHICKEN_MISC_2 _MMIO(0x42084)
 #define  COMP_PWR_DOWN (1 << 23)
 
+#define CHICKEN_MISC_4 _MMIO(0x4208c)
+#define   FBC_STRIDE_OVERRIDE  (1<<13)
+
 #define _CHICKEN_PIPESL_1_A0x420b0
 #define _CHICKEN_PIPESL_1_B0x420b4
 #define  HSW_FBCQ_DIS  (1 << 22)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 860b8c2..251d3f4 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -288,9 +288,28 @@ static bool ilk_fbc_is_active(struct drm_i915_private 
*dev_priv)
 static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
 {
struct intel_fbc_reg_params *params = _priv->fbc.params;
+   struct intel_fbc_state_cache *cache = _priv->fbc.state_cache;
u32 dpfc_ctl;
int threshold = dev_priv->fbc.threshold;
 
+   /* Display WA #0529: skl, kbl, bxt but not for glk*/
+   if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
+   u32 chicken_misc4 = I915_READ(CHICKEN_MISC_4);
+
+   if (i915_gem_object_get_tiling(cache->vma->obj)
+   != I915_TILING_X) {
+   int cfb_stride = DIV_ROUND_UP(cache->plane.src_w,
+(32 * threshold)) * 8;
+   params->fb.stride = cfb_stride;
+
+   I915_WRITE(CHICKEN_MISC_4, chicken_misc4 |
+   FBC_STRIDE_OVERRIDE | cfb_stride);
+   } else {
+   I915_WRITE(CHICKEN_MISC_4, chicken_misc4 &
+   ~FBC_STRIDE_OVERRIDE);
+   }
+   }
+
dpfc_ctl = 0;
if (IS_IVYBRIDGE(dev_priv))
dpfc_ctl |= IVB_DPFC_CTL_PLANE(params->crtc.plane);
-- 
1.9.1

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


Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

2017-07-18 Thread Chris Wilson
Quoting Tvrtko Ursulin (2017-07-18 15:36:16)
> From: Tvrtko Ursulin 
> 
> Enables other i915 components to enable and disable
> the facility as needed.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c  | 53 
> +
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  5 
>  2 files changed, 58 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 3e5e08c6b5ef..03e7459bad06 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -29,6 +29,8 @@
>  #include "intel_lrc.h"
>  
>  DEFINE_STATIC_KEY_FALSE(i915_engine_stats_key);
> +static DEFINE_MUTEX(i915_engine_stats_mutex);
> +static int i915_engine_stats_ref;
>  
>  /* Haswell does have the CXT_SIZE register however it does not appear to be
>   * valid. Now, docs explain in dwords what is in the context object. The full
> @@ -1340,6 +1342,57 @@ void intel_engines_mark_idle(struct drm_i915_private 
> *i915)
> }
>  }
>  
> +int intel_enable_engine_stats(struct drm_i915_private *dev_priv)

The pattern I've been trying to use here is

intel_engine_* - operate on the named engine

intel_engines_* - operate on all engines

Long term though having a global static key is going to be a nasty wart.
Joonas will definitely ask the question how much will it cost us to use
an engine->bool and what we can do to minimise that cost.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2017-07-18 Thread Sean Paul
Hi Dave,
Here's the first -misc-next pull for 4.13, definitely the largest one I've
sent to you. There's nothing too disruptive, a bunch of clean-up series which
tidy up atomic macros, return value fixes, etc. New functionality includes 2 
new dsi
bridge drivers, async atomic commits, YCBCR 4:2:0 support, and RK3399 support in
dw_hdmi.

Note that there will be conflicts with Al's tree that went directly to Linus.
Laurent posted a patch to fix this:
Subject: [PATCH] drm: compat: Fix compilation breakage due to drm_vblank_wait
Message-Id: <20170710234235.25334-1-laurent.pinchart+rene...@ideasonboard.com>

Feel free to add my Acked-by or Reviewed-by when you apply if you'd like.


drm-misc-next-2017-07-18:
UAPI Changes:
- Fail commits which request an event without including a crtc (Andrey)

Core Changes:
- Add YCBCR 4:2:0 support (Shashank)
- s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter)
- Add proper base class for private objs instead of using void* (Ville)
- Remove pending_read/write_domains from drm_gem_object (Chris)
- Add async plane update support (ie: cursor) to atomic helpers (Gustavo)
- Add old state to .enable and rename to .atomic_enable (Laurent)
- Add drm_atomic_helper_wait_for_flip_done() (Boris)
- Remove drm_driver->set_busid hook (Daniel)
- Migrate vblank documentation into the source files (Daniel)
- Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel)

Driver Changes:
- stm: Add STM32 DSI controller driver (Phillipe)
- amdgpu: Numerous small/misc fixes
- bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe)
- tinydrm: Add support for Pervasive Displays RePaper displays (Noralf)
- misc: Replace for_each_[obj]_in_state to prep for removal (Maarten)
- misc: Use .atomic_disable for atomic drivers (Laurent)
- vgem: Pin pages when mapped/exported (Chris)
- dw_hdmi: Add support for Rockchip RK3399 (Mark)
- atmel-hlcdc: Add 8-bit color look-up table format (Peter)
- vc4: Send vblank event when disabling a crtc (Boris)
- vc4: Use atomic helpers for fence waits (Eric)
- misc: drop drm_vblank_cleanup cargo-cult (Daniel)

Cc: Daniel Vetter 
Cc: Boris Brezillon 
Cc: Eric Anholt 
Cc: Peter Rosin 
Cc: Mark Yao 
Cc: Chris Wilson 
Cc: Andrey Grodzovsky 
Cc: Laurent Pinchart 
Cc: Gustavo Padovan 
Cc: Thierry Reding 
Cc: Ville Syrjälä 
Cc: Peter Rosin 
Cc: Shashank Sharma 
Cc: Philippe CORNU 

Thanks, Sean


The following changes since commit 6d61e70ccc21606ffb8a0a03bd3aba24f659502b:

  Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000)

are available in the git repository at:

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

for you to fetch changes up to b1332aaabbdada327f2daffc7d69161cbf210ebf:

  drm: stm: remove "default y" in Kconfig (2017-07-18 10:03:25 +0200)


UAPI Changes:
- Fail commits which request an event without including a crtc (Andrey)

Core Changes:
- Add YCBCR 4:2:0 support (Shashank)
- s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter)
- Add proper base class for private objs instead of using void* (Ville)
- Remove pending_read/write_domains from drm_gem_object (Chris)
- Add async plane update support (ie: cursor) to atomic helpers (Gustavo)
- Add old state to .enable and rename to .atomic_enable (Laurent)
- Add drm_atomic_helper_wait_for_flip_done() (Boris)
- Remove drm_driver->set_busid hook (Daniel)
- Migrate vblank documentation into the source files (Daniel)
- Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel)

Driver Changes:
- stm: Add STM32 DSI controller driver (Phillipe)
- amdgpu: Numerous small/misc fixes
- bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe)
- tinydrm: Add support for Pervasive Displays RePaper displays (Noralf)
- misc: Replace for_each_[obj]_in_state to prep for removal (Maarten)
- misc: Use .atomic_disable for atomic drivers (Laurent)
- vgem: Pin pages when mapped/exported (Chris)
- dw_hdmi: Add support for Rockchip RK3399 (Mark)
- atmel-hlcdc: Add 8-bit color look-up table format (Peter)
- vc4: Send vblank event when disabling a crtc (Boris)
- vc4: Use atomic helpers for fence waits (Eric)
- misc: drop drm_vblank_cleanup cargo-cult (Daniel)

Cc: Daniel Vetter 
Cc: Boris Brezillon 
Cc: Eric Anholt 
Cc: Peter Rosin 
Cc: Mark Yao 
Cc: Chris Wilson 
Cc: Andrey Grodzovsky 
Cc: Laurent Pinchart 

Re: [Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

2017-07-18 Thread Chris Wilson
Quoting Dhinakaran Pandiyan (2017-07-18 19:28:00)
> INTEL_GEN() appears to be the new way of doing these platform checks, so
> convert this i915_irq.c too.
> 
> Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

2017-07-18 Thread Chris Wilson
Quoting Lionel Landwerlin (2017-07-18 17:50:42)
>  static struct drm_driver driver = {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2b824f8875c4..607484737f3d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1917,6 +1917,9 @@ struct i915_oa_config {
> struct attribute_group sysfs_metric;
> struct attribute *attrs[2];
> struct device_attribute sysfs_metric_id;
> +
> +   /* Only updated while holding dev_priv->perf.metrics_lock. */
> +   bool in_use;

Definitely do not get warm fuzzy feeling about this.

Would making this a regular refcount be difficult? It would for example
allow removing whilst it is still in use by a stream (just removing it
from the user table so new streams cannot be created with it). And stop
me from making helpful suggestions about how in_use access is purely
atomic...

> +   oa_config = kzalloc(sizeof(*oa_config), GFP_KERNEL);
> +   if (!oa_config) {
> +   DRM_DEBUG("Failed to allocate memory for the OA config\n");
> +   return -ENOMEM;
> +   }
> +
> +   err = strncpy_from_user(oa_config->uuid, u64_to_user_ptr(args->uuid),
> +   UUID_STRING_LEN);

So you have a fixed size buffer, why have userspace pass a pointer
rather than an array? Try char uuid[UUID_STRING_LEN] in 
struct drm_i915_perf_oa_config and see which you think is eaiser to use
and, more importantly, harder to get wrong.

> +   if (err < 0) {
> +   DRM_DEBUG("Failed to copy uuid from OA config\n");
> +   goto mux_err;
> +   }
> +
> +   if (!uuid_is_valid(oa_config->uuid)) {
> +   DRM_DEBUG("Invalid uuid format for OA config\n");
> +   err = -EINVAL;
> +   goto mux_err;
> +   }
> +   idr_for_each_entry(_priv->perf.metrics_idr, tmp, id) {

Comment that you don't expect many so this iteration shouldn't be too
costly.

> +   if (!strcmp(tmp->uuid, oa_config->uuid)) {
> +   DRM_DEBUG("OA config already exists with this 
> uuid\n");
> +   err = -EADDRINUSE;
> +   goto sysfs_err;
> +   }
> +   }
> +
> +   err = create_dynamic_oa_sysfs_entry(dev_priv, oa_config);
> +   if (err) {
> +   DRM_DEBUG("Failed to create sysfs entry for OA config\n");
> +   goto sysfs_err;
> +   }
> +
> +   oa_config->id = idr_alloc(_priv->perf.metrics_idr,
> + oa_config, 2,

Comment on reserving 0 for invalid and 1 for default.

> +}
> +/**
> + * Structure to upload perf dynamic configuration into the kernel.
> + */
> +struct drm_i915_perf_oa_config {
> +   /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
> +   __u64 __user uuid;

Not a pointer, so __user is meaningless (and should generate warnings
from sparse). Equally it is nice to know in the name which of these are
encoding user pointers.

> +   __u32 n_mux_regs;
> +   __u32 pad0;
> +   __u64 __user mux_regs;
> +
> +   __u32 n_boolean_regs;
> +   __u32 pad1;
> +   __u64 __user boolean_regs;
> +
> +   __u32 n_flex_regs;
> +   __u32 pad2;
> +   __u64 __user flex_regs;


With a little bit of rearranging you can reduce the padding.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

2017-07-18 Thread Dhinakaran Pandiyan
INTEL_GEN() appears to be the new way of doing these platform checks, so
convert this i915_irq.c too.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_irq.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eb4f1dc..4cdee95 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -275,17 +275,17 @@ void gen5_disable_gt_irq(struct drm_i915_private 
*dev_priv, uint32_t mask)
 
 static i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
 {
-   return INTEL_INFO(dev_priv)->gen >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
+   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
 }
 
 static i915_reg_t gen6_pm_imr(struct drm_i915_private *dev_priv)
 {
-   return INTEL_INFO(dev_priv)->gen >= 8 ? GEN8_GT_IMR(2) : GEN6_PMIMR;
+   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IMR(2) : GEN6_PMIMR;
 }
 
 static i915_reg_t gen6_pm_ier(struct drm_i915_private *dev_priv)
 {
-   return INTEL_INFO(dev_priv)->gen >= 8 ? GEN8_GT_IER(2) : GEN6_PMIER;
+   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IER(2) : GEN6_PMIER;
 }
 
 /**
@@ -1661,7 +1661,7 @@ static void gen6_rps_irq_handler(struct drm_i915_private 
*dev_priv, u32 pm_iir)
spin_unlock(_priv->irq_lock);
}
 
-   if (INTEL_INFO(dev_priv)->gen >= 8)
+   if (INTEL_GEN(dev_priv) >= 8)
return;
 
if (HAS_VEBOX(dev_priv)) {
@@ -2440,7 +2440,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
ret = IRQ_HANDLED;
 
tmp_mask = GEN8_AUX_CHANNEL_A;
-   if (INTEL_INFO(dev_priv)->gen >= 9)
+   if (INTEL_GEN(dev_priv) >= 9)
tmp_mask |= GEN9_AUX_CHANNEL_B |
GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
@@ -2498,7 +2498,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
intel_check_page_flip(dev_priv, pipe);
 
flip_done = iir;
-   if (INTEL_INFO(dev_priv)->gen >= 9)
+   if (INTEL_GEN(dev_priv) >= 9)
flip_done &= GEN9_PIPE_PLANE1_FLIP_DONE;
else
flip_done &= GEN8_PIPE_PRIMARY_FLIP_DONE;
@@ -2513,7 +2513,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
 
fault_errors = iir;
-   if (INTEL_INFO(dev_priv)->gen >= 9)
+   if (INTEL_GEN(dev_priv) >= 9)
fault_errors &= GEN9_DE_PIPE_IRQ_FAULT_ERRORS;
else
fault_errors &= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
@@ -3492,7 +3492,7 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
u32 de_misc_masked = GEN8_DE_MISC_GSE;
enum pipe pipe;
 
-   if (INTEL_INFO(dev_priv)->gen >= 9) {
+   if (INTEL_GEN(dev_priv) >= 9) {
de_pipe_masked |= GEN9_PIPE_PLANE1_FLIP_DONE |
  GEN9_DE_PIPE_IRQ_FAULT_ERRORS;
de_port_masked |= GEN9_AUX_CHANNEL_B | GEN9_AUX_CHANNEL_C |
@@ -4290,16 +4290,16 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
 *
 * TODO: verify if this can be reproduced on VLV,CHV.
 */
-   if (INTEL_INFO(dev_priv)->gen <= 7)
+   if (INTEL_GEN(dev_priv) <= 7)
dev_priv->rps.pm_intrmsk_mbz |= GEN6_PM_RP_UP_EI_EXPIRED;
 
-   if (INTEL_INFO(dev_priv)->gen >= 8)
+   if (INTEL_GEN(dev_priv) >= 8)
dev_priv->rps.pm_intrmsk_mbz |= 
GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
 
if (IS_GEN2(dev_priv)) {
/* Gen2 doesn't have a hardware frame counter */
dev->max_vblank_count = 0;
-   } else if (IS_G4X(dev_priv) || INTEL_INFO(dev_priv)->gen >= 5) {
+   } else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
dev->max_vblank_count = 0x; /* full 32 bit counter */
dev->driver->get_vblank_counter = g4x_get_vblank_counter;
} else {
@@ -4346,7 +4346,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->enable_vblank = i965_enable_vblank;
dev->driver->disable_vblank = i965_disable_vblank;
dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
-   } else if (INTEL_INFO(dev_priv)->gen >= 8) {
+   } else if (INTEL_GEN(dev_priv) >= 8) {
dev->driver->irq_handler = gen8_irq_handler;
dev->driver->irq_preinstall = gen8_irq_reset;
dev->driver->irq_postinstall = gen8_irq_postinstall;
-- 
2.7.4

___

Re: [Intel-gfx] [PATCH v4 i-g-t] igt/perf: add tests to verify create/destroy userspace configs

2017-07-18 Thread Chris Wilson
Quoting Lionel Landwerlin (2017-07-18 18:18:52)
> v2: Add tests regarding removing configs (Matthew)
> Add tests regarding adding/removing configs without permissions
> (Matthew)
> 
> v3: Add some flex registers (Matthew)
> 
> v4: memset oa_config to 0 (Lionel)
> Change error code for removing unexisting config EINVAL->ENOENT (Lionel)
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  tests/perf.c | 208 
> +++
>  1 file changed, 208 insertions(+)
> 
> diff --git a/tests/perf.c b/tests/perf.c
> index 1c5cf351..66ec731a 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> @@ -146,6 +146,36 @@ enum drm_i915_perf_record_type {
>  };
>  #endif /* !DRM_I915_PERF_OPEN */
> 
> +#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
> +
> +#define DRM_I915_PERF_ADD_CONFIG   0x37
> +#define DRM_I915_PERF_REMOVE_CONFIG0x38
> +
> +#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
> +#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG  DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_I915_PERF_REMOVE_CONFIG, __u64)
> +
> +/**
> + * Structure to upload perf dynamic configuration into the kernel.
> + */
> +struct drm_i915_perf_oa_config {
> +   /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
> +   __u64 uuid;
> +
> +   __u32 n_mux_regs;
> +   __u32 pad0;
> +   __u64 mux_regs;
> +
> +   __u32 n_boolean_regs;
> +   __u32 pad1;
> +   __u64 boolean_regs;
> +
> +   __u32 n_flex_regs;
> +   __u32 pad2;
> +   __u64 flex_regs;
> +};
> +
> +#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
> +
>  struct accumulator {
>  #define MAX_RAW_OA_COUNTERS 62
> enum drm_i915_oa_format format;
> @@ -4001,6 +4031,175 @@ test_rc6_disable(void)
> igt_assert_neq(n_events_end - n_events_start, 0);
>  }
> 
> +static void
> +test_invalid_userspace_config_create(void)
> +{
> +   struct drm_i915_perf_oa_config config;
> +   const char *uuid = "01234567-0123-0123-0123-0123456789ab";
> +   const char *invalid_uuid = "blablabla-wrong";
> +   uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
> +   uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register */, 
> 0x0 };
> +
> +   memset(, 0, sizeof(config));
> +
> +   /* invalid uuid */
> +   config.uuid = to_user_pointer(invalid_uuid);
> +   config.n_mux_regs = 1;
> +   config.mux_regs = to_user_pointer(mux_regs);
> +   config.n_boolean_regs = 0;
> +   config.n_flex_regs = 0;
> +
> +   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, , EINVAL);

Create little stubs like
int __i915_perf_add_config(int fd, config)
{
int err;

err = 0;
if (igt_ioctl(fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, config))
err = -errno;

return err;
}

void i915_perf_add_config(int fd, config)
{
igt_assert_eq(__i915_perf_add_config(fd, config), 0);
}

and here use igt_assert_eq(__i915_perf_add_config(fd, config), -EINVAL);

The benefit is that if you ever do hit the error, the message is much
more understandable than the macro expansion of
DRM_IOCTL_I915_PERF_ADD_CONFIG.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

2017-07-18 Thread Imre Deak
On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
>   blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
> 
> This patch:
> - Adds definition of these bits.
> - Programs PIPEMISC for YCBCR420 outputs.
> - Adds readouts to compare HW and SW states.
> 
> V2: rebase
> V3: rebase
> V4: rebase
> V5: added r-b from Ander
> V6: Handle only YCBCR420 outputs (ville)
> V7: rebase
> V8: Addressed review comments from Ville
> - Add readouts for state->ycbcr420 and 420 pixel_clock.
> - Handle warning due to mismatch in clock for ycbcr420 clock.
> - Rename PIPEMISC macros to match the Bspec.
> - Add a debug print stating if YCBCR 4:2:0 output enabled.
> Added r-b from Ville
> 
> Cc: Ville Syrjala 
> Cc: Ander Conselvan de Oliveira 
> Cc: Daniel Vetter 
> 
> Reviewed-by: Ander Conselvan de Oliveira 
> Reviewed-by: Ville Syrjala 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  3 ++
>  drivers/gpu/drm/i915/intel_display.c | 55 
> ++--
>  2 files changed, 55 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c712d01..6dfcdd3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5227,6 +5227,9 @@ enum {
>  
>  #define _PIPE_MISC_A 0x70030
>  #define _PIPE_MISC_B 0x71030
> +#define   PIPEMISC_YUV420_ENABLE (1<<27)
> +#define   PIPEMISC_YUV420_MODE_BLEND (1<<26)
> +#define   PIPEMISC_OUTPUT_YUV(1<<11)

Missing the rename here requested by Ville.

>  #define   PIPEMISC_DITHER_BPC_MASK   (7<<5)
>  #define   PIPEMISC_DITHER_8_BPC  (0<<5)
>  #define   PIPEMISC_DITHER_10_BPC (1<<5)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d78f1c2..788502a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6216,7 +6216,6 @@ static uint32_t ilk_pipe_pixel_rate(const struct 
> intel_crtc_state *pipe_config)
>* We only use IF-ID interlacing. If we ever use
>* PF-ID we'll need to adjust the pixel_rate here.
>*/
> -

Extra w/s change.

>   if (pipe_config->pch_pfit.enabled) {
>   uint64_t pipe_w, pipe_h, pfit_w, pfit_h;
>   uint32_t pfit_size = pipe_config->pch_pfit.size;
> @@ -8076,6 +8075,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *config = intel_crtc->config;
>  
>   if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
>   u32 val = 0;
> @@ -8101,6 +8101,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
>   if (intel_crtc->config->dither)
>   val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
>  
> + if (config->ycbcr420) {
> + val |= PIPEMISC_OUTPUT_YUV |
> + PIPEMISC_YUV420_ENABLE |
> + PIPEMISC_YUV420_MODE_BLEND;
> + }
> +
>   I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
>   }
>  }
> @@ -9170,6 +9176,10 @@ static bool haswell_get_pipe_config(struct intel_crtc 
> *crtc,
>   pipe_config->scaler_state.scaler_users &= ~(1 << 
> SKL_CRTC_INDEX);
>   }
>  
> + if (IS_GEMINILAKE(dev_priv))
> + pipe_config->ycbcr420 = I915_READ(PIPEMISC(crtc->pipe)) &
> + PIPEMISC_YUV420_ENABLE;
> +
>   power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
>   if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
>   power_domain_mask |= BIT_ULL(power_domain);
> @@ -11377,6 +11387,9 @@ static void intel_dump_pipe_config(struct intel_crtc 
> *crtc,
> pipe_config->fdi_lanes,
> _config->fdi_m_n);
>  
> + if (pipe_config->ycbcr420)
> + DRM_DEBUG_KMS("YCbCr 4:2:0 output enabled\n");
> +
>   if (intel_crtc_has_dp_encoder(pipe_config)) {
>   intel_dump_m_n_config(pipe_config, "dp m_n",
>   pipe_config->lane_count, _config->dp_m_n);
> @@ -11704,6 +11717,22 @@ intel_modeset_update_crtc_state(struct 
> drm_atomic_state *state)
>   }
>  }
>  
> +static bool intel_420_clock_check(int clock1, int clock2)
> +{
> + int diff;
> +
> + if (clock1 == clock2 * 2)
> + return true;
> +
> + 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Attach a stub pm_domain

2017-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Attach a stub pm_domain
URL   : https://patchwork.freedesktop.org/series/27505/
State : success

== Summary ==

Series 27505v1 drm/i915/selftests: Attach a stub pm_domain
https://patchwork.freedesktop.org/api/1.0/series/27505/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-snb-2600) fdo#100215
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101705 +1

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

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:442s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:430s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:359s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:537s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-byt-j1900 total:279  pass:255  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:487s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:594s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:434s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:416s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:500s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:569s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:576s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:558s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:452s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:585s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:480s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:467s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:409s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
4bf673b drm/i915/selftests: Attach a stub pm_domain

== Logs ==

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


[Intel-gfx] [PATCH v2] drm/i915: Only free the oldest stale object before a fresh allocation

2017-07-18 Thread Chris Wilson
Inspired by Tvrtko's critique of the reaping of the stale contexts
before allocating a new one, also limit the freed object reaping to the
oldest stale object before allocating a fresh object. Unlike contexts,
objects may have radically different sizes of backing storage, but
similar to contexts, whilst we want to prevent starvation due to
excessive freed lists, we also want do not want to delay fresh
allocations for too long. Only freeing the oldest on the freed object
list before each allocation is a reasonable compromise.

v2: Only a single consumer of llist_del_first() is allowed (although
multiple llist_add are still allowed in parallel). Unlike
i915_gem_context, i915_gem_flush_free_objects() is itself not serialized
and so we need to add our own spinlock. Otherwise KASAN eventually spots
a use-after-free for the race on *first->next.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin  #v1
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 14 --
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 667fb5c44483..e1c2bc66e0fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1447,6 +1447,7 @@ struct i915_gem_mm {
 */
struct llist_head free_list;
struct work_struct free_work;
+   spinlock_t free_lock;
 
/** Usable portion of the GTT for GEM */
dma_addr_t stolen_base; /* limited to low memory (32-bit) */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2c2907fef612..d57603f64e96 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4542,9 +4542,18 @@ static void i915_gem_flush_free_objects(struct 
drm_i915_private *i915)
 {
struct llist_node *freed;
 
-   freed = llist_del_all(>mm.free_list);
-   if (unlikely(freed))
+   /* Free the oldest, most stale object to keep the free_list short */
+   freed = NULL;
+   if (!llist_empty(>mm.free_list)) { /* quick test for hotpath */
+   /* Only one consumer of llist_del_first() allowed */
+   spin_lock(>mm.free_lock);
+   freed = llist_del_first(>mm.free_list);
+   spin_unlock(>mm.free_lock);
+   }
+   if (unlikely(freed)) {
+   freed->next = NULL;
__i915_gem_free_objects(i915, freed);
+   }
 }
 
 static void __i915_gem_free_work(struct work_struct *work)
@@ -5026,6 +5035,7 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
INIT_WORK(_priv->mm.free_work, __i915_gem_free_work);
 
spin_lock_init(_priv->mm.obj_lock);
+   spin_lock_init(_priv->mm.free_lock);
init_llist_head(_priv->mm.free_list);
INIT_LIST_HEAD(_priv->mm.unbound_list);
INIT_LIST_HEAD(_priv->mm.bound_list);
-- 
2.13.3

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


[Intel-gfx] [PATCH] drm/i915/selftests: Attach a stub pm_domain

2017-07-18 Thread Chris Wilson
Supply a pm_domain and its ops for our mock GEM device so that
device runtime pm doesn't complain even though we only want to mark it
permanently active!

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 47613d20bba8..99c038249454 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -22,6 +22,7 @@
  *
  */
 
+#include 
 #include 
 
 #include "mock_engine.h"
@@ -109,6 +110,23 @@ static void mock_idle_work_handler(struct work_struct 
*work)
 {
 }
 
+static int pm_domain_resume(struct device *dev)
+{
+   return pm_generic_runtime_resume(dev);
+}
+
+static int pm_domain_suspend(struct device *dev)
+{
+   return pm_generic_runtime_suspend(dev);
+}
+
+static struct dev_pm_domain pm_domain = {
+   .ops = {
+   .runtime_suspend = pm_domain_suspend,
+   .runtime_resume = pm_domain_resume,
+   },
+};
+
 struct drm_i915_private *mock_gem_device(void)
 {
struct drm_i915_private *i915;
@@ -127,8 +145,10 @@ struct drm_i915_private *mock_gem_device(void)
dev_set_name(>dev, "mock");
dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
 
+   dev_pm_domain_set(>dev, _domain);
+   pm_runtime_enable(>dev);
pm_runtime_dont_use_autosuspend(>dev);
-   pm_runtime_get_sync(>dev);
+   WARN_ON(pm_runtime_get_sync(>dev));
 
i915 = (struct drm_i915_private *)(pdev + 1);
pci_set_drvdata(pdev, i915);
-- 
2.13.3

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


[Intel-gfx] [PATCH v4 i-g-t] igt/perf: add tests to verify create/destroy userspace configs

2017-07-18 Thread Lionel Landwerlin
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)

v3: Add some flex registers (Matthew)

v4: memset oa_config to 0 (Lionel)
Change error code for removing unexisting config EINVAL->ENOENT (Lionel)

Signed-off-by: Lionel Landwerlin 
---
 tests/perf.c | 208 +++
 1 file changed, 208 insertions(+)

diff --git a/tests/perf.c b/tests/perf.c
index 1c5cf351..66ec731a 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -146,6 +146,36 @@ enum drm_i915_perf_record_type {
 };
 #endif /* !DRM_I915_PERF_OPEN */

+#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
+
+#define DRM_I915_PERF_ADD_CONFIG   0x37
+#define DRM_I915_PERF_REMOVE_CONFIG0x38
+
+#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
+#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_PERF_REMOVE_CONFIG, __u64)
+
+/**
+ * Structure to upload perf dynamic configuration into the kernel.
+ */
+struct drm_i915_perf_oa_config {
+   /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
+   __u64 uuid;
+
+   __u32 n_mux_regs;
+   __u32 pad0;
+   __u64 mux_regs;
+
+   __u32 n_boolean_regs;
+   __u32 pad1;
+   __u64 boolean_regs;
+
+   __u32 n_flex_regs;
+   __u32 pad2;
+   __u64 flex_regs;
+};
+
+#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
+
 struct accumulator {
 #define MAX_RAW_OA_COUNTERS 62
enum drm_i915_oa_format format;
@@ -4001,6 +4031,175 @@ test_rc6_disable(void)
igt_assert_neq(n_events_end - n_events_start, 0);
 }

+static void
+test_invalid_userspace_config_create(void)
+{
+   struct drm_i915_perf_oa_config config;
+   const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+   const char *invalid_uuid = "blablabla-wrong";
+   uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+   uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register */, 0x0 
};
+
+   memset(, 0, sizeof(config));
+
+   /* invalid uuid */
+   config.uuid = to_user_pointer(invalid_uuid);
+   config.n_mux_regs = 1;
+   config.mux_regs = to_user_pointer(mux_regs);
+   config.n_boolean_regs = 0;
+   config.n_flex_regs = 0;
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, , EINVAL);
+
+   /* invalid mux_regs */
+   config.uuid = to_user_pointer(uuid);
+   config.n_mux_regs = 1;
+   config.mux_regs = to_user_pointer(invalid_mux_regs);
+   config.n_boolean_regs = 0;
+   config.n_flex_regs = 0;
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, , EINVAL);
+
+   /* empty config */
+   config.uuid = to_user_pointer(uuid);
+   config.n_mux_regs = 0;
+   config.mux_regs = to_user_pointer(mux_regs);
+   config.n_boolean_regs = 0;
+   config.n_flex_regs = 0;
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, , EINVAL);
+
+   /* empty config with null pointers */
+   config.uuid = to_user_pointer(uuid);
+   config.n_mux_regs = 1;
+   config.mux_regs = to_user_pointer(NULL);
+   config.n_boolean_regs = 2;
+   config.boolean_regs = to_user_pointer(NULL);
+   config.n_flex_regs = 3;
+   config.flex_regs = to_user_pointer(NULL);
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, , EINVAL);
+}
+
+static void
+test_invalid_userspace_config_remove(void)
+{
+   struct drm_i915_perf_oa_config config;
+   const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+   uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+   uint64_t config_id, wrong_config_id = 9;
+   char path[512];
+   int ret;
+
+   snprintf(path, sizeof(path), "/sys/class/drm/card%d/metrics/%s/id", 
card, uuid);
+
+   /* Destroy previous configuration if present */
+   if (try_read_u64_file(path, _id))
+ igt_assert(igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG, 
_id) == 0);
+
+   memset(, 0, sizeof(config));
+
+   config.uuid = to_user_pointer(uuid);
+
+   config.n_mux_regs = 1;
+   config.mux_regs = to_user_pointer(mux_regs);
+   config.n_boolean_regs = 0;
+   config.n_flex_regs = 0;
+
+   ret = igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, );
+   igt_assert(ret > 0);
+   config_id = ret;
+
+   /* Removing configs without permissions should fail. */
+   igt_fork(child, 1) {
+   igt_drop_root();
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG, 
_id, EACCES);
+   }
+   igt_waitchildren();
+
+   /* Removing invalid config ID should fail. */
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG, 
_config_id, ENOENT);
+
+   igt_assert(igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG, 
_id) == 0);
+}
+
+static void

[Intel-gfx] [PATCH i-g-t v3 3/5] lib/igt_draw: add support for Y tiling

2017-07-18 Thread Praveen Paneri
From: Paulo Zanoni 

From: Paulo Zanoni 

Most of the patch is to change the tile/untile functions so they can
work with Y-major tiling.

v2: (Praveen) No skipping on BLT for Y-tile now as we have a fix
 for that.

Reviewed-by: Praveen Paneri 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Praveen Paneri 
---
 lib/igt_draw.c | 171 -
 1 file changed, 121 insertions(+), 50 deletions(-)

diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index db55cd9..76ffb6c 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -135,71 +135,118 @@ static int swizzle_addr(int addr, int swizzle)
return addr;
 }
 
-/* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
- * if you need to. */
-static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int swizzle,
-  int bpp)
+static int tile(int x, int y, uint32_t x_tile_size, uint32_t y_tile_size,
+   uint32_t line_size, bool xmajor)
 {
-   int x_tile_size, y_tile_size;
-   int x_tile_n, y_tile_n, x_tile_off, y_tile_off;
-   int line_size, tile_size;
-   int tile_n, tile_off;
-   int tiled_pos, tiles_per_line;
-   int pixel_size = bpp / 8;
+   int tile_size, tiles_per_line, x_tile_n, y_tile_n, tile_off, pos;
+   int tile_n, x_tile_off, y_tile_off;
 
-   line_size = stride;
-   x_tile_size = 512;
-   y_tile_size = 8;
-   tile_size = x_tile_size * y_tile_size;
tiles_per_line = line_size / x_tile_size;
+   tile_size = x_tile_size * y_tile_size;
 
+   x_tile_n = x / x_tile_size;
y_tile_n = y / y_tile_size;
-   y_tile_off = y % y_tile_size;
+   tile_n = y_tile_n * tiles_per_line + x_tile_n;
 
-   x_tile_n = (x * pixel_size) / x_tile_size;
-   x_tile_off = (x * pixel_size) % x_tile_size;
+   x_tile_off = x % x_tile_size;
+   y_tile_off = y % y_tile_size;
 
-   tile_n = y_tile_n * tiles_per_line + x_tile_n;
-   tile_off = y_tile_off * x_tile_size + x_tile_off;
-   tiled_pos = tile_n * tile_size + tile_off;
+   if (xmajor)
+   tile_off = y_tile_off * x_tile_size + x_tile_off;
+   else
+   tile_off = x_tile_off * y_tile_size + y_tile_off;
 
-   tiled_pos = swizzle_addr(tiled_pos, swizzle);
+   pos = tile_n * tile_size + tile_off;
 
-   return tiled_pos / pixel_size;
+   return pos;
 }
 
-/* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
- * if you need to. */
-static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t stride,
-   int swizzle, int bpp, int *x, int *y)
+static void untile(int tiled_pos, int x_tile_size, int y_tile_size,
+  uint32_t line_size, bool xmajor, int *x, int *y)
 {
-   int tile_n, tile_off, tiles_per_line, line_size;
+   int tile_n, tile_off, tiles_per_line;
int x_tile_off, y_tile_off;
int x_tile_n, y_tile_n;
-   int x_tile_size, y_tile_size, tile_size;
-   int pixel_size = bpp / 8;
-
-   tiled_pos = swizzle_addr(tiled_pos, swizzle);
+   int tile_size;
 
-   line_size = stride;
-   x_tile_size = 512;
-   y_tile_size = 8;
tile_size = x_tile_size * y_tile_size;
tiles_per_line = line_size / x_tile_size;
 
tile_n = tiled_pos / tile_size;
tile_off = tiled_pos % tile_size;
 
-   y_tile_off = tile_off / x_tile_size;
-   x_tile_off = tile_off % x_tile_size;
+   if (xmajor) {
+   y_tile_off = tile_off / x_tile_size;
+   x_tile_off = tile_off % x_tile_size;
+   } else {
+   y_tile_off = tile_off % y_tile_size;
+   x_tile_off = tile_off / y_tile_size;
+   }
 
x_tile_n = tile_n % tiles_per_line;
y_tile_n = tile_n / tiles_per_line;
 
-   *x = (x_tile_n * x_tile_size + x_tile_off) / pixel_size;
+   *x = (x_tile_n * x_tile_size + x_tile_off);
*y = y_tile_n * y_tile_size + y_tile_off;
 }
 
+static int linear_x_y_to_xtiled_pos(int x, int y, uint32_t stride, int swizzle,
+   int bpp)
+{
+   int pos;
+   int pixel_size = bpp / 8;
+
+   x *= pixel_size;
+   pos = tile(x, y, 512, 8, stride, true);
+   pos = swizzle_addr(pos, swizzle);
+   return pos / pixel_size;
+}
+
+static int linear_x_y_to_ytiled_pos(int x, int y, uint32_t stride, int swizzle,
+   int bpp)
+{
+   int ow_tile_n, pos;
+   int ow_size = 16;
+   int pixel_size = bpp / 8;
+
+   /* We have an Y tiling of OWords, so use the tile() function to get the
+* OW number, then adjust to the fact that the OW may have more than one
+* pixel. */
+   x *= pixel_size;
+   ow_tile_n = tile(x / ow_size, y, 128 / ow_size, 32,
+

[Intel-gfx] [PATCH i-g-t v3 0/5] Add Y-tiling support into IGTs

2017-07-18 Thread Praveen Paneri
This series adds Y-tiled buffer creation support into IGT libraries and
goes on to use this capability to add support into FBC tests to use
Y-tiled buffers.

v2: Adressed review comments
v3: Included original patches from Paulo and addressed more comments

Paulo Zanoni (2):
  lib/igt_draw: add support for Y tiling
  tests/kms_draw_crc: add support for Y tiling

Praveen Paneri (3):
  lib/igt_fb: Let others use igt_get_fb_tile_size
  lib/igt_fb: Add helper function for tile_to_mod
  igt/kms_fbc_crc.c : Add Y-tile tests

 lib/igt_draw.c   | 171 ---
 lib/igt_fb.c |  41 +++-
 lib/igt_fb.h |   3 +
 tests/kms_draw_crc.c |  55 -
 tests/kms_fbc_crc.c  |  73 +-
 5 files changed, 246 insertions(+), 97 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH i-g-t v3 1/5] lib/igt_fb: Let others use igt_get_fb_tile_size

2017-07-18 Thread Praveen Paneri
From: Praveen Paneri 

This function can be used by igt_draw to get accurate
tile dimensions for all tile formats.

v2: Added comments to function igt_get_fb_tile_size (Daniel)
v3: Fixed errors in comments and coding style (Paulo)

Signed-off-by: Praveen Paneri 
---
 lib/igt_fb.c | 15 +--
 lib/igt_fb.h |  2 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index d2b7e9e..c94f95e 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -74,8 +74,19 @@ static struct format_desc_struct {
 #define for_each_format(f) \
for (f = format_desc; f - format_desc < ARRAY_SIZE(format_desc); f++)
 
-static void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
-unsigned *width_ret, unsigned *height_ret)
+/**
+ * igt_get_fb_tile_size:
+ * @fd: the DRM file descriptor
+ * @tiling: tiling layout of the framebuffer (as framebuffer modifier)
+ * @fb_bpp: bits per pixel of the framebuffer
+ * @width_ret: width of the tile in bytes
+ * @height_ret: height of the tile in lines
+ *
+ * This function returns width and height of a tile based on the given tiling
+ * format.
+ */
+void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
+ unsigned *width_ret, unsigned *height_ret)
 {
switch (tiling) {
case LOCAL_DRM_FORMAT_MOD_NONE:
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 4a680ce..010ed3a 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -95,6 +95,8 @@ enum igt_text_align {
align_hcenter   = 0x08,
 };
 
+void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
+ unsigned *width_ret, unsigned *height_ret);
 void igt_calc_fb_size(int fd, int width, int height, int bpp, uint64_t tiling,
  unsigned *size_ret, unsigned *stride_ret);
 unsigned int
-- 
1.9.1

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


[Intel-gfx] [PATCH i-g-t v3 5/5] igt/kms_fbc_crc.c : Add Y-tile tests

2017-07-18 Thread Praveen Paneri
From: Praveen Paneri 

Now that we have support for Y-tiled buffers, add another
iteration of tests for Y-tiled buffers.

v3:
 - Iterate over tiling modifier instead of tiling constant (Paulo)
 - Improved logging and fixed indentation (Paulo)

Signed-off-by: Praveen Paneri 
---
 tests/kms_fbc_crc.c | 69 ++---
 1 file changed, 44 insertions(+), 25 deletions(-)

diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 7964e05..74debfb 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -318,12 +318,10 @@ static void prepare_crtc(data_t *data)
igt_output_set_pipe(output, data->pipe);
 }
 
-static void create_fbs(data_t *data, bool tiled, struct igt_fb *fbs)
+static void create_fbs(data_t *data, uint64_t tiling, struct igt_fb *fbs)
 {
int rc;
drmModeModeInfo *mode = igt_output_get_mode(data->output);
-   uint64_t tiling = tiled ? LOCAL_I915_FORMAT_MOD_X_TILED :
- LOCAL_DRM_FORMAT_MOD_NONE;
 
rc = igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
 DRM_FORMAT_XRGB, tiling,
@@ -344,8 +342,8 @@ static void get_ref_crcs(data_t *data)
struct igt_fb fbs[4];
int i;
 
-   create_fbs(data, false, [0]);
-   create_fbs(data, false, [2]);
+   create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, [0]);
+   create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, [2]);
 
fill_mmap_gtt(data, fbs[2].gem_handle, 0xff);
fill_mmap_gtt(data, fbs[3].gem_handle, 0xff);
@@ -366,7 +364,7 @@ static void get_ref_crcs(data_t *data)
igt_remove_fb(data->drm_fd, [i]);
 }
 
-static bool prepare_test(data_t *data, enum test_mode test_mode)
+static bool prepare_test(data_t *data, enum test_mode test_mode, uint64_t 
tiling)
 {
igt_display_t *display = >display;
igt_output_t *output = data->output;
@@ -374,7 +372,7 @@ static bool prepare_test(data_t *data, enum test_mode 
test_mode)
 
data->primary = igt_output_get_plane_type(data->output, 
DRM_PLANE_TYPE_PRIMARY);
 
-   create_fbs(data, true, data->fb);
+   create_fbs(data, tiling, data->fb);
 
igt_pipe_crc_free(data->pipe_crc);
data->pipe_crc = NULL;
@@ -475,6 +473,7 @@ static void run_test(data_t *data, enum test_mode mode)
 {
igt_display_t *display = >display;
int valid_tests = 0;
+   uint64_t tiling_methods[] = {LOCAL_I915_FORMAT_MOD_X_TILED, 
LOCAL_I915_FORMAT_MOD_Y_TILED};
 
if (mode == TEST_CONTEXT || mode == TEST_PAGE_FLIP_AND_CONTEXT) {
drm_intel_context *ctx = 
drm_intel_gem_context_create(data->bufmgr);
@@ -484,32 +483,52 @@ static void run_test(data_t *data, enum test_mode mode)
 
reset_display(data);
 
-   for_each_pipe_with_valid_output(display, data->pipe, data->output) {
-   prepare_crtc(data);
+   for (int i=0; i < (sizeof(tiling_methods)/sizeof(tiling_methods[0]));
+i++) {
+   uint64_t tiling = tiling_methods[i];
 
-   igt_info("Beginning %s on pipe %s, connector %s\n",
- igt_subtest_name(),
- kmstest_pipe_name(data->pipe),
- igt_output_name(data->output));
+   if(intel_gen(intel_get_drm_devid(data->drm_fd)) < 9 &&
+   tiling == LOCAL_I915_FORMAT_MOD_Y_TILED) {
+   igt_info("Y-tiling not supported for this platform\n");
+   continue;
+   }
+
+   for_each_pipe_with_valid_output(display,
+   data->pipe, data->output) {
+   const char *tiling_name =
+   (tiling == 
LOCAL_I915_FORMAT_MOD_Y_TILED) ? "x":"y";
+   prepare_crtc(data);
 
-   if (!prepare_test(data, mode)) {
-   igt_info("%s on pipe %s, connector %s: SKIPPED\n",
+   igt_info("Beginning %s on pipe %s, connector "
+ "%s, %s-tiled\n",
  igt_subtest_name(),
  kmstest_pipe_name(data->pipe),
- igt_output_name(data->output));
-   continue;
-   }
+ igt_output_name(data->output),
+ tiling_name);
 
-   valid_tests++;
+   if (!prepare_test(data, mode, tiling)) {
+   igt_info("%s on pipe %s, connector "
+ "%s, %s-tiled: SKIPPED\n",
+ igt_subtest_name(),
+ kmstest_pipe_name(data->pipe),
+ igt_output_name(data->output),
+ 

[Intel-gfx] [PATCH i-g-t v3 4/5] tests/kms_draw_crc: add support for Y tiling

2017-07-18 Thread Praveen Paneri
From: Paulo Zanoni 

From: Paulo Zanoni 

This is the program that's supposed to test lib/igt_draw. We just
added Y tiling support for the library, so add the tests now.

Reviewed-by: Praveen Paneri 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Praveen Paneri 
---
 tests/kms_draw_crc.c | 55 ++--
 1 file changed, 40 insertions(+), 15 deletions(-)

diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index c57d3a3..906d89f 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -47,6 +47,13 @@ static const uint32_t formats[N_FORMATS] = {
DRM_FORMAT_XRGB2101010,
 };
 
+#define N_TILING_METHODS 3
+static const uint64_t tilings[N_TILING_METHODS] = {
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   LOCAL_I915_FORMAT_MOD_X_TILED,
+   LOCAL_I915_FORMAT_MOD_Y_TILED,
+};
+
 struct base_crc {
bool set;
igt_crc_t crc;
@@ -151,6 +158,9 @@ static void draw_method_subtest(enum igt_draw_method method,
 {
igt_crc_t crc;
 
+   if (tiling == LOCAL_I915_FORMAT_MOD_Y_TILED)
+   igt_require(intel_gen(intel_get_drm_devid(drm_fd)) >= 9);
+
/* Use IGT_DRAW_MMAP_GTT on an untiled buffer as the parameter for
 * comparison. Cache the value so we don't recompute it for every single
 * subtest. */
@@ -208,6 +218,11 @@ static void fill_fb_subtest(void)
get_fill_crc(LOCAL_I915_FORMAT_MOD_X_TILED, );
igt_assert_crc_equal(, _crc);
 
+   if (intel_gen(intel_get_drm_devid(drm_fd)) >= 9) {
+   get_fill_crc(LOCAL_I915_FORMAT_MOD_Y_TILED, );
+   igt_assert_crc_equal(, _crc);
+   }
+
igt_remove_fb(drm_fd, );
 }
 
@@ -265,28 +280,38 @@ static const char *format_str(int format_index)
}
 }
 
+static const char *tiling_str(int tiling_index)
+{
+   switch (tilings[tiling_index]) {
+   case LOCAL_DRM_FORMAT_MOD_NONE:
+   return "untiled";
+   case LOCAL_I915_FORMAT_MOD_X_TILED:
+   return "xtiled";
+   case LOCAL_I915_FORMAT_MOD_Y_TILED:
+   return "ytiled";
+   default:
+   igt_assert(false);
+   }
+}
+
 igt_main
 {
enum igt_draw_method method;
-   int format_index;
+   int format_idx, tiling_idx;
 
igt_fixture
setup_environment();
 
-   for (format_index = 0; format_index < N_FORMATS; format_index++) {
-   for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
-   igt_subtest_f("draw-method-%s-%s-untiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
-   draw_method_subtest(method, format_index,
-   LOCAL_DRM_FORMAT_MOD_NONE);
-   igt_subtest_f("draw-method-%s-%s-tiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
-   draw_method_subtest(method, format_index,
-   LOCAL_I915_FORMAT_MOD_X_TILED);
-   }
-   }
+   for (format_idx = 0; format_idx < N_FORMATS; format_idx++) {
+   for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
+   for (tiling_idx = 0; tiling_idx < N_TILING_METHODS; tiling_idx++) {
+   igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+   draw_method_subtest(method, format_idx,
+   tilings[tiling_idx]);
+   } } }
 
igt_subtest("fill-fb")
fill_fb_subtest();
-- 
1.9.1

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


[Intel-gfx] [PATCH i-g-t v3 2/5] lib/igt_fb: Add helper function for tile_to_mod

2017-07-18 Thread Praveen Paneri
From: Praveen Paneri 

igt_get_fb_tile_size function takes modifer as an argument
This helper function will let users to convert tiling to
modifier and use igt_get_fb_tile_size()

v2: Improved code comment (Paulo)

Signed-off-by: Praveen Paneri 
---
 lib/igt_fb.c | 26 ++
 lib/igt_fb.h |  1 +
 2 files changed, 27 insertions(+)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index c94f95e..042b413 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -217,6 +217,32 @@ uint64_t igt_fb_mod_to_tiling(uint64_t modifier)
}
 }
 
+/**
+ * igt_fb_tiling_to_mod:
+ * @tiling: DRM framebuffer tiling
+ *
+ * This function converts a DRM framebuffer tiling to its corresponding
+ * modifier constant.
+ *
+ * Returns:
+ * A modifier constant
+ */
+uint64_t igt_fb_tiling_to_mod(uint64_t tiling)
+{
+   switch (tiling) {
+   case I915_TILING_NONE:
+   return LOCAL_DRM_FORMAT_MOD_NONE;
+   case I915_TILING_X:
+   return LOCAL_I915_FORMAT_MOD_X_TILED;
+   case I915_TILING_Y:
+   return LOCAL_I915_FORMAT_MOD_Y_TILED;
+   case I915_TILING_Yf:
+   return LOCAL_I915_FORMAT_MOD_Yf_TILED;
+   default:
+   igt_assert(0);
+   }
+}
+
 /* helpers to create nice-looking framebuffers */
 static int create_bo_for_fb(int fd, int width, int height, uint32_t format,
uint64_t tiling, unsigned size, unsigned stride,
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 010ed3a..9b8ec8a 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -132,6 +132,7 @@ int igt_create_bo_with_dimensions(int fd, int width, int 
height, uint32_t format
  bool *is_dumb);
 
 uint64_t igt_fb_mod_to_tiling(uint64_t modifier);
+uint64_t igt_fb_tiling_to_mod(uint64_t tiling);
 
 /* cairo-based painting */
 cairo_t *igt_get_cairo_ctx(int fd, struct igt_fb *fb);
-- 
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 Add support for loadable OA configs

2017-07-18 Thread Patchwork
== Series Details ==

Series: Add support for loadable OA configs
URL   : https://patchwork.freedesktop.org/series/27501/
State : success

== Summary ==

Series 27501v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27501/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-r) k.org#196399
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781

k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:426s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:424s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:355s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:479s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:483s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:496s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:579s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:398s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:450s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:556s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:564s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:558s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:441s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:570s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:627s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:458s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:428s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:482s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:411s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
f6f2f20 drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
ff05eb6 drm/i915/perf: prune OA configs
7dbcc95 drm/i915/perf: fix flex eu registers programming

== Logs ==

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


[Intel-gfx] [PATCH v6 0/3] Add support for loadable OA configs

2017-07-18 Thread Lionel Landwerlin
Hi,

Here is a v6 of this series.

There are a bunch of fixes pointed out by Matthew in patch 3.

There was also a pretty big issue in v5 of patch 2, I dropped some
calls to function programming OACTXCONTROL on shutting down the perf
stream and that triggered failures in the oa-exponents IGT test. This
is now fixed and the tests are back to stable. OACTXCONTROL is now,
again, always reprogrammed on open/close of the stream.

Many thanks to Matthew for his time.

Cheers,

Lionel Landwerlin (3):
  drm/i915/perf: fix flex eu registers programming
  drm/i915/perf: prune OA configs
  drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

 drivers/gpu/drm/i915/i915_drv.c   |2 +
 drivers/gpu/drm/i915/i915_drv.h   |   92 +-
 drivers/gpu/drm/i915/i915_oa_bdw.c| 5360 +
 drivers/gpu/drm/i915/i915_oa_bdw.h|8 +-
 drivers/gpu/drm/i915/i915_oa_bxt.c| 2623 +---
 drivers/gpu/drm/i915/i915_oa_bxt.h|8 +-
 drivers/gpu/drm/i915/i915_oa_chv.c| 2806 +
 drivers/gpu/drm/i915/i915_oa_chv.h|8 +-
 drivers/gpu/drm/i915/i915_oa_glk.c| 2535 +---
 drivers/gpu/drm/i915/i915_oa_glk.h|8 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c|  764 +
 drivers/gpu/drm/i915/i915_oa_hsw.h|8 +-
 drivers/gpu/drm/i915/i915_oa_kblgt2.c | 2971 +-
 drivers/gpu/drm/i915/i915_oa_kblgt2.h |8 +-
 drivers/gpu/drm/i915/i915_oa_kblgt3.c | 3020 +--
 drivers/gpu/drm/i915/i915_oa_kblgt3.h |8 +-
 drivers/gpu/drm/i915/i915_oa_sklgt2.c | 3458 +
 drivers/gpu/drm/i915/i915_oa_sklgt2.h |8 +-
 drivers/gpu/drm/i915/i915_oa_sklgt3.c | 3019 +--
 drivers/gpu/drm/i915/i915_oa_sklgt3.h |8 +-
 drivers/gpu/drm/i915/i915_oa_sklgt4.c | 3073 +--
 drivers/gpu/drm/i915/i915_oa_sklgt4.h |8 +-
 drivers/gpu/drm/i915/i915_perf.c  |  735 +++--
 drivers/gpu/drm/i915/i915_reg.h   |2 +
 include/uapi/drm/i915_drm.h   |   24 +
 25 files changed, 988 insertions(+), 29576 deletions(-)

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


[Intel-gfx] [PATCH v6 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

2017-07-18 Thread Lionel Landwerlin
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.

v2: Drop DRM_ERROR for userspace errors (Matthew)
Add padding to userspace structure (Matthew)
s/guid/uuid/ (Matthew)

v3: Use u32 instead of int to iterate through registers (Matthew)

v4: Lock access to dynamic config list (Lionel)

v5: by Matthew:
Fix uninitialized error values
Fix incorrect unwiding when opening perf stream
Use kmalloc_array() to store register
Use uuid_is_valid() to valid config uuids
Declare ioctls as write only
Check padding members are set to 0
by Lionel:
Return ENOENT rather than EINVAL when trying to remove non
existing config

Signed-off-by: Matthew Auld 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Andrzej Datczuk 
---
 drivers/gpu/drm/i915/i915_drv.c  |   2 +
 drivers/gpu/drm/i915/i915_drv.h  |  48 
 drivers/gpu/drm/i915/i915_perf.c | 488 +++
 drivers/gpu/drm/i915/i915_reg.h  |   2 +
 include/uapi/drm/i915_drm.h  |  24 ++
 5 files changed, 513 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..a3d339670ec1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b824f8875c4..607484737f3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1917,6 +1917,9 @@ struct i915_oa_config {
struct attribute_group sysfs_metric;
struct attribute *attrs[2];
struct device_attribute sysfs_metric_id;
+
+   /* Only updated while holding dev_priv->perf.metrics_lock. */
+   bool in_use;
 };
 
 struct i915_perf_stream;
@@ -2043,6 +2046,25 @@ struct i915_perf_stream {
  */
 struct i915_oa_ops {
/**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+   bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+  u32 addr);
+
+   /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+   bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+   bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
 * @init_oa_buffer: Resets the head and tail pointers of the
 * circular buffer for periodic OA reports.
 *
@@ -2430,10 +2452,32 @@ struct drm_i915_private {
struct kobject *metrics_kobj;
struct ctl_table_header *sysctl_header;
 
+   /*
+* Lock associated with adding/modifying/removing OA configs
+* in dev_priv->perf.metrics_idr.
+*/
+   struct mutex metrics_lock;
+
+   /*
+* List of dynamic configurations, you need to hold
+* dev_priv->perf.metrics_lock to access it.
+*/
+   struct idr metrics_idr;
+
+   /*
+* Lock associated with anything below within this structure
+* except exclusive_stream.
+*/
struct mutex lock;
struct list_head streams;
 
struct {
+   /*
+* The stream currently using the OA unit. If accessed
+* outside a syscall associated to its file
+* descriptor, you need to hold
+* dev_priv->drm.struct_mutex.
+*/
struct i915_perf_stream *exclusive_stream;
 
u32 specific_ctx_id;
@@ -3599,6 +3643,10 @@ 

[Intel-gfx] [PATCH v6 1/3] drm/i915/perf: fix flex eu registers programming

2017-07-18 Thread Lionel Landwerlin
We were reserving fewer dwords in the ring than necessary. Indeed
we're always writing all registers once, so discard the actual number
of registers given by the user and just program the whitelisted ones
once.

Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+")
Reported-by: Matthew Auld 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld 
Cc:  # v4.12+
---
 drivers/gpu/drm/i915/i915_perf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 96682fd86f82..df78bfa9e574 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1601,11 +1601,11 @@ static int gen8_emit_oa_config(struct 
drm_i915_gem_request *req)
u32 *cs;
int i;
 
-   cs = intel_ring_begin(req, n_flex_regs * 2 + 4);
+   cs = intel_ring_begin(req, ARRAY_SIZE(flex_mmio) * 2 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   *cs++ = MI_LOAD_REGISTER_IMM(n_flex_regs + 1);
+   *cs++ = MI_LOAD_REGISTER_IMM(ARRAY_SIZE(flex_mmio) + 1);
 
*cs++ = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
*cs++ = (dev_priv->perf.oa.period_exponent << 
GEN8_OA_TIMER_PERIOD_SHIFT) |
-- 
2.13.2

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


Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

2017-07-18 Thread Lyude Paul
Acked-by: Lyude 

On Tue, 2017-07-18 at 18:00 +0200, Daniel Vetter wrote:
> There's a bunch of reasons why I think we should formalize and
> enforce
> our review rules for igt patches:
> 
> - We have a lot of new engineers joining and review helps enormously
>   with mentoring and learning. But right now only patches from
>   contributors without commit rights are consistently subjected to
>   review, which makes this imbalanced and removes senior contributors
>   from the review pool.
> 
> - We have a much bigger team and we need to make sure we're aligned
> on
>   where igt as a tool and testsuite needs to head towards. Getting
>   that alignment happens through reviewing each other's submission.
>   Pushing a contentious patch and then dealing with a heated irc
>   discussion is much less effective.
> 
> - Finally igt becomes ever more important for our testing, making
> sure
>   the code quality is high is important. Review helps with that.
> 
> v2: Improve wording a bit (Imre).
> 
> Acked-by: Daniel Stone 
> Acked-by: Jani Nikula 
> Acked-by: Joonas Lahtinen 
> Acked-by: Maarten Lankhorst 
> Acked-by: Petri Latvala 
> Acked-by: Imre Deak 
> Acked-by: Robert Foss 
> Acked-by: Ben Widawsky 
> Acked-by: Tvrtko Ursulin 
> Acked-by: Mika Kuoppala 
> Signed-off-by: Daniel Vetter 
> ---
>  CONTRIBUTING | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index d2adcf03b7c3..561c5dd80bba 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -26,10 +26,11 @@ A short list of contribution guidelines:
>convenience macros provided by the igt library. The semantic patch
> lib/igt.cocci
>can help with the more automatic conversions.
>  
> -- There is no formal review requirement and regular contributors
> with commit
> -  access can push patches right after submitting them to the mailing
> lists. But
> -  invasive changes, new helper libraries and contributions from
> newcomers should
> -  go through a proper review to ensure overall consistency in the
> codebase.
> +- Patches need to be reviewed on the mailing list. Exceptions only
> apply for
> +  testcases and tooling for drivers with just a single contributor
> (e.g. vc4).
> +  In this case patches must still be submitted to the mailing list
> first.
> +  Testcase should preferrably be cross-reviewed by the same people
> who write and
> +  review the kernel feature itself.
>  
>  - When patches from new contributors (without commit access) are
> stuck, for
>anything related to the regular releases, issues with packaging
> and
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

2017-07-18 Thread Daniel Vetter
There's a bunch of reasons why I think we should formalize and enforce
our review rules for igt patches:

- We have a lot of new engineers joining and review helps enormously
  with mentoring and learning. But right now only patches from
  contributors without commit rights are consistently subjected to
  review, which makes this imbalanced and removes senior contributors
  from the review pool.

- We have a much bigger team and we need to make sure we're aligned on
  where igt as a tool and testsuite needs to head towards. Getting
  that alignment happens through reviewing each other's submission.
  Pushing a contentious patch and then dealing with a heated irc
  discussion is much less effective.

- Finally igt becomes ever more important for our testing, making sure
  the code quality is high is important. Review helps with that.

v2: Improve wording a bit (Imre).

Acked-by: Daniel Stone 
Acked-by: Jani Nikula 
Acked-by: Joonas Lahtinen 
Acked-by: Maarten Lankhorst 
Acked-by: Petri Latvala 
Acked-by: Imre Deak 
Acked-by: Robert Foss 
Acked-by: Ben Widawsky 
Acked-by: Tvrtko Ursulin 
Acked-by: Mika Kuoppala 
Signed-off-by: Daniel Vetter 
---
 CONTRIBUTING | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index d2adcf03b7c3..561c5dd80bba 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -26,10 +26,11 @@ A short list of contribution guidelines:
   convenience macros provided by the igt library. The semantic patch 
lib/igt.cocci
   can help with the more automatic conversions.
 
-- There is no formal review requirement and regular contributors with commit
-  access can push patches right after submitting them to the mailing lists. But
-  invasive changes, new helper libraries and contributions from newcomers 
should
-  go through a proper review to ensure overall consistency in the codebase.
+- Patches need to be reviewed on the mailing list. Exceptions only apply for
+  testcases and tooling for drivers with just a single contributor (e.g. vc4).
+  In this case patches must still be submitted to the mailing list first.
+  Testcase should preferrably be cross-reviewed by the same people who write 
and
+  review the kernel feature itself.
 
 - When patches from new contributors (without commit access) are stuck, for
   anything related to the regular releases, issues with packaging and
-- 
2.13.2

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


Re: [Intel-gfx] [PATCH v2 0/5] x86/io: Rely on asm-generic/io.h

2017-07-18 Thread Andy Shevchenko
On Fri, 2017-06-30 at 20:09 +0300, Andy Shevchenko wrote:
> The series brings a bit of order to arch/x86/include/asm/io.h by re-
> using
> definitions in the generic header.
> 
> The series has been tested on Intel Broxton hardware in 32- and 64-bit 
> modes.

Any comments?
Shall I resend this?

> 
> Since v2:
> - add cleanup patches in accordance to re-use what's defined in
> generic header
> - split to few patches
> - hopefully nail down an issue kbuild bot complained about
> - append tags (Wolfram)
> 
> Andy Shevchenko (5):
>   x86/io: Define IO accessors by preprocessor
>   x86/io: Include asm-generic/io.h to architectural code
>   x86/io: Remove mem*io() duplications
>   x86/io: Remove xlate_dev_kmem_ptr() duplication
>   x86/io: Make readq() / writeq() API consistent
> 
>  arch/x86/include/asm/io.h | 98 +++---
> -
>  include/asm-generic/io.h  | 27 +
>  2 files changed, 74 insertions(+), 51 deletions(-)
> 

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


Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

2017-07-18 Thread Chris Wilson
Quoting Tvrtko Ursulin (2017-07-18 15:36:16)
> +int intel_enable_engine_stats(struct drm_i915_private *dev_priv)
> +{
> +   if (!i915.enable_execlists)
> +   return -ENODEV;
> +
> +   mutex_lock(_engine_stats_mutex);
> +   if (i915_engine_stats_ref++ == 0) {
> +   struct intel_engine_cs *engine;
> +   enum intel_engine_id id;
> +
> +   for_each_engine(engine, dev_priv, id) {
> +   memset(>stats, 0, sizeof(engine->stats));
> +   spin_lock_init(>stats.lock);
> +   }
> +
> +   static_branch_enable(_engine_stats_key);
> +   }
> +   mutex_unlock(_engine_stats_mutex);

I don't think static_branch_enable() is a might_sleep, so it looks like
you can rewrite this avoiding the mutex and thus not requiring the
worker and then can use the error code here to decide if you need to
use the timer instead.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

2017-07-18 Thread Chris Wilson
Quoting Tvrtko Ursulin (2017-07-18 15:36:16)
> +u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine)
> +{
> +   unsigned long flags;
> +   u64 total;
> +
> +   spin_lock_irqsave(>stats.lock, flags);
> +
> +   total = engine->stats.total;
> +
> +   /*
> +* If the engine is executing something at the moment
> +* add it to the total.
> +*/
> +   if (engine->stats.ref)
> +   total += ktime_get_real_ns() - engine->stats.start;
> +
> +   spin_unlock_irqrestore(>stats.lock, flags);

Answers to another patch found here. I would say this is the other half
of the interface and should be kept together.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC 11/14] drm/i915: Engine busy time tracking

2017-07-18 Thread Chris Wilson
Quoting Tvrtko Ursulin (2017-07-18 15:36:15)
> From: Tvrtko Ursulin 
> 
> Track total time requests have been executing on the hardware.
> 
> To make this cheap it is hidden behind a static branch with the
> intention that it is only enabled when there is a consumer
> listening. This means that in the default off case the total
> cost of the tracking is just a few no-op instructions on the
> fast paths.

> +static inline void intel_engine_context_in(struct intel_engine_cs *engine)
> +{
> +   if (static_branch_unlikely(_engine_stats_key)) {
> +   unsigned long flags;
> +
> +   spin_lock_irqsave(>stats.lock, flags);

What's the purpose of this lock? RMW is ordered by virtue of the tasklet
(only one cpu can be doing the rmw at any time). Did I miss another
user?

> +   if (engine->stats.ref++ == 0)
> +   engine->stats.start = ktime_get_real_ns();

Use ktime_get_raw() and leave the conversion to ns to the caller.
What is the cost of a ktime nowadays?

How do you handle the currently active case when reporting? Imagine a
continuous stream of requests, hoping between contexts without a
break.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Catch and flush hotplug uevents after each plug

2017-07-18 Thread Paul Kocialkowski
This adds calls to igt_hotplug_detected and igt_flush_hotplugs to catch
and flush hotplugs from connector unplug (due to chamelium reset) and
plug. These need to be intercepted so that they are not delayed and
issued after resume, providing a false positive for the test result.

In addition, the final hotplug uevent flush is brought closer to the
suspend call, to decrease the likeliness of false positive.

However, false positives still do happen, because it is not possible to
make sure that the uevent caused by each connector's state change was
caught instead of being delayed and issued at resume time.

Signed-off-by: Paul Kocialkowski 
---
 tests/chamelium.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tests/chamelium.c b/tests/chamelium.c
index 8af33aaa..0528ffb3 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -340,12 +340,16 @@ test_suspend_resume_edid_change(data_t *data, struct 
chamelium_port *port,
 
reset_state(data, port);
 
+   /* Catch the event and flush all remaining ones. */
+   igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
+   igt_flush_hotplugs(mon);
+
/* First plug in the port */
chamelium_port_set_edid(data->chamelium, port, edid_id);
chamelium_plug(data->chamelium, port);
-   wait_for_connector(data, port, DRM_MODE_CONNECTED);
+   igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
 
-   igt_flush_hotplugs(mon);
+   wait_for_connector(data, port, DRM_MODE_CONNECTED);
 
/*
 * Change the edid before we suspend. On resume, the machine should
@@ -355,6 +359,8 @@ test_suspend_resume_edid_change(data_t *data, struct 
chamelium_port *port,
 
get_connectors_link_status_failed(data, link_status_failed[0]);
 
+   igt_flush_hotplugs(mon);
+
igt_system_suspend_autoresume(state, test);
 
igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
-- 
2.13.2

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


[Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

2017-07-18 Thread Paul Kocialkowski
It may occur that a hotplug uevent is detected at resume, even though it
does not indicate that an actual hotplug happened. This is the case when
link training fails on any other connector.

There is currently no way to distinguish what connector caused a hotplug
uevent, nor what the reason for that uevent really is. This makes it
impossible to find out whether the test actually passed or not.

To circumvent this problem, the link status of each connector is
collected before and after suspend and compared to skip the test if
the state was good before and turned to bad after resume.

This only concerns the EDID change test, where we cannot check the
connector state (that is not supposed to have changed). For actual
hotplug tests, the tests should be safe since they check each
connector's state after receiving the uevent.

The situation described here happens with DP-VGA bridges that fail link
training after resume, as they need some more time to response on their
AUX channel.

Signed-off-by: Paul Kocialkowski 
---
 tests/chamelium.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/tests/chamelium.c b/tests/chamelium.c
index e26f0557..8af33aaa 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -87,6 +87,31 @@ get_precalculated_crc(struct chamelium_port *port, int w, 
int h)
 }
 
 static void
+get_connectors_link_status_failed(data_t *data, bool *link_status_failed)
+{
+   drmModeConnector *connector;
+   uint64_t link_status;
+   drmModePropertyPtr prop;
+   int p;
+
+   for (p = 0; p < data->port_count; p++) {
+   connector = chamelium_port_get_connector(data->chamelium,
+data->ports[p], false);
+
+   igt_assert(kmstest_get_property(data->drm_fd,
+   connector->connector_id,
+   DRM_MODE_OBJECT_CONNECTOR,
+   "link-status", NULL,
+   _status, ));
+
+   link_status_failed[p] = link_status == DRM_MODE_LINK_STATUS_BAD;
+
+   drmModeFreeProperty(prop);
+   drmModeFreeConnector(connector);
+   }
+}
+
+static void
 require_connector_present(data_t *data, unsigned int type)
 {
int i;
@@ -310,6 +335,8 @@ test_suspend_resume_edid_change(data_t *data, struct 
chamelium_port *port,
int alt_edid_id)
 {
struct udev_monitor *mon = igt_watch_hotplug();
+   bool link_status_failed[2][data->port_count];
+   int p;
 
reset_state(data, port);
 
@@ -326,8 +353,16 @@ test_suspend_resume_edid_change(data_t *data, struct 
chamelium_port *port,
 */
chamelium_port_set_edid(data->chamelium, port, alt_edid_id);
 
+   get_connectors_link_status_failed(data, link_status_failed[0]);
+
igt_system_suspend_autoresume(state, test);
+
igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
+
+   get_connectors_link_status_failed(data, link_status_failed[1]);
+
+   for (p = 0; p < data->port_count; p++)
+   igt_skip_on(!link_status_failed[0][p] && 
link_status_failed[1][p]);
 }
 
 static igt_output_t *
-- 
2.13.2

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


[Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

2017-07-18 Thread Paul Kocialkowski
It may occur that a hotplug uevent is detected at resume, even though it
does not indicate that an actual hotplug happened. This is the case when
link training fails on any other connector.

There is currently no way to distinguish what connector caused a hotplug
uevent, nor what the reason for that uevent really is. This makes it
impossible to find out whether the test actually passed or not.

To circumvent this problem, the link status of each connector is
collected before and after suspend and compared to skip the test if
the state was good before and turned to bad after resume.

This only concerns the EDID change test, where we cannot check the
connector state (that is not supposed to have changed). For actual
hotplug tests, the tests should be safe since they check each
connector's state after receiving the uevent.

The situation described here happens with DP-VGA bridges that fail link
training after resume, as they need some more time to response on their
AUX channel.

Signed-off-by: Paul Kocialkowski 
---
 tests/chamelium.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/tests/chamelium.c b/tests/chamelium.c
index e26f0557..8af33aaa 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -87,6 +87,31 @@ get_precalculated_crc(struct chamelium_port *port, int w, 
int h)
 }
 
 static void
+get_connectors_link_status_failed(data_t *data, bool *link_status_failed)
+{
+   drmModeConnector *connector;
+   uint64_t link_status;
+   drmModePropertyPtr prop;
+   int p;
+
+   for (p = 0; p < data->port_count; p++) {
+   connector = chamelium_port_get_connector(data->chamelium,
+data->ports[p], false);
+
+   igt_assert(kmstest_get_property(data->drm_fd,
+   connector->connector_id,
+   DRM_MODE_OBJECT_CONNECTOR,
+   "link-status", NULL,
+   _status, ));
+
+   link_status_failed[p] = link_status == DRM_MODE_LINK_STATUS_BAD;
+
+   drmModeFreeProperty(prop);
+   drmModeFreeConnector(connector);
+   }
+}
+
+static void
 require_connector_present(data_t *data, unsigned int type)
 {
int i;
@@ -310,6 +335,8 @@ test_suspend_resume_edid_change(data_t *data, struct 
chamelium_port *port,
int alt_edid_id)
 {
struct udev_monitor *mon = igt_watch_hotplug();
+   bool link_status_failed[2][data->port_count];
+   int p;
 
reset_state(data, port);
 
@@ -326,8 +353,16 @@ test_suspend_resume_edid_change(data_t *data, struct 
chamelium_port *port,
 */
chamelium_port_set_edid(data->chamelium, port, alt_edid_id);
 
+   get_connectors_link_status_failed(data, link_status_failed[0]);
+
igt_system_suspend_autoresume(state, test);
+
igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
+
+   get_connectors_link_status_failed(data, link_status_failed[1]);
+
+   for (p = 0; p < data->port_count; p++)
+   igt_skip_on(!link_status_failed[0][p] && 
link_status_failed[1][p]);
 }
 
 static igt_output_t *
-- 
2.13.2

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


[Intel-gfx] [PATCH i-g-t 0/2] Unrelated hotplug uevent masking out actual test result

2017-07-18 Thread Paul Kocialkowski
This patch introduces a workaround for a case where a uevent is issued
by the kernel because of DP link training failing on a connector
unrelated to the current test. Since the test depends on receiving a
hotplug uevent, it previously passed even though it should not have.

False positives also occur due to the plug/unplug events being delayed
and issued at resume time. This is mitigated by catching and flushing
hotplugs everytime a change is made on connectors, but it is not enough
to ensure that all hotplug events were caught and not delayed.

The problem here is that it is not possible to find out the exact reason
why a uevent is issued by the kernel. A possible way to fix this would
be to introduce more fields (the connector name and some reason why the
event is triggered would probably be sufficient).

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


Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

2017-07-18 Thread Oscar Mateo




On 07/14/2017 08:08 AM, Chris Wilson wrote:

Quoting Oscar Mateo (2017-07-14 15:52:59)



On 07/13/2017 03:28 PM, Rodrigo Vivi wrote:

On Wed, May 3, 2017 at 9:31 AM, Chris Wilson  wrote:

On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote:

 On 05/03/2017 08:52 AM, Mika Kuoppala wrote:

   Oscar Mateo [1] writes:


   On 05/02/2017 09:17 AM, Mika Kuoppala wrote:

   Chris Wilson [2] writes:


   On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote:

   The new batchbuffer for CNL surpasses the 4096 byte mark.

   Cc: Mika Kuoppala [3]
   Cc: Ben Widawsky [4]
   Signed-off-by: Oscar Mateo [5]

   Evil, 4k+ of nothing-ness that userspace then has to configure for itself
   for correctness anyway.

   Patch looks ok, but still question the sanity.

   Is there a requirement for CNL to init the renderstate?

   I would like to drop the render state init from CNL if
   we can't find evidence that it needs it. Bspec indicates
   that it doesnt.

I'd like to drop as well, and I was hearing people around telling we
didn't need anymore,
however without this during power on I had bad failures...


The best I could get from architecture (+Raf) is that setting valid and
coherent values for the whole render state is required as soon as the
context is created, no matter who does it. If you see failures when the
KMD does not do it, that means the UMD must be missing something, right?

That is my initial response as well. The kernel does load one context,
just so that the hardware always has space to write to on power saving.
The only batch executed for it is the golden render state. Easy enough
to only initialise that kernel context to isolate whether it is
self-inflicted or that userspace overlooked something in its state
management. (I have the view that even if userspace doesn't think it
needs to use a particular bit of state today, tomorrow it will so will
need it anyway!)
-Chris


Rodrigo, you have access to a CNL: can you make this test? The idea is 
to find out if the root cause for the failures you were seeing is the 
kernel default context or in the UMD-created contexts.


Thanks,
Oscar

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


[Intel-gfx] ✓ Fi.CI.BAT: success for i915 PMU and engine busy stats

2017-07-18 Thread Patchwork
== Series Details ==

Series: i915 PMU and engine busy stats
URL   : https://patchwork.freedesktop.org/series/27488/
State : success

== Summary ==

Series 27488v1 i915 PMU and engine busy stats
https://patchwork.freedesktop.org/api/1.0/series/27488/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

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

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:443s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:431s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:357s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:525s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:516s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:494s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:481s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:595s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:411s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:500s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:570s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:578s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:562s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:456s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:585s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:472s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:473s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:439s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:475s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:405s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
6601a6c drm/i915/pmu: Wire up engine busy stats to PMU
7d7d26e drm/i915: Export engine busy stats in debugfs
f4fddc8 drm/i915: Interface for controling engine stats collection
559f3b2 drm/i915: Engine busy time tracking
d02886e drm/i915: Wrap context schedule notification
cdcdd9f drm/i915/pmu: Suspend sampling when GPU is idle
c436b20 drm/i915/pmu: Expose events in sysfs
c0efa43 drm/i915/pmu: Add fake regs
da03ba4 drm/i915/pmu: Only sample enabled samplers
afea896 drm/i915/pmu: Helper to extract engine and sampler from PMU config
2ff9a43 drm/i915/pmu: Decouple uAPI engine ids
8a3ac8e drm/i915/pmu: Add queued samplers to the PMU uAPI
278c42b drm/i915/pmu: Add VCS2 engine to the PMU uAPI
dc1f338 RFC drm/i915: Expose a PMU interface for perf queries

== Logs ==

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


Re: [Intel-gfx] [PATCH v4] drm/i915/execlists: Read the context-status buffer from the HWSP

2017-07-18 Thread Chris Wilson
Quoting Mika Kuoppala (2017-07-18 15:36:46)
> Chris Wilson  writes:
> 
> > The engine provides a mirror of the CSB in the HWSP. If we use the
> > cacheable reads from the HWSP, we can shave off a few mmio reads per
> > context-switch interrupt (which are quite frequent!). Just removing a
> > couple of mmio is not enough to actually reduce any latency, but a small
> > reduction in overall cpu usage.
> >
> > Much appreciation for Ben dropping the bombshell that the CSB was in the
> > HWSP and for Michel in digging out the details.
> >
> > v2: Don't be lazy, add the defines for the indices.
> > v3: Include the HWSP in debugfs/i915_engine_info
> > v4: Check for GVT-g, it currently depends on intercepting CSB mmio
> > v5: Fixup GVT-g mmio path
> >
> > Suggested-by: Ben Widawsky 
> > Signed-off-by: Chris Wilson 
> > Cc: Michel Thierry 
> > Cc: Tvrtko Ursulin 
> > Cc: Mika Kuoppala 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Zhenyu Wang 
> > Cc: Zhi Wang 
> > Acked-by: Michel Thierry 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c |  7 +--
> >  drivers/gpu/drm/i915/intel_lrc.c| 16 +++-
> >  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
> >  3 files changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 620c9218d1c1..5fd01c14a3ec 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -3384,6 +3384,7 @@ static int i915_engine_info(struct seq_file *m, void 
> > *unused)
> >  upper_32_bits(addr), lower_32_bits(addr));
> >  
> >   if (i915.enable_execlists) {
> > + const u32 *hws = 
> > >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> >   u32 ptr, read, write;
> >   unsigned int idx;
> >  
> > @@ -3404,10 +3405,12 @@ static int i915_engine_info(struct seq_file *m, 
> > void *unused)
> >   write += GEN8_CSB_ENTRIES;
> >   while (read < write) {
> >   idx = ++read % GEN8_CSB_ENTRIES;
> > - seq_printf(m, "Execlist CSB[%d]: 0x%08x, 
> > context: %d\n",
> > + seq_printf(m, "Execlist CSB[%d]: 0x%08x 
> > [0x%08x in hwsp], context: %d [%d in hwsp]\n",
> >  idx,
> >  
> > I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
> > -
> > I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)));
> > +hws[idx * 2],
> > +
> > I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)),
> > +hws[idx * 2 + 1]);
> >   }
> >  
> >   rcu_read_lock();
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 3469badedbe0..41dc04eb6097 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -547,10 +547,17 @@ static void intel_lrc_irq_handler(unsigned long data)
> >   while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
> >   u32 __iomem *csb_mmio =
> >   dev_priv->regs + 
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
> > - u32 __iomem *buf =
> > - dev_priv->regs + 
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0));
> > + /* The HWSP contains a (cacheable) mirror of the CSB */
> > + const u32 *buf =
> > + 
> > >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> 
> Could be also const u32 * const buf = ...
> as in debugfs counterpart. Value added is quite thin tho vs clutter so
> not insisting.

> >   unsigned int head, tail;
> >  
> > + /* However GVT emulation depends upon intercepting CSB mmio */
> > + if (unlikely(intel_vgpu_active(dev_priv))) {
> > + buf = (u32 * __force)
> > + (dev_priv->regs + 
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> > + }

Hence why we can't use const u32 *const buf ;-)

> > +
> >   /* The write will be ordered by the uncached read (itself
> >* a memory barrier), so we do not need another in the form
> >* of a locked instruction. The race between the interrupt
> > @@ -590,13 +597,12 @@ static void intel_lrc_irq_handler(unsigned long data)
> >* status notifier.
> >   

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

2017-07-18 Thread Lionel Landwerlin

On 18/07/17 11:09, Matthew Auld wrote:

On 07/17, Lionel Landwerlin wrote:

The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.

This will relieve the kernel from holding all the possible configs, so
we can leave only the test configs here.

v2: Drop DRM_ERROR for userspace errors (Matthew)
 Add padding to userspace structure (Matthew)
 s/guid/uuid/ (Matthew)

v3: Use u32 instead of int to iterate through registers (Matthew)

v4: Lock access to dynamic config list (Lionel)

Signed-off-by: Matthew Auld 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Andrzej Datczuk 
---
  drivers/gpu/drm/i915/i915_drv.c  |   2 +
  drivers/gpu/drm/i915/i915_drv.h  |  48 +
  drivers/gpu/drm/i915/i915_perf.c | 413 +--
  drivers/gpu/drm/i915/i915_reg.h  |   2 +
  include/uapi/drm/i915_drm.h  |  24 +++
  5 files changed, 475 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..a3d339670ec1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
  };
  
  static struct drm_driver driver = {

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b824f8875c4..607484737f3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1917,6 +1917,9 @@ struct i915_oa_config {
struct attribute_group sysfs_metric;
struct attribute *attrs[2];
struct device_attribute sysfs_metric_id;
+
+   /* Only updated while holding dev_priv->perf.metrics_lock. */
+   bool in_use;
  };
  
  struct i915_perf_stream;

@@ -2043,6 +2046,25 @@ struct i915_perf_stream {
   */
  struct i915_oa_ops {
/**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+   bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+  u32 addr);
+
+   /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+   bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+   bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
 * @init_oa_buffer: Resets the head and tail pointers of the
 * circular buffer for periodic OA reports.
 *
@@ -2430,10 +2452,32 @@ struct drm_i915_private {
struct kobject *metrics_kobj;
struct ctl_table_header *sysctl_header;
  
+		/*

+* Lock associated with adding/modifying/removing OA configs
+* in dev_priv->perf.metrics_idr.
+*/
+   struct mutex metrics_lock;
+
+   /*
+* List of dynamic configurations, you need to hold
+* dev_priv->perf.metrics_lock to access it.
+*/
+   struct idr metrics_idr;
+
+   /*
+* Lock associated with anything below within this structure
+* except exclusive_stream.
+*/
struct mutex lock;
struct list_head streams;
  
  		struct {

+   /*
+* The stream currently using the OA unit. If accessed
+* outside a syscall associated to its file
+* descriptor, you need to hold
+* dev_priv->drm.struct_mutex.
+*/
struct i915_perf_stream *exclusive_stream;
  
  			u32 specific_ctx_id;

@@ -3599,6 +3643,10 @@ i915_gem_context_lookup_timeline(struct i915_gem_context 
*ctx,
  
  int i915_perf_open_ioctl(struct drm_device *dev, void *data,

 struct drm_file *file);
+int 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Explicit the connector name for DP link training result (rev2)

2017-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915: Explicit the connector name for DP link training result (rev2)
URL   : https://patchwork.freedesktop.org/series/27410/
State : success

== Summary ==

Series 27410v2 drm/i915: Explicit the connector name for DP link training result
https://patchwork.freedesktop.org/api/1.0/series/27410/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) k.org#196399 +1
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597

k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399
fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:444s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:434s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:353s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:536s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:514s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:495s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:491s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:593s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:437s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:415s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:490s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:572s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:592s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:559s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:458s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:582s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:469s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:482s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:466s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:405s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
53ca378 drm/i915: Explicit the connector name for DP link training result

== Logs ==

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


Re: [Intel-gfx] [PATCH v4] drm/i915/execlists: Read the context-status buffer from the HWSP

2017-07-18 Thread Mika Kuoppala
Chris Wilson  writes:

> The engine provides a mirror of the CSB in the HWSP. If we use the
> cacheable reads from the HWSP, we can shave off a few mmio reads per
> context-switch interrupt (which are quite frequent!). Just removing a
> couple of mmio is not enough to actually reduce any latency, but a small
> reduction in overall cpu usage.
>
> Much appreciation for Ben dropping the bombshell that the CSB was in the
> HWSP and for Michel in digging out the details.
>
> v2: Don't be lazy, add the defines for the indices.
> v3: Include the HWSP in debugfs/i915_engine_info
> v4: Check for GVT-g, it currently depends on intercepting CSB mmio
> v5: Fixup GVT-g mmio path
>
> Suggested-by: Ben Widawsky 
> Signed-off-by: Chris Wilson 
> Cc: Michel Thierry 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> Cc: Daniele Ceraolo Spurio 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Acked-by: Michel Thierry 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  7 +--
>  drivers/gpu/drm/i915/intel_lrc.c| 16 +++-
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
>  3 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 620c9218d1c1..5fd01c14a3ec 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3384,6 +3384,7 @@ static int i915_engine_info(struct seq_file *m, void 
> *unused)
>  upper_32_bits(addr), lower_32_bits(addr));
>  
>   if (i915.enable_execlists) {
> + const u32 *hws = 
> >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
>   u32 ptr, read, write;
>   unsigned int idx;
>  
> @@ -3404,10 +3405,12 @@ static int i915_engine_info(struct seq_file *m, void 
> *unused)
>   write += GEN8_CSB_ENTRIES;
>   while (read < write) {
>   idx = ++read % GEN8_CSB_ENTRIES;
> - seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, 
> context: %d\n",
> + seq_printf(m, "\tExeclist CSB[%d]: 0x%08x 
> [0x%08x in hwsp], context: %d [%d in hwsp]\n",
>  idx,
>  
> I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
> -
> I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)));
> +hws[idx * 2],
> +
> I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)),
> +hws[idx * 2 + 1]);
>   }
>  
>   rcu_read_lock();
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3469badedbe0..41dc04eb6097 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -547,10 +547,17 @@ static void intel_lrc_irq_handler(unsigned long data)
>   while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
>   u32 __iomem *csb_mmio =
>   dev_priv->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
> - u32 __iomem *buf =
> - dev_priv->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0));
> + /* The HWSP contains a (cacheable) mirror of the CSB */
> + const u32 *buf =
> + >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];

Could be also const u32 * const buf = ...
as in debugfs counterpart. Value added is quite thin tho vs clutter so
not insisting.

>   unsigned int head, tail;
>  
> + /* However GVT emulation depends upon intercepting CSB mmio */
> + if (unlikely(intel_vgpu_active(dev_priv))) {
> + buf = (u32 * __force)
> + (dev_priv->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> + }
> +
>   /* The write will be ordered by the uncached read (itself
>* a memory barrier), so we do not need another in the form
>* of a locked instruction. The race between the interrupt
> @@ -590,13 +597,12 @@ static void intel_lrc_irq_handler(unsigned long data)
>* status notifier.
>*/
>  
> - status = readl(buf + 2 * head);
> + status = buf[2 * head];
>   if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
>   continue;
>  
>   /* Check the context/desc id for this event 

[Intel-gfx] [RFC 14/14] drm/i915/pmu: Wire up engine busy stats to PMU

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

We can use engine busy stats instead of the MMIO sampling timer
for better efficiency.

As minimum this saves period * num_engines / sec mmio reads,
and in a better case, when only engine busy samplers are active,
it enables us to not kick off the sampling timer at all.

It is also more accurate since it doesn't rely on sampling.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 drivers/gpu/drm/i915/i915_pmu.c | 64 +
 2 files changed, 61 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f1fded6dd9cf..2986a01660d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2603,8 +2603,11 @@ struct drm_i915_private {
spinlock_t lock;
struct hrtimer timer;
bool timer_enabled;
+   bool busy_stats;
u64 enable;
u64 sample[__I915_NUM_PMU_SAMPLERS];
+   struct work_struct enable_busy_stats;
+   struct delayed_work disable_busy_stats;
} pmu;
 
/*
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4b113cad40d1..996612843594 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -29,12 +29,23 @@ static const unsigned int user_engine_map[I915_NUM_ENGINES] 
= {
[I915_SAMPLE_VECS] = VECS,
 };
 
+#define ENGINE_BUSY_BITS \
+   (BIT_ULL(I915_PMU_COUNT_RCS_BUSY) | \
+BIT_ULL(I915_PMU_COUNT_BCS_BUSY) | \
+BIT_ULL(I915_PMU_COUNT_VCS_BUSY) | \
+BIT_ULL(I915_PMU_COUNT_VCS2_BUSY) | \
+BIT_ULL(I915_PMU_COUNT_VECS_BUSY))
+
 static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
 {
-   if (gpu_active)
-   return i915->pmu.enable;
-   else
-   return i915->pmu.enable >> 32;
+   u64 mask = i915->pmu.enable;
+
+   if (!gpu_active)
+   mask >>= 32;
+   else if (i915->pmu.busy_stats)
+   mask &= ~ENGINE_BUSY_BITS;
+
+   return mask;
 }
 
 void i915_pmu_gt_idle(struct drm_i915_private *i915)
@@ -110,7 +121,8 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
if (sample_mask & BIT(I915_SAMPLE_QUEUED))
engine->pmu_sample[I915_SAMPLE_QUEUED] += PERIOD;
 
-   if (sample_mask & BIT(I915_SAMPLE_BUSY)) {
+   if ((sample_mask & BIT(I915_SAMPLE_BUSY)) &&
+   !dev_priv->pmu.busy_stats) {
fw = grab_forcewake(dev_priv, fw);
val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
if (!(val & MODE_IDLE))
@@ -337,6 +349,11 @@ static void i915_pmu_timer_cancel(struct perf_event *event)
hrtimer_cancel(>hrtimer);
 }
 
+static bool supports_busy_stats(void)
+{
+   return i915.enable_execlists;
+}
+
 static void i915_pmu_enable(struct perf_event *event)
 {
struct drm_i915_private *i915 =
@@ -345,6 +362,13 @@ static void i915_pmu_enable(struct perf_event *event)
 
spin_lock_irqsave(>pmu.lock, flags);
 
+   if (pmu_config_sampler(event->attr.config) == I915_SAMPLE_BUSY &&
+   supports_busy_stats() && !i915->pmu.busy_stats) {
+   i915->pmu.busy_stats = true;
+   if (!cancel_delayed_work(>pmu.disable_busy_stats))
+   queue_work(i915->wq, >pmu.enable_busy_stats);
+   }
+
i915->pmu.enable |= BIT_ULL(event->attr.config);
if (pmu_needs_timer(i915, true) && !i915->pmu.timer_enabled) {
hrtimer_start_range_ns(>pmu.timer,
@@ -367,6 +391,11 @@ static void i915_pmu_disable(struct perf_event *event)
spin_lock_irqsave(>pmu.lock, flags);
i915->pmu.enable &= ~BIT_ULL(event->attr.config);
i915->pmu.timer_enabled &= pmu_needs_timer(i915, true);
+   if (!(i915->pmu.enable & ENGINE_BUSY_BITS) && i915->pmu.busy_stats) {
+   i915->pmu.busy_stats = false;
+   queue_delayed_work(i915->wq, >pmu.disable_busy_stats,
+  round_jiffies_up_relative(2 * HZ));
+   }
spin_unlock_irqrestore(>pmu.lock, flags);
 
i915_pmu_timer_cancel(event);
@@ -471,7 +500,12 @@ static void i915_pmu_event_read(struct perf_event *event)
/* Do nothing */
} else {
enum intel_engine_id id = user_engine_map[user_engine];
-   val = i915->engine[id]->pmu_sample[sample];
+   struct intel_engine_cs *engine = i915->engine[id];
+
+   if (i915->pmu.busy_stats && sample == I915_SAMPLE_BUSY)
+   val = intel_engine_get_current_busy_ns(engine);
+   else
+   val = 

[Intel-gfx] [RFC 10/14] drm/i915: Wrap context schedule notification

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

No functional change just something which will be handy in the
following patch.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 699868d81de8..89aa29f23a92 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -307,6 +307,18 @@ execlists_context_status_change(struct 
drm_i915_gem_request *rq,
   status, rq);
 }
 
+static inline void
+execlists_context_schedule_in(struct drm_i915_gem_request *rq)
+{
+   execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
+}
+
+static inline void
+execlists_context_schedule_out(struct drm_i915_gem_request *rq)
+{
+   execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
+}
+
 static void
 execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state)
 {
@@ -352,7 +364,7 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
if (rq) {
GEM_BUG_ON(count > !n);
if (!count++)
-   execlists_context_status_change(rq, 
INTEL_CONTEXT_SCHEDULE_IN);
+   execlists_context_schedule_in(rq);
port_set([n], port_pack(rq, count));
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id = 
upper_32_bits(desc));
@@ -603,8 +615,7 @@ static void intel_lrc_irq_handler(unsigned long data)
if (--count == 0) {
GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);
GEM_BUG_ON(!i915_gem_request_completed(rq));
-   execlists_context_status_change(rq, 
INTEL_CONTEXT_SCHEDULE_OUT);
-
+   execlists_context_schedule_out(rq);
trace_i915_gem_request_out(rq);
i915_gem_request_put(rq);
 
-- 
2.9.4

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


[Intel-gfx] [RFC 09/14] drm/i915/pmu: Suspend sampling when GPU is idle

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

If only a subset of events is enabled we can afford to suspend
the sampling timer when the GPU is idle and so save some cycles
and power.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  6 
 drivers/gpu/drm/i915/i915_gem.c |  1 +
 drivers/gpu/drm/i915/i915_gem_request.c |  1 +
 drivers/gpu/drm/i915/i915_pmu.c | 52 +++--
 4 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index de518503e033..f1fded6dd9cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2600,7 +2600,9 @@ struct drm_i915_private {
 
struct {
struct pmu base;
+   spinlock_t lock;
struct hrtimer timer;
+   bool timer_enabled;
u64 enable;
u64 sample[__I915_NUM_PMU_SAMPLERS];
} pmu;
@@ -3778,9 +3780,13 @@ extern void i915_perf_unregister(struct drm_i915_private 
*dev_priv);
 #ifdef CONFIG_PERF_EVENTS
 extern void i915_pmu_register(struct drm_i915_private *i915);
 extern void i915_pmu_unregister(struct drm_i915_private *i915);
+extern void i915_pmu_gt_idle(struct drm_i915_private *i915);
+extern void i915_pmu_gt_active(struct drm_i915_private *i915);
 #else
 static inline void i915_pmu_register(struct drm_i915_private *i915) {}
 static inline void i915_pmu_unregister(struct drm_i915_private *i915) {}
+static inline void i915_pmu_gt_idle(struct drm_i915_private *i915) {}
+static inline void i915_pmu_gt_active(struct drm_i915_private *i915) {}
 #endif
 
 /* i915_suspend.c */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1b2dfa8bdeef..bb81c1fcbc40 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3235,6 +3235,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
 
intel_engines_mark_idle(dev_priv);
i915_gem_timelines_mark_idle(dev_priv);
+   i915_pmu_gt_idle(dev_priv);
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 483af8921060..569c44a6ba2a 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -876,6 +876,7 @@ static void i915_gem_mark_busy(const struct intel_engine_cs 
*engine)
i915_update_gfx_val(dev_priv);
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_busy(dev_priv);
+   i915_pmu_gt_active(dev_priv);
 
queue_delayed_work(dev_priv->wq,
   _priv->gt.retire_work,
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 7ea84a191876..4b113cad40d1 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -29,6 +29,40 @@ static const unsigned int user_engine_map[I915_NUM_ENGINES] 
= {
[I915_SAMPLE_VECS] = VECS,
 };
 
+static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
+{
+   if (gpu_active)
+   return i915->pmu.enable;
+   else
+   return i915->pmu.enable >> 32;
+}
+
+void i915_pmu_gt_idle(struct drm_i915_private *i915)
+{
+   spin_lock_irq(>pmu.lock);
+   /*
+* Signal sampling timer to stop if only engine events are enabled and
+* GPU went idle.
+*/
+   i915->pmu.timer_enabled = pmu_needs_timer(i915, false);
+   spin_unlock_irq(>pmu.lock);
+}
+
+void i915_pmu_gt_active(struct drm_i915_private *i915)
+{
+   spin_lock_irq(>pmu.lock);
+   /*
+* Re-enable sampling timer when GPU goes active.
+*/
+   if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
+   hrtimer_start_range_ns(>pmu.timer,
+  ns_to_ktime(PERIOD), 0,
+  HRTIMER_MODE_REL_PINNED);
+   i915->pmu.timer_enabled = true;
+   }
+   spin_unlock_irq(>pmu.lock);
+}
+
 static bool grab_forcewake(struct drm_i915_private *i915, bool fw)
 {
if (!fw)
@@ -133,7 +167,7 @@ static enum hrtimer_restart i915_sample(struct hrtimer 
*hrtimer)
struct drm_i915_private *i915 =
container_of(hrtimer, struct drm_i915_private, pmu.timer);
 
-   if (i915->pmu.enable == 0)
+   if (!READ_ONCE(i915->pmu.timer_enabled))
return HRTIMER_NORESTART;
 
engines_sample(i915);
@@ -307,13 +341,19 @@ static void i915_pmu_enable(struct perf_event *event)
 {
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
+   unsigned long flags;
+
+   spin_lock_irqsave(>pmu.lock, flags);
 
-   if (i915->pmu.enable == 0)
+   i915->pmu.enable |= BIT_ULL(event->attr.config);
+   if (pmu_needs_timer(i915, true) && 

[Intel-gfx] [RFC 03/14] drm/i915/pmu: Add queued samplers to the PMU uAPI

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

This is also partially missing in the original patch.

Signed-off-by: Tvrtko Ursulin 
---
 include/uapi/drm/i915_drm.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 67e63757b35d..7003599a460e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -103,22 +103,27 @@ enum i915_mocs_table_index {
 
 #define __I915_PMU_COUNT(ring, id) ((ring) << 2 | (id))
 
+#define I915_PMU_COUNT_RCS_QUEUED __I915_PMU_COUNT(I915_SAMPLE_RCS, 
I915_SAMPLE_QUEUED)
 #define I915_PMU_COUNT_RCS_BUSY __I915_PMU_COUNT(I915_SAMPLE_RCS, 
I915_SAMPLE_BUSY)
 #define I915_PMU_COUNT_RCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_RCS, 
I915_SAMPLE_WAIT)
 #define I915_PMU_COUNT_RCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_RCS, 
I915_SAMPLE_SEMA)
 
+#define I915_PMU_COUNT_VCS_QUEUED __I915_PMU_COUNT(I915_SAMPLE_VCS, 
I915_SAMPLE_QUEUED)
 #define I915_PMU_COUNT_VCS_BUSY __I915_PMU_COUNT(I915_SAMPLE_VCS, 
I915_SAMPLE_BUSY)
 #define I915_PMU_COUNT_VCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_VCS, 
I915_SAMPLE_WAIT)
 #define I915_PMU_COUNT_VCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_VCS, 
I915_SAMPLE_SEMA)
 
+#define I915_PMU_COUNT_VCS2_QUEUED __I915_PMU_COUNT(I915_SAMPLE_VCS2, 
I915_SAMPLE_QUEUED)
 #define I915_PMU_COUNT_VCS2_BUSY __I915_PMU_COUNT(I915_SAMPLE_VCS2, 
I915_SAMPLE_BUSY)
 #define I915_PMU_COUNT_VCS2_WAIT __I915_PMU_COUNT(I915_SAMPLE_VCS2, 
I915_SAMPLE_WAIT)
 #define I915_PMU_COUNT_VCS2_SEMA __I915_PMU_COUNT(I915_SAMPLE_VCS2, 
I915_SAMPLE_SEMA)
 
+#define I915_PMU_COUNT_BCS_QUEUED __I915_PMU_COUNT(I915_SAMPLE_BCS, 
I915_SAMPLE_QUEUED)
 #define I915_PMU_COUNT_BCS_BUSY __I915_PMU_COUNT(I915_SAMPLE_BCS, 
I915_SAMPLE_BUSY)
 #define I915_PMU_COUNT_BCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_BCS, 
I915_SAMPLE_WAIT)
 #define I915_PMU_COUNT_BCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_BCS, 
I915_SAMPLE_SEMA)
 
+#define I915_PMU_COUNT_VECS_QUEUED __I915_PMU_COUNT(I915_SAMPLE_VECS, 
I915_SAMPLE_QUEUED)
 #define I915_PMU_COUNT_VECS_BUSY __I915_PMU_COUNT(I915_SAMPLE_VECS, 
I915_SAMPLE_BUSY)
 #define I915_PMU_COUNT_VECS_WAIT __I915_PMU_COUNT(I915_SAMPLE_VECS, 
I915_SAMPLE_WAIT)
 #define I915_PMU_COUNT_VECS_SEMA __I915_PMU_COUNT(I915_SAMPLE_VECS, 
I915_SAMPLE_SEMA)
-- 
2.9.4

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


[Intel-gfx] [RFC 06/14] drm/i915/pmu: Only sample enabled samplers

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Save some execution time by not reading the MMIO registers
for the samplers which are not enabled.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 49 +++--
 1 file changed, 33 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index d80e673477b5..4d61a1e72ee6 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -29,6 +29,14 @@ static const unsigned int user_engine_map[I915_NUM_ENGINES] 
= {
[I915_SAMPLE_VECS] = VECS,
 };
 
+static bool grab_forcewake(struct drm_i915_private *i915, bool fw)
+{
+   if (!fw)
+   intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
+
+   return true;
+}
+
 static void engines_sample(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
@@ -46,6 +54,7 @@ static void engines_sample(struct drm_i915_private *dev_priv)
 
for_each_engine(engine, dev_priv, id) {
unsigned int user_engine = engine_map[id];
+   u8 sample_mask;
u32 val;
 
if (WARN_ON_ONCE(id >= ARRAY_SIZE(engine_map)))
@@ -53,30 +62,38 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
else
user_engine = engine_map[id];
 
-   if (!(dev_priv->pmu.enable &
-   (ENGINE_SAMPLE_MASK << (ENGINE_SAMPLE_BITS * user_engine
+   sample_mask = (dev_priv->pmu.enable >>
+ (ENGINE_SAMPLE_BITS * user_engine)) &
+ ENGINE_SAMPLE_MASK;
+
+   if (!sample_mask)
continue;
 
if (i915_seqno_passed(intel_engine_get_seqno(engine),
  intel_engine_last_submit(engine)))
continue;
 
-   if (!fw) {
-   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
-   fw = true;
-   }
-
-   engine->pmu_sample[I915_SAMPLE_QUEUED] += PERIOD;
+   if (sample_mask & BIT(I915_SAMPLE_QUEUED))
+   engine->pmu_sample[I915_SAMPLE_QUEUED] += PERIOD;
 
-   val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
-   if (!(val & MODE_IDLE))
-   engine->pmu_sample[I915_SAMPLE_BUSY] += PERIOD;
+   if (sample_mask & BIT(I915_SAMPLE_BUSY)) {
+   fw = grab_forcewake(dev_priv, fw);
+   val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
+   if (!(val & MODE_IDLE))
+   engine->pmu_sample[I915_SAMPLE_BUSY] += PERIOD;
+   }
 
-   val = I915_READ_FW(RING_CTL(engine->mmio_base));
-   if (val & RING_WAIT)
-   engine->pmu_sample[I915_SAMPLE_WAIT] += PERIOD;
-   if (val & RING_WAIT_SEMAPHORE)
-   engine->pmu_sample[I915_SAMPLE_SEMA] += PERIOD;
+   if (sample_mask &
+   (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA))) {
+   fw = grab_forcewake(dev_priv, fw);
+   val = I915_READ_FW(RING_CTL(engine->mmio_base));
+   if ((sample_mask & BIT(I915_SAMPLE_WAIT)) &&
+   (val & RING_WAIT))
+   engine->pmu_sample[I915_SAMPLE_WAIT] += PERIOD;
+   if ((sample_mask & BIT(I915_SAMPLE_SEMA)) &&
+   (val & RING_WAIT_SEMAPHORE))
+   engine->pmu_sample[I915_SAMPLE_SEMA] += PERIOD;
+   }
}
 
if (fw)
-- 
2.9.4

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


[Intel-gfx] [RFC 08/14] drm/i915/pmu: Expose events in sysfs

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

This makes then visible to "perf list".

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 89 +
 1 file changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4195d89b1c82..7ea84a191876 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -474,11 +474,100 @@ static int i915_pmu_event_event_idx(struct perf_event 
*event)
return 0;
 }
 
+static ssize_t i915_pmu_format_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+struct dev_ext_attribute *eattr;
+
+eattr = container_of(attr, struct dev_ext_attribute, attr);
+return sprintf(buf, "%s\n", (char *) eattr->var);
+}
+
+#define I915_PMU_FORMAT_ATTR(_name, _config)   \
+(&((struct dev_ext_attribute[]) {   \
+{ .attr = __ATTR(_name, S_IRUGO, i915_pmu_format_show, NULL), \
+  .var = (void *) _config, }\
+})[0].attr.attr)
+
+static struct attribute *i915_pmu_format_attrs[] = {
+I915_PMU_FORMAT_ATTR(i915_eventid, "config:0-42"),
+NULL,
+};
+
+static const struct attribute_group i915_pmu_format_attr_group = {
+.name = "format",
+.attrs = i915_pmu_format_attrs,
+};
+
+static ssize_t i915_pmu_event_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+struct dev_ext_attribute *eattr;
+
+eattr = container_of(attr, struct dev_ext_attribute, attr);
+return sprintf(buf, "config=0x%lx\n", (unsigned long) eattr->var);
+}
+
+#define I915_PMU_EVENT_ATTR(_name, _config)\
+(&((struct dev_ext_attribute[]) {   \
+{ .attr = __ATTR(_name, S_IRUGO, i915_pmu_event_show, NULL), \
+  .var = (void *) _config, }\
+ })[0].attr.attr)
+
+static struct attribute *i915_pmu_events_attrs[] = {
+I915_PMU_EVENT_ATTR(rcs-queued,I915_PMU_COUNT_RCS_QUEUED),
+I915_PMU_EVENT_ATTR(rcs-busy,  I915_PMU_COUNT_RCS_BUSY),
+I915_PMU_EVENT_ATTR(rcs-wait,  I915_PMU_COUNT_RCS_WAIT),
+I915_PMU_EVENT_ATTR(rcs-sema,  I915_PMU_COUNT_RCS_SEMA),
+
+I915_PMU_EVENT_ATTR(bcs-queued,I915_PMU_COUNT_BCS_QUEUED),
+I915_PMU_EVENT_ATTR(bcs-busy,  I915_PMU_COUNT_BCS_BUSY),
+I915_PMU_EVENT_ATTR(bcs-wait,  I915_PMU_COUNT_BCS_WAIT),
+I915_PMU_EVENT_ATTR(bcs-sema,  I915_PMU_COUNT_BCS_SEMA),
+
+I915_PMU_EVENT_ATTR(vcs-queued,I915_PMU_COUNT_VCS_QUEUED),
+I915_PMU_EVENT_ATTR(vcs-busy,  I915_PMU_COUNT_VCS_BUSY),
+I915_PMU_EVENT_ATTR(vcs-wait,  I915_PMU_COUNT_VCS_WAIT),
+I915_PMU_EVENT_ATTR(vcs-sema,  I915_PMU_COUNT_VCS_SEMA),
+
+I915_PMU_EVENT_ATTR(vcs2-queued, I915_PMU_COUNT_VCS2_QUEUED),
+I915_PMU_EVENT_ATTR(vcs2-busy,  I915_PMU_COUNT_VCS2_BUSY),
+I915_PMU_EVENT_ATTR(vcs2-wait,  I915_PMU_COUNT_VCS2_WAIT),
+I915_PMU_EVENT_ATTR(vcs2-sema,  I915_PMU_COUNT_VCS2_SEMA),
+
+I915_PMU_EVENT_ATTR(vecs-queued, I915_PMU_COUNT_VECS_QUEUED),
+I915_PMU_EVENT_ATTR(vecs-busy,  I915_PMU_COUNT_VECS_BUSY),
+I915_PMU_EVENT_ATTR(vecs-wait,  I915_PMU_COUNT_VECS_WAIT),
+I915_PMU_EVENT_ATTR(vecs-sema,  I915_PMU_COUNT_VECS_SEMA),
+
+I915_PMU_EVENT_ATTR(actual-frequency,   I915_PMU_ACTUAL_FREQUENCY),
+I915_PMU_EVENT_ATTR(requested-frequency, I915_PMU_REQUESTED_FREQUENCY),
+I915_PMU_EVENT_ATTR(energy, I915_PMU_ENERGY),
+I915_PMU_EVENT_ATTR(interrupts, I915_PMU_INTERRUPTS),
+I915_PMU_EVENT_ATTR(rc6-residency,  I915_PMU_RC6_RESIDENCY),
+I915_PMU_EVENT_ATTR(rc6p-residency, I915_PMU_RC6p_RESIDENCY),
+I915_PMU_EVENT_ATTR(rc6pp-residency,I915_PMU_RC6pp_RESIDENCY),
+
+NULL,
+};
+
+static const struct attribute_group i915_pmu_events_attr_group = {
+.name = "events",
+.attrs = i915_pmu_events_attrs,
+};
+
+static const struct attribute_group *i915_pmu_attr_groups[] = {
+_pmu_format_attr_group,
+_pmu_events_attr_group,
+NULL
+};
+
 void i915_pmu_register(struct drm_i915_private *i915)
 {
if (INTEL_GEN(i915) <= 2)
return;
 
+   i915->pmu.base.attr_groups  = i915_pmu_attr_groups;
i915->pmu.base.task_ctx_nr  = perf_sw_context;
i915->pmu.base.event_init   = i915_pmu_event_init;
i915->pmu.base.add  = i915_pmu_event_add;
-- 
2.9.4

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


[Intel-gfx] [RFC 07/14] drm/i915/pmu: Add fake regs

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Without this I can get a null ptr deref when trying to access
our events with perf.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4d61a1e72ee6..4195d89b1c82 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -183,8 +183,11 @@ static int engine_event_init(struct perf_event *event)
return 0;
 }
 
+static DEFINE_PER_CPU(struct pt_regs, i915_pmu_pt_regs);
+
 static enum hrtimer_restart hrtimer_sample(struct hrtimer *hrtimer)
 {
+   struct pt_regs *regs = this_cpu_ptr(_pmu_pt_regs);
struct perf_sample_data data;
struct perf_event *event;
u64 period;
@@ -196,7 +199,7 @@ static enum hrtimer_restart hrtimer_sample(struct hrtimer 
*hrtimer)
event->pmu->read(event);
 
perf_sample_data_init(, 0, event->hw.last_period);
-   perf_event_overflow(event, , NULL);
+   perf_event_overflow(event, , regs);
 
period = max_t(u64, 1, event->hw.sample_period);
hrtimer_forward_now(hrtimer, ns_to_ktime(period));
-- 
2.9.4

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


[Intel-gfx] [RFC 04/14] drm/i915/pmu: Decouple uAPI engine ids

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

As elsewhere in the code we have to decouple the binary
engine identifiers for easier maintenance.

Also the sampler mask was incorrect in the timer callback.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 44 -
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f03ddad44da6..9a8208dba7a9 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -10,6 +10,25 @@
 #define RING_MASK 0x
 #define RING_MAX 32
 
+#define ENGINE_SAMPLE_MASK (0xf)
+#define ENGINE_SAMPLE_BITS (4)
+
+static const unsigned int engine_map[I915_NUM_ENGINES] = {
+   [RCS] = I915_SAMPLE_RCS,
+   [BCS] = I915_SAMPLE_BCS,
+   [VCS] = I915_SAMPLE_VCS,
+   [VCS2] = I915_SAMPLE_VCS2,
+   [VECS] = I915_SAMPLE_VECS,
+};
+
+static const unsigned int user_engine_map[I915_NUM_ENGINES] = {
+   [I915_SAMPLE_RCS] = RCS,
+   [I915_SAMPLE_BCS] = BCS,
+   [I915_SAMPLE_VCS] = VCS,
+   [I915_SAMPLE_VCS2] = VCS2,
+   [I915_SAMPLE_VECS] = VECS,
+};
+
 static void engines_sample(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
@@ -26,9 +45,16 @@ static void engines_sample(struct drm_i915_private *dev_priv)
return;
 
for_each_engine(engine, dev_priv, id) {
+   unsigned int user_engine = engine_map[id];
u32 val;
 
-   if ((dev_priv->pmu.enable & (0x7 << (4*id))) == 0)
+   if (WARN_ON_ONCE(id >= ARRAY_SIZE(engine_map)))
+   continue;
+   else
+   user_engine = engine_map[id];
+
+   if (!(dev_priv->pmu.enable &
+   (ENGINE_SAMPLE_MASK << (ENGINE_SAMPLE_BITS * user_engine
continue;
 
if (i915_seqno_passed(intel_engine_get_seqno(engine),
@@ -112,6 +138,11 @@ static int engine_event_init(struct perf_event *event)
int engine = event->attr.config >> 2;
int sample = event->attr.config & 3;
 
+   if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map)))
+   return -ENOENT;
+   else
+   engine = user_engine_map[engine];
+
switch (sample) {
case I915_SAMPLE_QUEUED:
case I915_SAMPLE_BUSY:
@@ -125,9 +156,6 @@ static int engine_event_init(struct perf_event *event)
return -ENOENT;
}
 
-   if (engine >= I915_NUM_ENGINES)
-   return -ENOENT;
-
if (!i915->engine[engine])
return -ENODEV;
 
@@ -369,7 +397,13 @@ static void i915_pmu_event_read(struct perf_event *event)
if (event->attr.config < 32) {
int engine = event->attr.config >> 2;
int sample = event->attr.config & 3;
-   val = i915->engine[engine]->pmu_sample[sample];
+
+   if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map))) {
+   /* Do nothing */
+   } else {
+   engine = user_engine_map[engine];
+   val = i915->engine[engine]->pmu_sample[sample];
+   }
} else switch (event->attr.config) {
case I915_PMU_ACTUAL_FREQUENCY:
val = i915->pmu.sample[__I915_SAMPLE_FREQ_ACT];
-- 
2.9.4

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


[Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Enables other i915 components to enable and disable
the facility as needed.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 53 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 
 2 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3e5e08c6b5ef..03e7459bad06 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -29,6 +29,8 @@
 #include "intel_lrc.h"
 
 DEFINE_STATIC_KEY_FALSE(i915_engine_stats_key);
+static DEFINE_MUTEX(i915_engine_stats_mutex);
+static int i915_engine_stats_ref;
 
 /* Haswell does have the CXT_SIZE register however it does not appear to be
  * valid. Now, docs explain in dwords what is in the context object. The full
@@ -1340,6 +1342,57 @@ void intel_engines_mark_idle(struct drm_i915_private 
*i915)
}
 }
 
+int intel_enable_engine_stats(struct drm_i915_private *dev_priv)
+{
+   if (!i915.enable_execlists)
+   return -ENODEV;
+
+   mutex_lock(_engine_stats_mutex);
+   if (i915_engine_stats_ref++ == 0) {
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   for_each_engine(engine, dev_priv, id) {
+   memset(>stats, 0, sizeof(engine->stats));
+   spin_lock_init(>stats.lock);
+   }
+
+   static_branch_enable(_engine_stats_key);
+   }
+   mutex_unlock(_engine_stats_mutex);
+
+   return 0;
+}
+
+void intel_disable_engine_stats(void)
+{
+   mutex_lock(_engine_stats_mutex);
+   if (--i915_engine_stats_ref == 0)
+   static_branch_disable(_engine_stats_key);
+   mutex_unlock(_engine_stats_mutex);
+}
+
+u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+   u64 total;
+
+   spin_lock_irqsave(>stats.lock, flags);
+
+   total = engine->stats.total;
+
+   /*
+* If the engine is executing something at the moment
+* add it to the total.
+*/
+   if (engine->stats.ref)
+   total += ktime_get_real_ns() - engine->stats.start;
+
+   spin_unlock_irqrestore(>stats.lock, flags);
+
+   return total;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_engine.c"
 #endif
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 2eb1e970ad06..e0f495a6d0d9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -776,4 +776,9 @@ static inline void intel_engine_context_out(struct 
intel_engine_cs *engine)
}
 }
 
+int intel_enable_engine_stats(struct drm_i915_private *i915);
+void intel_disable_engine_stats(void);
+
+u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine);
+
 #endif /* _INTEL_RINGBUFFER_H_ */
-- 
2.9.4

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


[Intel-gfx] [RFC 11/14] drm/i915: Engine busy time tracking

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Track total time requests have been executing on the hardware.

To make this cheap it is hidden behind a static branch with the
intention that it is only enabled when there is a consumer
listening. This means that in the default off case the total
cost of the tracking is just a few no-op instructions on the
fast paths.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  6 +
 drivers/gpu/drm/i915/intel_lrc.c|  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 39 +
 3 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 24db316e0fd1..3e5e08c6b5ef 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -22,10 +22,14 @@
  *
  */
 
+#include 
+
 #include "i915_drv.h"
 #include "intel_ringbuffer.h"
 #include "intel_lrc.h"
 
+DEFINE_STATIC_KEY_FALSE(i915_engine_stats_key);
+
 /* Haswell does have the CXT_SIZE register however it does not appear to be
  * valid. Now, docs explain in dwords what is in the context object. The full
  * size is 70720 bytes, however, the power context and execlist context will
@@ -223,6 +227,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
 
+   spin_lock_init(>stats.lock);
+
ATOMIC_INIT_NOTIFIER_HEAD(>context_status_notifier);
 
dev_priv->engine[id] = engine;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 89aa29f23a92..b72a2d7cd44c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -310,12 +310,14 @@ execlists_context_status_change(struct 
drm_i915_gem_request *rq,
 static inline void
 execlists_context_schedule_in(struct drm_i915_gem_request *rq)
 {
+   intel_engine_context_in(rq->engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
 }
 
 static inline void
 execlists_context_schedule_out(struct drm_i915_gem_request *rq)
 {
+   intel_engine_context_out(rq->engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0877b151239d..2eb1e970ad06 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -443,6 +443,13 @@ struct intel_engine_cs {
 * certain bits to encode the command length in the header).
 */
u32 (*get_cmd_length_mask)(u32 cmd_header);
+
+   struct {
+   spinlock_t lock;
+   unsigned int ref;
+   u64 start; /* Timestamp of the last idle to active transition. 
*/
+   u64 total; /* Total time engined was busy. */
+   } stats;
 };
 
 static inline unsigned int
@@ -737,4 +744,36 @@ bool intel_engines_are_idle(struct drm_i915_private 
*dev_priv);
 void intel_engines_mark_idle(struct drm_i915_private *i915);
 void intel_engines_reset_default_submission(struct drm_i915_private *i915);
 
+DECLARE_STATIC_KEY_FALSE(i915_engine_stats_key);
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+   if (static_branch_unlikely(_engine_stats_key)) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>stats.lock, flags);
+   if (engine->stats.ref++ == 0)
+   engine->stats.start = ktime_get_real_ns();
+   GEM_BUG_ON(engine->stats.ref == 0);
+   spin_unlock_irqrestore(>stats.lock, flags);
+   }
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+   if (static_branch_unlikely(_engine_stats_key)) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>stats.lock, flags);
+   /*
+* After turning on the static key context out might be the
+* first event which then needs to be ignored (ref == 0).
+*/
+   if (engine->stats.ref && --engine->stats.ref == 0)
+   engine->stats.total += ktime_get_real_ns() -
+  engine->stats.start;
+   spin_unlock_irqrestore(>stats.lock, flags);
+   }
+}
+
 #endif /* _INTEL_RINGBUFFER_H_ */
-- 
2.9.4

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


[Intel-gfx] [RFC 13/14] drm/i915: Export engine busy stats in debugfs

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Export the stats added in the previous patch in debugfs.

Number of active clients reading this data is tracked and the
static key is only enabled whilst there are some.

Userspace is intended to keep the file descriptor open, seeking
to the beginning of the file periodically, and re-reading the
stats.

This is because the underlying implementation is costly on every
first open/last close transition, and also, because the stats
exported mostly make sense when they are considered relative to
the previous sample.

File lists nanoseconds each engine was active since the tracking
has started.

v2: Rebase.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 89 +
 1 file changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2ef75c1a6119..5a425cc225df 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4848,6 +4848,89 @@ static const struct file_operations 
i915_hpd_storm_ctl_fops = {
.write = i915_hpd_storm_ctl_write
 };
 
+struct i915_engine_stats_buf {
+   unsigned int len;
+   size_t available;
+   char buf[0];
+};
+
+static int i915_engine_stats_open(struct inode *inode, struct file *file)
+{
+   struct drm_i915_private *i915 = file->f_inode->i_private;
+   const unsigned int engine_name_len =
+   sizeof(((struct intel_engine_cs *)0)->name);
+   struct i915_engine_stats_buf *buf;
+   const unsigned int buf_size =
+   (engine_name_len + 2 + 19 + 1) * I915_NUM_ENGINES + 1 +
+   sizeof(*buf);
+   int ret;
+
+   buf = kzalloc(buf_size, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   ret = intel_enable_engine_stats(i915);
+   if (ret) {
+   kfree(buf);
+   return ret;
+   }
+
+   buf->len = buf_size;
+   file->private_data = buf;
+
+   return 0;
+}
+
+static int i915_engine_stats_release(struct inode *inode, struct file *file)
+{
+   intel_disable_engine_stats();
+   kfree(file->private_data);
+
+   return 0;
+}
+
+static ssize_t i915_engine_stats_read(struct file *file, char __user *ubuf,
+ size_t count, loff_t *pos)
+{
+   struct i915_engine_stats_buf *buf =
+   (struct i915_engine_stats_buf *)file->private_data;
+
+   if (*pos == 0) {
+   struct drm_i915_private *dev_priv = file->f_inode->i_private;
+   char *ptr = >buf[0];
+   int left = buf->len;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   buf->available = 0;
+
+   for_each_engine(engine, dev_priv, id) {
+   u64 total = intel_engine_get_current_busy_ns(engine);
+   int len;
+
+   len = snprintf(ptr, left, "%s: %llu\n",
+  engine->name, total);
+   buf->available += len;
+   left -= len;
+   ptr += len;
+
+   if (len == 0)
+   return -EFBIG;
+   }
+   }
+
+   return simple_read_from_buffer(ubuf, count, pos, >buf[0],
+  buf->available);
+}
+
+static const struct file_operations i915_engine_stats_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_engine_stats_open,
+   .release = i915_engine_stats_release,
+   .read = i915_engine_stats_read,
+   .llseek = default_llseek,
+};
+
 static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", i915_capabilities, 0},
{"i915_gem_objects", i915_gem_object_info, 0},
@@ -4938,6 +5021,12 @@ int i915_debugfs_register(struct drm_i915_private 
*dev_priv)
struct dentry *ent;
int ret, i;
 
+   ent = debugfs_create_file("i915_engine_stats", S_IRUGO,
+ minor->debugfs_root, to_i915(minor->dev),
+ _engine_stats_fops);
+   if (!ent)
+   return -ENOMEM;
+
ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
  minor->debugfs_root, to_i915(minor->dev),
  _forcewake_fops);
-- 
2.9.4

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


[Intel-gfx] [RFC 05/14] drm/i915/pmu: Helper to extract engine and sampler from PMU config

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Less hardcoded shifts and ands in the code is better.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 9a8208dba7a9..d80e673477b5 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -131,17 +131,21 @@ static void i915_pmu_event_destroy(struct perf_event 
*event)
WARN_ON(event->parent);
 }
 
+#define pmu_config_engine(config) ((config) >> 2)
+#define pmu_config_sampler(config) ((config) & 3)
+
 static int engine_event_init(struct perf_event *event)
 {
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
-   int engine = event->attr.config >> 2;
-   int sample = event->attr.config & 3;
+   unsigned int user_engine = pmu_config_engine(event->attr.config);
+   unsigned int sample = pmu_config_sampler(event->attr.config);
+   enum intel_engine_id engine_id;
 
-   if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map)))
+   if (WARN_ON_ONCE(user_engine >= ARRAY_SIZE(user_engine_map)))
return -ENOENT;
else
-   engine = user_engine_map[engine];
+   engine_id = user_engine_map[user_engine];
 
switch (sample) {
case I915_SAMPLE_QUEUED:
@@ -156,7 +160,7 @@ static int engine_event_init(struct perf_event *event)
return -ENOENT;
}
 
-   if (!i915->engine[engine])
+   if (!i915->engine[engine_id])
return -ENODEV;
 
return 0;
@@ -395,14 +399,14 @@ static void i915_pmu_event_read(struct perf_event *event)
u64 val = 0;
 
if (event->attr.config < 32) {
-   int engine = event->attr.config >> 2;
-   int sample = event->attr.config & 3;
+   unsigned int user_engine = 
pmu_config_engine(event->attr.config);
+   unsigned int sample = pmu_config_sampler(event->attr.config);
 
-   if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map))) {
+   if (WARN_ON_ONCE(user_engine >= ARRAY_SIZE(user_engine_map))) {
/* Do nothing */
} else {
-   engine = user_engine_map[engine];
-   val = i915->engine[engine]->pmu_sample[sample];
+   enum intel_engine_id id = user_engine_map[user_engine];
+   val = i915->engine[id]->pmu_sample[sample];
}
} else switch (event->attr.config) {
case I915_PMU_ACTUAL_FREQUENCY:
-- 
2.9.4

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


[Intel-gfx] [RFC 00/14] i915 PMU and engine busy stats

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Rough sketch of the idea I mentioned a few times to various people - merging
the engine busyness tracking with Chris i915 PMU RFC.

First patch is the actual PMU RFC by Chris. It is followed by some cleanup
patches, then come a few improvements, cheap execlists engine busyness tracking,
debugfs view for the same, and finally the i915 PMU is extended to use this
instead of timer based mmio sampling.

This makes it cheaper and also more accurate since engine busyness is not
derived via sampling.

But I haven't figure out the perf API yet. For example is it possible to access
our events in an usable fashion via perf top/stat or something? Do we want to
make the events discoverable as I did (patch 8).

I could not find much (any?) kernel API level documentation for perf.

Btw patch series actually works since intel-gpu-overlay can use these events
when they are available.

Chris Wilson (1):
  RFC drm/i915: Expose a PMU interface for perf queries

Tvrtko Ursulin (13):
  drm/i915/pmu: Add VCS2 engine to the PMU uAPI
  drm/i915/pmu: Add queued samplers to the PMU uAPI
  drm/i915/pmu: Decouple uAPI engine ids
  drm/i915/pmu: Helper to extract engine and sampler from PMU config
  drm/i915/pmu: Only sample enabled samplers
  drm/i915/pmu: Add fake regs
  drm/i915/pmu: Expose events in sysfs
  drm/i915/pmu: Suspend sampling when GPU is idle
  drm/i915: Wrap context schedule notification
  drm/i915: Engine busy time tracking
  drm/i915: Interface for controling engine stats collection
  drm/i915: Export engine busy stats in debugfs
  drm/i915/pmu: Wire up engine busy stats to PMU

 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_debugfs.c |  89 
 drivers/gpu/drm/i915/i915_drv.c |   2 +
 drivers/gpu/drm/i915/i915_drv.h |  32 ++
 drivers/gpu/drm/i915/i915_gem.c |   1 +
 drivers/gpu/drm/i915/i915_gem_request.c |   1 +
 drivers/gpu/drm/i915/i915_pmu.c | 697 
 drivers/gpu/drm/i915/intel_engine_cs.c  |  59 +++
 drivers/gpu/drm/i915/intel_lrc.c|  19 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  46 +++
 include/uapi/drm/i915_drm.h |  51 +++
 kernel/events/core.c|   1 +
 12 files changed, 996 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_pmu.c

-- 
2.9.4

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


[Intel-gfx] [RFC 02/14] drm/i915/pmu: Add VCS2 engine to the PMU uAPI

2017-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

It is missing from the original patch.

Signed-off-by: Tvrtko Ursulin 
---
 include/uapi/drm/i915_drm.h | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 733774f19a0b..67e63757b35d 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -96,9 +96,10 @@ enum i915_mocs_table_index {
 #define I915_SAMPLE_SEMA   3
 
 #define I915_SAMPLE_RCS0
-#define I915_SAMPLE_VCS1
-#define I915_SAMPLE_BCS2
-#define I915_SAMPLE_VECS   3
+#define I915_SAMPLE_BCS1
+#define I915_SAMPLE_VCS2
+#define I915_SAMPLE_VCS2   3
+#define I915_SAMPLE_VECS   4
 
 #define __I915_PMU_COUNT(ring, id) ((ring) << 2 | (id))
 
@@ -110,6 +111,10 @@ enum i915_mocs_table_index {
 #define I915_PMU_COUNT_VCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_VCS, 
I915_SAMPLE_WAIT)
 #define I915_PMU_COUNT_VCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_VCS, 
I915_SAMPLE_SEMA)
 
+#define I915_PMU_COUNT_VCS2_BUSY __I915_PMU_COUNT(I915_SAMPLE_VCS2, 
I915_SAMPLE_BUSY)
+#define I915_PMU_COUNT_VCS2_WAIT __I915_PMU_COUNT(I915_SAMPLE_VCS2, 
I915_SAMPLE_WAIT)
+#define I915_PMU_COUNT_VCS2_SEMA __I915_PMU_COUNT(I915_SAMPLE_VCS2, 
I915_SAMPLE_SEMA)
+
 #define I915_PMU_COUNT_BCS_BUSY __I915_PMU_COUNT(I915_SAMPLE_BCS, 
I915_SAMPLE_BUSY)
 #define I915_PMU_COUNT_BCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_BCS, 
I915_SAMPLE_WAIT)
 #define I915_PMU_COUNT_BCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_BCS, 
I915_SAMPLE_SEMA)
-- 
2.9.4

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


[Intel-gfx] [RFC 01/14] RFC drm/i915: Expose a PMU interface for perf queries

2017-07-18 Thread Tvrtko Ursulin
From: Chris Wilson 

The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.

To be able to do so, we need to export the two symbols from
kernel/events/core.c to register and unregister a PMU device.

v2: Use a common timer for the ring sampling.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.c |   2 +
 drivers/gpu/drm/i915/i915_drv.h |  23 ++
 drivers/gpu/drm/i915/i915_pmu.c | 452 
 drivers/gpu/drm/i915/intel_ringbuffer.h |   2 +
 include/uapi/drm/i915_drm.h |  41 +++
 kernel/events/core.c|   1 +
 7 files changed, 522 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_pmu.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f8227318dcaf..1c720013dc42 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -26,6 +26,7 @@ i915-y := i915_drv.o \
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
+i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
 
 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..f18ce519f6a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,6 +1194,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = _priv->drm;
 
i915_gem_shrinker_init(dev_priv);
+   i915_pmu_register(dev_priv);
 
/*
 * Notify a valid surface after modesetting,
@@ -1247,6 +1248,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
intel_opregion_unregister(dev_priv);
 
i915_perf_unregister(dev_priv);
+   i915_pmu_unregister(dev_priv);
 
i915_teardown_sysfs(dev_priv);
i915_guc_log_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c6fab08a2e6..de518503e033 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2093,6 +2094,12 @@ struct intel_cdclk_state {
unsigned int cdclk, vco, ref;
 };
 
+enum {
+   __I915_SAMPLE_FREQ_ACT = 0,
+   __I915_SAMPLE_FREQ_REQ,
+   __I915_NUM_PMU_SAMPLERS
+};
+
 struct drm_i915_private {
struct drm_device drm;
 
@@ -2591,6 +2598,13 @@ struct drm_i915_private {
int irq;
} lpe_audio;
 
+   struct {
+   struct pmu base;
+   struct hrtimer timer;
+   u64 enable;
+   u64 sample[__I915_NUM_PMU_SAMPLERS];
+   } pmu;
+
/*
 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
 * will be rejected. Instead look for a better place.
@@ -3760,6 +3774,15 @@ extern void i915_perf_fini(struct drm_i915_private 
*dev_priv);
 extern void i915_perf_register(struct drm_i915_private *dev_priv);
 extern void i915_perf_unregister(struct drm_i915_private *dev_priv);
 
+/* i915_pmu.c */
+#ifdef CONFIG_PERF_EVENTS
+extern void i915_pmu_register(struct drm_i915_private *i915);
+extern void i915_pmu_unregister(struct drm_i915_private *i915);
+#else
+static inline void i915_pmu_register(struct drm_i915_private *i915) {}
+static inline void i915_pmu_unregister(struct drm_i915_private *i915) {}
+#endif
+
 /* i915_suspend.c */
 extern int i915_save_state(struct drm_i915_private *dev_priv);
 extern int i915_restore_state(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
new file mode 100644
index ..f03ddad44da6
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -0,0 +1,452 @@
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "intel_ringbuffer.h"
+
+#define FREQUENCY 200
+#define PERIOD max_t(u64, 1, NSEC_PER_SEC / FREQUENCY)
+
+#define RING_MASK 0x
+#define RING_MAX 32
+
+static void engines_sample(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   bool fw = false;
+
+   if ((dev_priv->pmu.enable & RING_MASK) == 0)
+   return;
+
+   if (!dev_priv->gt.awake)
+   return;
+
+   if (!intel_runtime_pm_get_if_in_use(dev_priv))
+   return;
+
+   for_each_engine(engine, dev_priv, id) {
+   u32 val;
+
+   if ((dev_priv->pmu.enable & (0x7 << (4*id))) == 

[Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result

2017-07-18 Thread Paul Kocialkowski
This adds the connector name when printing a debug message about the DP
link training result. It is useful to figure out what connector is
failing when multiple DP connectors are used.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index b79c1c0e404c..05907fa8a553 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -321,12 +321,16 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
if (!intel_dp_link_training_channel_equalization(intel_dp))
goto failure_handling;
 
-   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate = 
%d, Lane count = %d",
+ intel_connector->base.base.id,
+ intel_connector->base.name,
  intel_dp->link_rate, intel_dp->lane_count);
return;
 
  failure_handling:
-   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = 
%d, lane count = %d",
+ intel_connector->base.base.id,
+ intel_connector->base.name,
  intel_dp->link_rate, intel_dp->lane_count);
if (!intel_dp_get_link_train_fallback_values(intel_dp,
 intel_dp->link_rate,
-- 
2.13.2

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drain the device workqueue on unload (rev2)

2017-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915: Drain the device workqueue on unload (rev2)
URL   : https://patchwork.freedesktop.org/series/26494/
State : success

== Summary ==

Series 26494v2 drm/i915: Drain the device workqueue on unload
https://patchwork.freedesktop.org/api/1.0/series/26494/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) k.org#196399
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101705

k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:440s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:426s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:353s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:533s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-byt-j1900 total:279  pass:255  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:610s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:440s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:414s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:502s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:569s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:579s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:569s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:452s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:585s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:467s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:472s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:482s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:411s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
b859b5d drm/i915: Drain the device workqueue on unload

== Logs ==

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


[Intel-gfx] [PATCH v2] drm/i915: Drain the device workqueue on unload

2017-07-18 Thread Chris Wilson
Workers on the i915->wq may rearm themselves so for completeness we need
to replace our flush_workqueue() with a call to drain_workqueue() before
unloading the device.

v2: Reinforce the drain_workqueue with an preceeding rcu_barrier() as a
few of the tasks that need to be drained may first be armed by RCU.

References: https://bugs.freedesktop.org/show_bug.cgi?id=101627
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.c  |  6 ++
 drivers/gpu/drm/i915/i915_drv.h  | 20 
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  2 +-
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4b62fd012877..41c5b11a7c8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -596,7 +596,8 @@ static const struct vga_switcheroo_client_ops 
i915_switcheroo_ops = {
 
 static void i915_gem_fini(struct drm_i915_private *dev_priv)
 {
-   flush_workqueue(dev_priv->wq);
+   /* Flush any outstanding unpin_work. */
+   i915_gem_drain_workqueue(dev_priv);
 
mutex_lock(_priv->drm.struct_mutex);
intel_uc_fini_hw(dev_priv);
@@ -1409,9 +1410,6 @@ void i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
i915_reset_error_state(dev_priv);
 
-   /* Flush any outstanding unpin_work. */
-   drain_workqueue(dev_priv->wq);
-
i915_gem_fini(dev_priv);
intel_uc_fini_fw(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 667fb5c44483..e9a4b96dc775 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3300,6 +3300,26 @@ static inline void i915_gem_drain_freed_objects(struct 
drm_i915_private *i915)
} while (flush_work(>mm.free_work));
 }
 
+static inline void i915_gem_drain_workqueue(struct drm_i915_private *i915)
+{
+   /*
+* Similar to objects above (see i915_gem_drain_freed-objects), in
+* general we have workers that are armed by RCU and then rearm
+* themselves in their callbacks. To be paranoid, we need to
+* drain the workqueue a second time after waiting for the RCU
+* grace period so that we catch work queued via RCU from the first
+* pass. As neither drain_workqueue() nor flush_workqueue() report
+* a result, we make an assumption that we only don't require more
+* than 2 passes to catch all recursive RCU delayed work.
+*
+*/
+   int pass = 2;
+   do {
+   rcu_barrier();
+   drain_workqueue(i915->wq);
+   } while (--pass);
+}
+
 struct i915_vma * __must_check
 i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
 const struct i915_ggtt_view *view,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 47613d20bba8..7a468cb30946 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -57,7 +57,7 @@ static void mock_device_release(struct drm_device *dev)
 
cancel_delayed_work_sync(>gt.retire_work);
cancel_delayed_work_sync(>gt.idle_work);
-   flush_workqueue(i915->wq);
+   i915_gem_drain_workqueue(i915);
 
mutex_lock(>drm.struct_mutex);
for_each_engine(engine, i915, id)
-- 
2.13.3

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Fixed16.16 wrapper cleanup & wm optimization (rev6)

2017-07-18 Thread Patchwork
== Series Details ==

Series: Fixed16.16 wrapper cleanup & wm optimization (rev6)
URL   : https://patchwork.freedesktop.org/series/25692/
State : success

== Summary ==

Series 25692v6 Fixed16.16 wrapper cleanup & wm optimization
https://patchwork.freedesktop.org/api/1.0/series/25692/revisions/6/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) k.org#196399
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101705 +1

k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:439s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:429s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:535s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-byt-j1900 total:279  pass:255  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:490s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:598s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:443s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:417s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:414s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:499s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:571s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:578s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:563s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:453s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:586s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:467s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:475s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:463s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:548s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:399s

10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC 
integration manifest
e6dea33 drm/i915/skl+: debugfs entry to control IPC
38552712 drm/i915/bxt+: Enable IPC support
1564688 drm/i915/gen9+: Add has_ipc flag in device info structure
fac25d3 drm/i915/cnl: Extend WM workaround with IPC for CNL
c99e00c drm/i915/glk: IPC linetime watermark workaround for GLK
c549418 drm/i915/gen10: Calculate and enable transition WM
a180ccf drm/i915/skl+: Optimize WM calculation
10e25f6 drm/i915: Fixed point fixed16 wrapper cleanup

== Logs ==

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


[Intel-gfx] [PATCH 7/8] drm/i915/bxt+: Enable IPC support

2017-07-18 Thread Mahesh Kumar
From: "Kumar, Mahesh" 

This patch adds IPC support. This patch also enables IPC in all supported
platforms based on has_ipc flag.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controls the memory read priority of Display.

When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.

Changes since V1:
 - Remove commandline parameter to disable ipc
 - Address Paulo's comments
Changes since V2:
 - Address review comments
 - Set ipc_enabled flag
Changes since V3:
 - move ipc_enabled flag assignment inside intel_ipc_enable function
Changes since V4:
 - Re-enable IPC after suspend/resume
Changes since V5:
 - Enable IPC for all gen >=9 except SKL
Changes since V6:
 - fix commit msg
 - after resume program IPC based on SW state.
Changes since V7:
 - Modify IPC support check based on HAS_IPC macro (suggested by Chris)

Signed-off-by: Mahesh Kumar 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c  |  4 +++-
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 24 
 5 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..c69958b55ee2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1338,7 +1338,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
intel_runtime_pm_enable(dev_priv);
 
-   dev_priv->ipc_enabled = false;
+   intel_init_ipc(dev_priv);
 
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
DRM_INFO("DRM_I915_DEBUG enabled\n");
@@ -2602,6 +2602,8 @@ static int intel_runtime_resume(struct device *kdev)
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
intel_hpd_init(dev_priv);
 
+   intel_enable_ipc(dev_priv);
+
enable_rpm_wakeref_asserts(dev_priv);
 
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01f92ab..4ceda0fc1baf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6728,6 +6728,7 @@ enum {
 #define  DISP_FBC_WM_DIS   (1<<15)
 #define DISP_ARB_CTL2  _MMIO(0x45004)
 #define  DISP_DATA_PARTITION_5_6   (1<<6)
+#define  DISP_IPC_ENABLE   (1<<3)
 #define DBUF_CTL   _MMIO(0x45008)
 #define  DBUF_POWER_REQUEST(1<<31)
 #define  DBUF_POWER_STATE  (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0ed454a23e34..0a5d6ba64925 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15733,6 +15733,7 @@ void intel_display_resume(struct drm_device *dev)
if (!ret)
ret = __intel_display_resume(dev, state, );
 
+   intel_enable_ipc(dev_priv);
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0902d7cb48d9..7b0e834a61f9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1883,6 +1883,8 @@ bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
 int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
  struct intel_crtc_state *cstate);
+void intel_init_ipc(struct drm_i915_private *dev_priv);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
 static inline int intel_enable_rc6(void)
 {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f2794d29f217..70f59df09e75 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5772,6 +5772,30 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
 }
 
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   val = I915_READ(DISP_ARB_CTL2);
+
+   if (dev_priv->ipc_enabled)
+   val |= DISP_IPC_ENABLE;
+   else
+   val &= ~DISP_IPC_ENABLE;
+
+   I915_WRITE(DISP_ARB_CTL2, val);
+}
+
+void intel_init_ipc(struct drm_i915_private *dev_priv)
+{
+   dev_priv->ipc_enabled = false;
+   if (!HAS_IPC(dev_priv))
+   return;
+
+   dev_priv->ipc_enabled = true;
+   intel_enable_ipc(dev_priv);
+}
+
 /*
  * Lock protecting IPS related data structures
  */

[Intel-gfx] [PATCH 8/8] drm/i915/skl+: debugfs entry to control IPC

2017-07-18 Thread Mahesh Kumar
From: "Kumar, Mahesh" 

This patch creates an entry in debugfs to check the status of IPC.
This can also be used to enable/disable IPC in supported platforms.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 73 -
 1 file changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2ef75c1a6119..368f64de0fdc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3592,6 +3592,76 @@ static int i915_wa_registers(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_ipc_status_show(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = m->private;
+
+   seq_printf(m, "Isochronous Priority Control: %s\n",
+   enableddisabled(dev_priv->ipc_enabled));
+   return 0;
+}
+
+static int i915_ipc_status_open(struct inode *inode, struct file *file)
+{
+   struct drm_i915_private *dev_priv = inode->i_private;
+
+   if (HAS_IPC(dev_priv))
+   return -ENODEV;
+
+   return single_open(file, i915_ipc_status_show, dev_priv);
+}
+
+static ssize_t i915_ipc_status_write(struct file *file, const char __user 
*ubuf,
+size_t len, loff_t *offp)
+{
+   struct seq_file *m = file->private_data;
+   struct drm_i915_private *dev_priv = m->private;
+   char *newline;
+   char tmp[16];
+   bool enable;
+
+   if (HAS_IPC(dev_priv))
+   return -ENODEV;
+
+   if (len >= sizeof(tmp))
+   return -EINVAL;
+
+   if (copy_from_user(tmp, ubuf, len))
+   return -EFAULT;
+
+   tmp[len] = '\0';
+
+   /* Strip newline, if any */
+   newline = strchr(tmp, '\n');
+   if (newline)
+   *newline = '\0';
+
+   if (strcmp(tmp, "0") == 0 || strcmp(tmp, "disable") == 0 ||
+   strcmp(tmp, "off") == 0 || strcmp(tmp, "dis") == 0)
+   enable = false;
+   else if (strcmp(tmp, "1") == 0 || strcmp(tmp, "enable") == 0 ||
+   strcmp(tmp, "on") == 0 || strcmp(tmp, "en") == 0)
+   enable = true;
+   else
+   return -EINVAL;
+
+   intel_runtime_pm_get(dev_priv);
+   dev_priv->ipc_enabled = enable;
+   intel_enable_ipc(dev_priv);
+   intel_runtime_pm_put(dev_priv);
+
+   return len;
+}
+
+static const struct file_operations i915_ipc_status_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_ipc_status_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_ipc_status_write
+};
+
 static int i915_ddb_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4929,7 +4999,8 @@ static const struct i915_debugfs_files {
{"i915_dp_test_type", _displayport_test_type_fops},
{"i915_dp_test_active", _displayport_test_active_fops},
{"i915_guc_log_control", _guc_log_control_fops},
-   {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops}
+   {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
+   {"i915_ipc_status", _ipc_status_fops}
 };
 
 int i915_debugfs_register(struct drm_i915_private *dev_priv)
-- 
2.13.0

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


[Intel-gfx] [PATCH 4/8] drm/i915/glk: IPC linetime watermark workaround for GLK

2017-07-18 Thread Mahesh Kumar
From: "Kumar, Mahesh" 

IF IPC is enabled LINETIME_WM value should be half of calculated value
 line time = ROUNDDOWN(1/2 * Calculated Line Time)

Earlier code was rounding-up the value, But updated Bspec says we should
take the ROUNDDOWN. This patch corrects that as well.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9a2ed1b734d5..dac0fcf8b54e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4571,9 +4571,10 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
 
linetime_wm = fixed16_to_u32_round_up(mul_u32_fixed16(8, linetime_us));
 
-   /* Display WA #1135: bxt. */
-   if (IS_BROXTON(dev_priv) && dev_priv->ipc_enabled)
-   linetime_wm = DIV_ROUND_UP(linetime_wm, 2);
+   /* Display WA #1135: bxt:ALL GLK:ALL */
+   if ((IS_BROXTON(dev_priv) || IS_GEMINILAKE(dev_priv)) &&
+   dev_priv->ipc_enabled)
+   linetime_wm /= 2;
 
return linetime_wm;
 }
-- 
2.13.0

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


[Intel-gfx] [PATCH 5/8] drm/i915/cnl: Extend WM workaround with IPC for CNL

2017-07-18 Thread Mahesh Kumar
From: "Kumar, Mahesh" 

CNL:A & CNL:B have same workaround as KBL to increase wm level latency
by 4us if IPC is enabled.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dac0fcf8b54e..f2794d29f217 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4447,7 +4447,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
 
/* Display WA #1141: kbl,cfl */
-   if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
+   if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
+   IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) &&
dev_priv->ipc_enabled)
latency += 4;
 
-- 
2.13.0

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


[Intel-gfx] [PATCH 6/8] drm/i915/gen9+: Add has_ipc flag in device info structure

2017-07-18 Thread Mahesh Kumar
From: "Kumar, Mahesh" 

New Isochronous Priority Control (IPC) capability is introduced in newer
GEN platforms. This patch adds a device info flag to indicate if platform
supports IPC. Patch also sets this flag in supported platforms.

Signed-off-by: Mahesh Kumar 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 -
 drivers/gpu/drm/i915/i915_pci.c | 4 
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 62ba18d6717f..47745e3de841 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -784,7 +784,8 @@ struct intel_csr {
func(cursor_needs_physical); \
func(hws_needs_physical); \
func(overlay_needs_physical); \
-   func(supports_tv);
+   func(supports_tv); \
+   func(has_ipc);
 
 struct sseu_dev_info {
u8 slice_mask;
@@ -3011,6 +3012,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
 #define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
 
+#define HAS_IPC(dev_priv)   ((dev_priv)->info.has_ipc)
+
 /*
  * For now, anything with a GuC requires uCode loading, and then supports
  * command submission once loaded. But these are logically independent
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a1e6b696bcfa..0dbdfe0f32a5 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -390,6 +390,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.has_full_ppgtt = 1, \
.has_full_48bit_ppgtt = 1, \
.has_reset_engine = 1, \
+   .has_ipc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
IVB_CURSOR_OFFSETS, \
BDW_COLORS
@@ -413,6 +414,7 @@ static const struct intel_device_info intel_geminilake_info 
= {
.platform = INTEL_KABYLAKE, \
.has_csr = 1, \
.has_guc = 1, \
+   .has_ipc = 1, \
.ddb_size = 896
 
 static const struct intel_device_info intel_kabylake_info = {
@@ -431,6 +433,7 @@ static const struct intel_device_info 
intel_kabylake_gt3_info = {
.platform = INTEL_COFFEELAKE, \
.has_csr = 1, \
.has_guc = 1, \
+   .has_ipc = 1, \
.ddb_size = 896
 
 static const struct intel_device_info intel_coffeelake_info = {
@@ -449,6 +452,7 @@ static const struct intel_device_info intel_cannonlake_info 
= {
.gen = 10,
.ddb_size = 1024,
.has_csr = 1,
+   .has_ipc = 1,
.color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
 };
 
-- 
2.13.0

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


[Intel-gfx] [PATCH 2/8] drm/i915/skl+: Optimize WM calculation

2017-07-18 Thread Mahesh Kumar
From: "Kumar, Mahesh" 

Plane configuration parameters doesn't change for each WM-level
calculation. Currently we compute same parameters 8 times for each
wm-level.
This patch optimizes it by calculating these parameters in beginning
& reuse during each level-wm calculation.

Signed-off-by: Mahesh Kumar 
Acked-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h |  13 +++
 drivers/gpu/drm/i915/intel_pm.c | 179 ++--
 2 files changed, 111 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 96edced67e10..62ba18d6717f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1790,6 +1790,19 @@ struct skl_wm_level {
uint8_t plane_res_l;
 };
 
+/* Stores plane specific WM parameters */
+struct skl_wm_params{
+   bool x_tiled, y_tiled;
+   uint32_t width;
+   uint8_t cpp;
+   uint32_t plane_pixel_rate;
+   uint32_t y_min_scanlines;
+   uint32_t plane_bytes_per_line;
+   uint_fixed_16_16_t plane_blocks_per_line;
+   uint_fixed_16_16_t y_tile_minimum;
+   uint32_t linetime_us;
+};
+
 /*
  * This struct helps tracking the state needed for runtime PM, which puts the
  * device in PCI D3 state. Notice that when this happens, nothing on the
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee2a349cfe68..b2bd65847d9b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4341,128 +4341,135 @@ skl_adjusted_plane_pixel_rate(const struct 
intel_crtc_state *cstate,
downscale_amount);
 }
 
-static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
-   struct intel_crtc_state *cstate,
-   const struct intel_plane_state *intel_pstate,
-   uint16_t ddb_allocation,
-   int level,
-   uint16_t *out_blocks, /* out */
-   uint8_t *out_lines, /* out */
-   bool *enabled /* out */)
+static int
+skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
+   struct intel_crtc_state *cstate,
+   const struct intel_plane_state *intel_pstate,
+   struct skl_wm_params *wp)
 {
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = _pstate->base;
const struct drm_framebuffer *fb = pstate->fb;
-   uint32_t latency = dev_priv->wm.skl_latency[level];
-   uint_fixed_16_16_t method1, method2;
-   uint_fixed_16_16_t plane_blocks_per_line;
-   uint_fixed_16_16_t selected_result;
uint32_t interm_pbpl;
-   uint32_t plane_bytes_per_line;
-   uint32_t res_blocks, res_lines;
-   uint8_t cpp;
-   uint32_t width = 0;
-   uint32_t plane_pixel_rate;
-   uint_fixed_16_16_t y_tile_minimum;
-   uint32_t y_min_scanlines;
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
-   bool y_tiled, x_tiled;
 
-   if (latency == 0 ||
-   !intel_wm_plane_visible(cstate, intel_pstate)) {
-   *enabled = false;
+   if (!intel_wm_plane_visible(cstate, intel_pstate))
return 0;
-   }
 
-   y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED;
-   x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
-
-   /* Display WA #1141: kbl,cfl */
-   if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
-   dev_priv->ipc_enabled)
-   latency += 4;
-
-   if (apply_memory_bw_wa && x_tiled)
-   latency += 15;
+   wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED;
+   wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
 
if (plane->id == PLANE_CURSOR) {
-   width = intel_pstate->base.crtc_w;
+   wp->width = intel_pstate->base.crtc_w;
} else {
/*
 * Src coordinates are already rotated by 270 degrees for
 * the 90/270 degree plane rotation cases (to match the
 * GTT mapping), hence no need to account for rotation here.
 */
-   width = drm_rect_width(_pstate->base.src) >> 16;
+   wp->width = drm_rect_width(_pstate->base.src) >> 16;
}
 
-   cpp = (fb->format->format == DRM_FORMAT_NV12) ? fb->format->cpp[1] :
-   fb->format->cpp[0];
-   

[Intel-gfx] [PATCH 3/8] drm/i915/gen10: Calculate and enable transition WM

2017-07-18 Thread Mahesh Kumar
From: "Kumar, Mahesh" 

GEN > 9 require transition WM to be programmed if IPC is enabled.
This patch calculates & enable transition WM for supported platforms.
If transition WM is enabled, Plane read requests are sent at high
priority until filling above the transition watermark, then the
requests are sent at lower priority until dropping below the level-0 WM.
The lower priority requests allow other memory clients to have better
memory access.

transition minimum is the minimum amount needed for trans_wm to work to
ensure  the demote does not happen before enough data has been read to
meet the level 0 watermark requirements.

transition amount is configurable value. Higher values will
tend to cause longer periods of high priority reads followed by longer
periods of lower priority reads. Tuning to lower values will tend to
cause shorter periods of high and lower priority reads.

Keeping transition amount to 10 in this patch, as suggested by HW team.

Signed-off-by: Mahesh Kumar 
Acked-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 51 +++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b2bd65847d9b..9a2ed1b734d5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4579,12 +4579,55 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
 }
 
 static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
+ struct skl_wm_params *wp,
+ struct skl_wm_level *wm_l0,
+ uint16_t ddb_allocation,
  struct skl_wm_level *trans_wm /* out */)
 {
+   struct drm_device *dev = cstate->base.crtc->dev;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   uint16_t trans_min, trans_y_tile_min;
+   uint16_t trans_amount = 10; /* This is configurable amount */
+   uint16_t trans_offset_b, res_blocks;
+
if (!cstate->base.active)
+   goto exit;
+
+   /* Transition WM are not recommended by HW team for GEN9 */
+   if (INTEL_GEN(dev_priv) <= 9)
+   goto exit;
+
+   /* Transition WM don't make any sense if ipc is disabled */
+   if (!dev_priv->ipc_enabled)
+   goto exit;
+
+   if (INTEL_GEN(dev_priv) >= 10)
+   trans_min = 4;
+
+   trans_offset_b = trans_min + trans_amount;
+   trans_y_tile_min = (uint16_t) mul_round_up_u32_fixed16(2,
+   wp->y_tile_minimum);
+
+   if (wp->y_tiled) {
+   res_blocks = max(wm_l0->plane_res_b, trans_y_tile_min) +
+   trans_offset_b;
+   } else {
+   res_blocks = wm_l0->plane_res_b + trans_offset_b;
+   }
+
+   res_blocks += 1;
+
+   /* WA BUG:1938466 add one block for non y-tile planes */
+   if (!wp->y_tiled && IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))
+   res_blocks += 1;
+
+   if (res_blocks < ddb_allocation) {
+   trans_wm->plane_res_b = res_blocks;
+   trans_wm->plane_en = true;
return;
+   }
 
-   /* Until we know more, just disable transition WMs */
+exit:
trans_wm->plane_en = false;
 }
 
@@ -4611,8 +4654,11 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
to_intel_plane_state(pstate);
enum plane_id plane_id = to_intel_plane(plane)->id;
struct skl_wm_params wm_params;
+   enum pipe pipe = to_intel_crtc(cstate->base.crtc)->pipe;
+   uint16_t ddb_blocks;
 
wm = _wm->planes[plane_id];
+   ddb_blocks = skl_ddb_entry_size(>plane[pipe][plane_id]);
memset(_params, 0, sizeof(struct skl_wm_params));
 
ret = skl_compute_plane_wm_params(dev_priv, cstate,
@@ -4624,7 +4670,8 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
intel_pstate, _params, wm);
if (ret)
return ret;
-   skl_compute_transition_wm(cstate, >trans_wm);
+   skl_compute_transition_wm(cstate, _params, >wm[0],
+ ddb_blocks, >trans_wm);
}
pipe_wm->linetime = skl_compute_linetime_wm(cstate);
 
-- 
2.13.0

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


[Intel-gfx] [PATCH 1/8] drm/i915: Fixed point fixed16 wrapper cleanup

2017-07-18 Thread Mahesh Kumar
From: "Kumar, Mahesh" 

As per suggestion from Jani, cleanup the code. Cleanup includes
 - Instead of left shifting & check, compare with U32/16_MAX
 - Use typecast instead of clamp_t

Signed-off-by: Mahesh Kumar 
Cc: Jani Nikula 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c6fab08a2e6..96edced67e10 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -126,7 +126,7 @@ static inline uint_fixed_16_16_t u32_to_fixed16(uint32_t 
val)
 {
uint_fixed_16_16_t fp;
 
-   WARN_ON(val >> 16);
+   WARN_ON(val > U16_MAX);
 
fp.val = val << 16;
return fp;
@@ -163,8 +163,8 @@ static inline uint_fixed_16_16_t 
max_fixed16(uint_fixed_16_16_t max1,
 static inline uint_fixed_16_16_t clamp_u64_to_fixed16(uint64_t val)
 {
uint_fixed_16_16_t fp;
-   WARN_ON(val >> 32);
-   fp.val = clamp_t(uint32_t, val, 0, ~0);
+   WARN_ON(val > U32_MAX);
+   fp.val = (uint32_t) val;
return fp;
 }
 
@@ -181,8 +181,8 @@ static inline uint32_t mul_round_up_u32_fixed16(uint32_t 
val,
 
intermediate_val = (uint64_t) val * mul.val;
intermediate_val = DIV_ROUND_UP_ULL(intermediate_val, 1 << 16);
-   WARN_ON(intermediate_val >> 32);
-   return clamp_t(uint32_t, intermediate_val, 0, ~0);
+   WARN_ON(intermediate_val > U32_MAX);
+   return (uint32_t) intermediate_val;
 }
 
 static inline uint_fixed_16_16_t mul_fixed16(uint_fixed_16_16_t val,
@@ -211,8 +211,8 @@ static inline uint32_t div_round_up_u32_fixed16(uint32_t 
val,
 
interm_val = (uint64_t)val << 16;
interm_val = DIV_ROUND_UP_ULL(interm_val, d.val);
-   WARN_ON(interm_val >> 32);
-   return clamp_t(uint32_t, interm_val, 0, ~0);
+   WARN_ON(interm_val > U32_MAX);
+   return (uint32_t) interm_val;
 }
 
 static inline uint_fixed_16_16_t mul_u32_fixed16(uint32_t val,
-- 
2.13.0

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


[Intel-gfx] [PATCH 0/8] Fixed16.16 wrapper cleanup & wm optimization

2017-07-18 Thread Mahesh Kumar
This series Include patches for:
clean fixed16.16 wrappers
optimize wm calculation code
enable/Implement trans wm calculation
create a DebugFS entry for IPC status

Mahesh Kumar (8):
  drm/i915: Fixed point fixed16 wrapper cleanup
  drm/i915/skl+: Optimize WM calculation
  drm/i915/gen10: Calculate and enable transition WM
  drm/i915/glk: IPC linetime watermark workaround for GLK
  drm/i915/cnl: Extend WM workaround with IPC for CNL
  drm/i915/gen9+: Add has_ipc flag in device info structure
  drm/i915/bxt+: Enable IPC support
  drm/i915/skl+: debugfs entry to control IPC

 drivers/gpu/drm/i915/i915_debugfs.c  |  73 +-
 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |  32 +++--
 drivers/gpu/drm/i915/i915_pci.c  |   4 +
 drivers/gpu/drm/i915/i915_reg.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |   1 +
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 262 +++
 8 files changed, 283 insertions(+), 96 deletions(-)

-- 
2.13.0

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


Re: [Intel-gfx] [PATCH v3 0/2] Handle unsupported configuration with IF-ID

2017-07-18 Thread Mahesh Kumar

Hi Daniel,


On Monday 17 July 2017 12:56 PM, Daniel Vetter wrote:

On Fri, Jun 30, 2017 at 05:40:58PM +0530, Mahesh Kumar wrote:

Gen9+ Interlace fetch mode doesn't support few plane configurations & pipe 
scaling.
  - Y-tile
  - 90/270 rotation
  - pipe/plane scaling
  - 420 planar formats

Do we have igt testcases that try to exercise all this? When fixing bugs,
pls make sure you don't fix the bugs, but also make sure we have solid
coverage. Given that this escaped for years, it's very likely our coverage
is _really_ bad and needs to be improve a lot for testing interlaced modes
...
We have testdisplay with -y option to test Y-tiling (90/270 rotation 
need Y-tiling so those are also covered).
But AFAIK we don't have any testcase to verify scaling with Interlace 
mode & other combinations.
Should we extend existing IGT test for 
scaling/rotation/tiling/pixel-format to include Interlace mode as well, 
or should we have a separate Interlace mode specific IGT

which will exercise all combinations with all Interlace modes?

As IF-ID mode doesn't support all the above combination but *PF-ID mode 
does support them* from GEN9(scaling Y-tile 90/270 rotation etc). So I 
submitted a patch to always enable PF-ID mode for Interlace

https://patchwork.freedesktop.org/patch/160275/
But Ville suggested not to always enable PF-ID mode instead control 
fetching mode based on property.
Currently there is no open source user for this property. What will you 
suggest here?


Thanks,
-Mahesh

Thanks, Daniel


Changes since V2:
  - Address review comments from ville

Mahesh Kumar (2):
   drm/i915/skl+: Check for supported plane configuration in Interlace
 mode
   drm/i915/skl+: Scaling not supported in IF-ID Interlace mode

  drivers/gpu/drm/i915/intel_atomic_plane.c | 15 +++
  drivers/gpu/drm/i915/intel_display.c  | 15 +++
  2 files changed, 30 insertions(+)

--
2.13.0

___
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] ✓ Fi.CI.BAT: success for net/sch_generic: Shut up noise

2017-07-18 Thread Daniel Vetter
On Tue, Jul 18, 2017 at 11:14:35AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: net/sch_generic: Shut up noise
> URL   : https://patchwork.freedesktop.org/series/27475/
> State : success
> 
> == Summary ==
> 
> Series 27475v1 net/sch_generic: Shut up noise
> https://patchwork.freedesktop.org/api/1.0/series/27475/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> dmesg-warn -> PASS   (fi-kbl-r) k.org#196399
> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597
> 
> k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399
> fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597

Thrown into our core-for-CI branch. Note that most likely it's e1000e
failure, core networking is simply the canary. And e1000e fail takes
forever to get addressed :-(

Thanks, Daniel

> 
> fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
> time:444s
> fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
> time:431s
> fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
> time:360s
> fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
> time:525s
> fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
> time:504s
> fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
> time:488s
> fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
> time:490s
> fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
> time:604s
> fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
> time:433s
> fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
> time:415s
> fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
> time:415s
> fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:490s
> fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:471s
> fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:462s
> fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
> time:567s
> fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:582s
> fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
> time:557s
> fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
> time:457s
> fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
> time:587s
> fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
> time:465s
> fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
> time:479s
> fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
> time:437s
> fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
> time:466s
> fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
> time:542s
> fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
> time:405s
> 
> 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s 
> UTC integration manifest
> 8cc4ab5 net/sch_generic: Shut up noise
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5217/

-- 
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


  1   2   >