Re: [Intel-gfx] [Announcement] 2016-Q1 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Jike Song]

Hi all,

We are pleased to announce another update of Intel GVT-g for Xen.

Intel GVT-g is a full GPU virtualization solution with mediated pass-through, 
starting from 4th generation Intel Core(TM) processors with Intel Graphics 
processors. A virtual GPU instance is maintained for each VM, with part of 
performance critical resources directly assigned. The capability of running 
native graphics driver inside a VM, without hypervisor intervention in 
performance critical paths, achieves a good balance among performance, feature, 
and sharing capability. Xen is currently supported on Intel Processor Graphics 
(a.k.a. XenGT).


Repositories
-

Kernel: https://github.com/01org/igvtg-kernel (2016q1-4.3.0 branch)
Xen: https://github.com/01org/igvtg-xen (2016q1-4.6 branch)
Qemu: https://github.com/01org/igvtg-qemu (2016q1-2.3.0 branch)

This update consists of:
-Windows 10 guest is preliminarily supported in this release. 
-Implemented vgtbuffer(Indirect display) feature on SKL platform.
-Backward compatibility support 5th generation (Broadwell)
-Increased VGT stability on SKL platform
-Kernel updated from drm-intel 4.2.0 to drm-intel 4.3.0
-Xen updated from Xen 4.5.0 to Xen 4.6.0
-Qemu updated from 1.6 to 2.3

Known issues:
-At least 2GB memory is suggested for VM(win7-32/64, win8.1 64) to run most 
3D workloads.
-Windows 7 GFX driver upgrading only works on Safe mode.
-Some media decode can't work well (will be resolved in the next version 
Windows GFX driver). 
-Windows8 and later Windows fast boot is not supported, whose workaround is 
to disable power S3/S4 in HVM file by adding "acpi_s3=0, acpi_s4=0"
-Sometimes when dom0 and guest have heavy workload, i915 in dom0 will 
trigger a false graphics reset. The workaround is to disable dom0 hangcheck in 
dom0 grub file by adding "i915.enable_hangcheck=0"

Next update will be around early July, 2016.

GVT-g project portal:
https://01.org/igvt-g

Please subscribe the mailing list:
https://lists.01.org/mailman/listinfo/igvt-g


More information about background, architecture and others about Intel GVT-g, 
can be found at:

https://01.org/igvt-g
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-REWRITE%203RD%20v4.pdf
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt


Note: The XenGT project should be considered a work in progress. As such it is 
not a complete product nor should it be considered one. Extra care should be 
taken when testing and configuring a system to use the XenGT project.


--
Thanks,
Jike

On 01/27/2016 02:21 PM, Jike Song wrote:
> Hi all,
> 
> We are pleased to announce another update of Intel GVT-g for Xen.
> 
> Intel GVT-g is a full GPU virtualization solution with mediated pass-through, 
> starting from 4th generation Intel Core(TM) processors with Intel Graphics 
> processors. A virtual GPU instance is maintained for each VM, with part of 
> performance critical resources directly assigned. The capability of running 
> native graphics driver inside a VM, without hypervisor intervention in 
> performance critical paths, achieves a good balance among performance, 
> feature, and sharing capability. Xen is currently supported on Intel 
> Processor Graphics (a.k.a. XenGT).
> 
> Repositories
> -
> 
> Kernel: https://github.com/01org/igvtg-kernel (2015q4-4.2.0 branch)
> Xen: https://github.com/01org/igvtg-xen (2015q4-4.5 branch)
> Qemu: https://github.com/01org/igvtg-qemu (xengt_public2015q4 branch)
> 
> This update consists of:
> 
>   - 6th generation Intel Core Processor (code name: Skylake) is 
> preliminarily supported in this release. Users could start run multiple 
> Windows / Linux virtual machines simultaneously, and switch display among 
> them.
>   - Backward compatibility support 4th generation Intel Core Processor 
> (code name: Haswell) and 5th generation Intel Core Processor (code name: 
> Broadwell).
>   - Kernel update from drm-intel 3.18.0 to drm-intel 4.2.0.
> 
> Known issues:
>- At least 2GB memory is suggested for a VM to run most 3D workloads.
>- Keymap might be incorrect in guest. Config file may need to explicitly 
> specify "keymap='en-us'". Although it looks like the default value, earlier 
> we saw the problem of wrong keymap code if it is not explicitly set.
>- Cannot move mouse pointer smoothly in guest by default launched by VNC 
> mode. Configuration file need to explicitly specify "usb=1" to enable a USB 
> bus, and "usbdevice='tablet'" to add pointer device using absolute 
> coordinates.
>- Running heavy 3D workloads in multiple guests for couple of hours may 
> cause stability issue.
>- There are still stability issues on Skylake
> 
> 
> 

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

[Stephen Rothwell]

Hi Dave,

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

drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_prepare_ddi_buffer':
drivers/gpu/drm/i915/intel_ddi.c:447:15: error: 'struct drm_i915_private' has 
no member named 'edp_low_vswing'
   if (dev_priv->edp_low_vswing) {
   ^

Caused by commit

  06411f08b3f3 ("drm/i915: move edp low vswing config to vbt data")

interacting with commit

  992e7a41f9fc ("drm/i915: Fix eDP low vswing for Broadwell")

from the drm-intel-fixes tree.

I applied the following merge fixup patch (which is suggested by the "v3:
Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing"
comment in the drm-intel-fixes tree patch, but clearly could not be
done there).

From: Stephen Rothwell 
Date: Thu, 28 Apr 2016 11:53:36 +1000
Subject: [PATCH] drm/i915: fix up for edp_low_vswing change

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/intel_ddi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 6080b5481984..e304857ba405 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -444,7 +444,7 @@ void intel_prepare_ddi_buffer(struct intel_encoder *encoder)
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
 
-   if (dev_priv->edp_low_vswing) {
+   if (dev_priv->vbt.edp.low_vswing) {
ddi_translations_edp = bdw_ddi_translations_edp;
n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
} else {
-- 
2.7.0

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

[Intel-gfx] [PATCH 04/21] drm/i915/slpc: Add enable_slpc module parameter

[tom . orourke]

From: Tom O'Rourke 

i915.enable_slpc is used to override the default for slpc usage.
The expected values are -1=auto, 0=disabled [default], 1=enabled.

slpc_enable_sanitize() converts i915.enable_slpc to either 0 or 1.
Interpretation of default value is based on HAS_SLPC(), after
slpc_version_check().  This function also enforces the requirement
that guc_submission is required for slpc.

intel_slpc_enabled() returns 1 if SLPC should be used.

v2: Add early call to sanitize enable_slpc in intel_guc_ucode_init

Suggested-by: Paulo Zanoni 
Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_params.c  |  6 ++
 drivers/gpu/drm/i915/i915_params.h  |  1 +
 drivers/gpu/drm/i915/intel_guc.h|  6 ++
 drivers/gpu/drm/i915/intel_guc_loader.c | 19 +++
 4 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 383c076..9617bc2 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -36,6 +36,7 @@ struct i915_params i915 __read_mostly = {
.enable_dc = -1,
.enable_fbc = -1,
.enable_execlists = -1,
+   .enable_slpc = 0,
.enable_hangcheck = true,
.enable_ppgtt = -1,
.enable_psr = -1,
@@ -128,6 +129,11 @@ MODULE_PARM_DESC(enable_execlists,
"Override execlists usage. "
"(-1=auto [default], 0=disabled, 1=enabled)");
 
+module_param_named_unsafe(enable_slpc, i915.enable_slpc, int, 0400);
+MODULE_PARM_DESC(enable_slpc,
+   "Override single-loop-power-controller (slpc) usage. "
+   "(-1=auto, 0=disabled [default], 1=enabled)");
+
 module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
 MODULE_PARM_DESC(enable_psr, "Enable PSR "
 "(0=disabled, 1=enabled - link mode chosen per-platform, 
2=force link-standby mode, 3=force link-off mode) "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 65e73dd..e9f7eed 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -39,6 +39,7 @@ struct i915_params {
int enable_fbc;
int enable_ppgtt;
int enable_execlists;
+   int enable_slpc;
int enable_psr;
unsigned int preliminary_hw_support;
int disable_power_well;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 4d24856..cecfe4e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -137,6 +137,12 @@ struct intel_guc {
uint32_t last_seqno[GUC_MAX_ENGINES_NUM];
 };
 
+static inline int intel_slpc_enabled(void)
+{
+   WARN_ON(i915.enable_slpc < 0);
+   return i915.enable_slpc;
+}
+
 /* intel_guc_loader.c */
 extern void intel_guc_ucode_init(struct drm_device *dev);
 extern int intel_guc_ucode_load(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 87702cd..174cc34 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -116,6 +116,21 @@ static void direct_interrupts_to_guc(struct 
drm_i915_private *dev_priv)
I915_WRITE(GUC_WD_VECS_IER, ~irqs);
 }
 
+static void slpc_enable_sanitize(struct drm_device *dev)
+{
+   /* handle default case */
+   if (i915.enable_slpc < 0)
+   i915.enable_slpc = HAS_SLPC(dev);
+
+   /* slpc requires hardware support and compatible firmware */
+   if (!HAS_SLPC(dev))
+   i915.enable_slpc = 0;
+
+   /* slpc requires guc submission */
+   if (!i915.enable_guc_submission)
+   i915.enable_slpc = 0;
+}
+
 static void slpc_version_check(struct drm_device *dev,
   struct intel_guc_fw *guc_fw)
 {
@@ -126,6 +141,8 @@ static void slpc_version_check(struct drm_device *dev,
info = (struct intel_device_info *) _priv->info;
info->has_slpc = 0;
}
+
+   slpc_enable_sanitize(dev);
 }
 
 static u32 get_gttype(struct drm_i915_private *dev_priv)
@@ -657,6 +674,8 @@ void intel_guc_ucode_init(struct drm_device *dev)
fw_path = "";   /* unknown device */
}
 
+   slpc_enable_sanitize(dev);
+
if (!i915.enable_guc_submission)
return;
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 20/21] drm/i915/slpc: Add i915_slpc_info to debugfs

[tom . orourke]

From: Tom O'Rourke 

i915_slpc_info shows the contents of SLPC shared data
parsed into text format.

v2: reformat slpc info (Radek)
squashed query task state info
in slpc info, kunmap before seq_print (Paulo)
return void instead of ignored return value (Paulo)
v3: Avoid magic numbers and use local variables (Jon Bloomfield)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 184 
 drivers/gpu/drm/i915/intel_slpc.c   |  23 +
 drivers/gpu/drm/i915/intel_slpc.h   |   3 +
 3 files changed, 210 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8b39a13..5f3780c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1404,6 +1404,189 @@ static const struct file_operations i915_slpc_dcc_fops 
= {
.llseek  = seq_lseek
 };
 
+static int i915_slpc_info(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   void *pv = NULL;
+   struct slpc_shared_data data;
+   int i, value;
+   enum slpc_global_state global_state;
+   enum slpc_platform_sku platform_sku;
+   enum slpc_host_os host_os;
+   enum slpc_power_plan power_plan;
+   enum slpc_power_source power_source;
+
+   obj = dev_priv->guc.slpc.shared_data_obj;
+   if (obj) {
+   intel_slpc_query_task_state(dev);
+
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   pv = kmap_atomic(page);
+   }
+
+   if (pv) {
+   data = *(struct slpc_shared_data *) pv;
+   kunmap_atomic(pv);
+
+   seq_printf(m, "SLPC Version: %d.%d.%d (0x%8x)\n",
+  data.slpc_version >> 16,
+  (data.slpc_version >> 8) & 0xFF,
+  data.slpc_version & 0xFF,
+  data.slpc_version);
+   seq_printf(m, "shared data size: %d\n", data.shared_data_size);
+
+   global_state = (enum slpc_global_state) data.global_state;
+   seq_printf(m, "global state: %d (", global_state);
+   switch (global_state) {
+   case SLPC_GLOBAL_STATE_NOT_RUNNING:
+   seq_puts(m, "not running)\n");
+   break;
+   case SLPC_GLOBAL_STATE_INITIALIZING:
+   seq_puts(m, "initializing)\n");
+   break;
+   case SLPC_GLOBAL_STATE_RESETTING:
+   seq_puts(m, "resetting)\n");
+   break;
+   case SLPC_GLOBAL_STATE_RUNNING:
+   seq_puts(m, "running)\n");
+   break;
+   case SLPC_GLOBAL_STATE_SHUTTING_DOWN:
+   seq_puts(m, "shutting down)\n");
+   break;
+   case SLPC_GLOBAL_STATE_ERROR:
+   seq_puts(m, "error)\n");
+   break;
+   default:
+   seq_puts(m, "unknown)\n");
+   break;
+   }
+
+   platform_sku = (enum slpc_platform_sku)
+   data.platform_info.platform_sku;
+   seq_printf(m, "sku: %d (", platform_sku);
+   switch (platform_sku) {
+   case SLPC_PLATFORM_SKU_UNDEFINED:
+   seq_puts(m, "undefined)\n");
+   break;
+   case SLPC_PLATFORM_SKU_ULX:
+   seq_puts(m, "ULX)\n");
+   break;
+   case SLPC_PLATFORM_SKU_ULT:
+   seq_puts(m, "ULT)\n");
+   break;
+   case SLPC_PLATFORM_SKU_T:
+   seq_puts(m, "T)\n");
+   break;
+   case SLPC_PLATFORM_SKU_MOBL:
+   seq_puts(m, "Mobile)\n");
+   break;
+   case SLPC_PLATFORM_SKU_DT:
+   seq_puts(m, "DT)\n");
+   break;
+   case SLPC_PLATFORM_SKU_UNKNOWN:
+   default:
+   seq_puts(m, "unknown)\n");
+   break;
+   }
+   seq_printf(m, "slice count: %d\n",
+  data.platform_info.slice_count);
+
+   host_os = (enum slpc_host_os) data.platform_info.host_os;
+   seq_printf(m, "host OS: %d (", host_os);
+   switch (host_os) {
+   case SLPC_HOST_OS_UNDEFINED:
+   seq_puts(m, "undefined)\n");
+   break;
+   case SLPC_HOST_OS_WINDOWS_8:
+ 

[Intel-gfx] [PATCH 21/21] drm/i915/slpc: Fail intel_runtime_suspend if SLPC or RPS not active

[tom . orourke]

From: Sagar Arun Kamble 

intel_runtime_suspend failed with warning if RPS was disabled.
With SLPC enabled, RPS is disabled. With SLPC, warning is now changed
to consider SLPC active status as well. This will ensure runtime suspend
proceeds when SLPC enabled.

v2: Commit message update. (Tom)

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc22fa0..00a2713 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1474,7 +1474,8 @@ static int intel_runtime_suspend(struct device *device)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
-   if (WARN_ON_ONCE(!(dev_priv->rps.enabled && intel_enable_rc6(dev
+   if (WARN_ON_ONCE(!((dev_priv->rps.enabled || intel_slpc_active(dev)) &&
+  intel_enable_rc6(dev
return -ENODEV;
 
if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev)))
-- 
1.9.1

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

[Intel-gfx] [PATCH 08/21] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

[tom . orourke]

From: Tom O'Rourke 

SLPC shared data is used to pass information
to/from SLPC firmware.

For Skylake, platform sku type and slice count
are identified from device id and fuse values.

Support for other platforms needs to be added.

v2: Update for SLPC interface version 2015.2.4
intel_slpc_active() returns 1 if slpc initialized (Paulo)
v3: change default host_os to "Windows"
v4: Spelling fixes (Sagar Kamble and Nick Hoath)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_drv.h  |  8 +++-
 drivers/gpu/drm/i915/intel_guc.h  |  2 +
 drivers/gpu/drm/i915/intel_slpc.c | 84 ++-
 drivers/gpu/drm/i915/intel_slpc.h | 75 ++
 4 files changed, 166 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9d02835..47e538a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1593,7 +1593,13 @@ bool chv_phy_powergate_ch(struct drm_i915_private 
*dev_priv, enum dpio_phy phy,
 
 static inline int intel_slpc_active(struct drm_device *dev)
 {
-   return 0;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int ret = 0;
+
+   if (dev_priv->guc.slpc.shared_data_obj)
+   ret = 1;
+
+   return ret;
 }
 
 /* intel_pm.c */
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 2d4571e..c55fb5b 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -136,6 +136,8 @@ struct intel_guc {
 
uint64_t submissions[GUC_MAX_ENGINES_NUM];
uint32_t last_seqno[GUC_MAX_ENGINES_NUM];
+
+   struct intel_slpc slpc;
 };
 
 static inline int intel_slpc_enabled(void)
diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 474fac0..5e039d5 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -22,17 +22,97 @@
  *
  */
 #include 
+#include 
 #include "i915_drv.h"
 #include "intel_guc.h"
 
+static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
+{
+   struct drm_device *dev = obj->base.dev;
+   enum slpc_platform_sku platform_sku;
+
+   if (IS_SKL_ULX(dev))
+   platform_sku = SLPC_PLATFORM_SKU_ULX;
+   else if (IS_SKL_ULT(dev))
+   platform_sku = SLPC_PLATFORM_SKU_ULT;
+   else
+   platform_sku = SLPC_PLATFORM_SKU_DT;
+
+   return (u8) platform_sku;
+}
+
+static u8 slpc_get_slice_count(struct drm_i915_gem_object *obj)
+{
+   struct drm_device *dev = obj->base.dev;
+   u8 slice_count = 1;
+
+   if (IS_SKYLAKE(dev))
+   slice_count = INTEL_INFO(dev)->slice_total;
+
+   return slice_count;
+}
+
+static void slpc_shared_data_init(struct drm_i915_gem_object *obj)
+{
+   struct page *page;
+   struct slpc_shared_data *data;
+   u64 msr_value;
+
+   page = i915_gem_object_get_page(obj, 0);
+   if (page) {
+   data = kmap_atomic(page);
+   memset(data, 0, sizeof(struct slpc_shared_data));
+
+   data->slpc_version = SLPC_VERSION;
+   data->shared_data_size = sizeof(struct slpc_shared_data);
+   data->global_state = (u32) SLPC_GLOBAL_STATE_NOT_RUNNING;
+   data->platform_info.platform_sku = slpc_get_platform_sku(obj);
+   data->platform_info.slice_count = slpc_get_slice_count(obj);
+   data->platform_info.host_os = (u8) SLPC_HOST_OS_WINDOWS_8;
+   data->platform_info.power_plan_source =
+   (u8) SLPC_POWER_PLAN_SOURCE(SLPC_POWER_PLAN_BALANCED,
+   SLPC_POWER_SOURCE_AC);
+   rdmsrl(MSR_TURBO_RATIO_LIMIT, msr_value);
+   data->platform_info.P0_freq = (u8) msr_value;
+   rdmsrl(MSR_PLATFORM_INFO, msr_value);
+   data->platform_info.P1_freq = (u8) (msr_value >> 8);
+   data->platform_info.Pe_freq = (u8) (msr_value >> 40);
+   data->platform_info.Pn_freq = (u8) (msr_value >> 48);
+   rdmsrl(MSR_PKG_POWER_LIMIT, msr_value);
+   data->platform_info.package_rapl_limit_high =
+   (u32) (msr_value >> 32);
+   data->platform_info.package_rapl_limit_low = (u32) msr_value;
+
+   kunmap_atomic(data);
+   }
+}
+
 void intel_slpc_init(struct drm_device *dev)
 {
-   return;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_gem_object *obj;
+
+   /* Allocate shared data structure */
+   obj = dev_priv->guc.slpc.shared_data_obj;
+   if (!obj) {
+   obj = gem_allocate_guc_obj(dev_priv->dev,
+   PAGE_ALIGN(sizeof(struct slpc_shared_data)));
+   dev_priv->guc.slpc.shared_data_obj = obj;
+   }
+
+

[Intel-gfx] [PATCH 12/21] drm/i915/slpc: Send shutdown event

[tom . orourke]

From: Tom O'Rourke 

Send SLPC shutdown event during disable, suspend, and reset
operations.  Sending shutdown event while already shutdown
is OK.

v2: return void instead of ignored error code (Paulo)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_slpc.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 3fd46ac..076d07b 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -56,6 +56,23 @@ static void host2guc_slpc_reset(struct drm_device *dev)
host2guc_slpc(dev_priv, data, 4);
 }
 
+static void host2guc_slpc_shutdown(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_gem_object *obj = dev_priv->guc.slpc.shared_data_obj;
+   u32 data[4];
+   u64 shared_data_gtt_offset = i915_gem_obj_ggtt_offset(obj);
+
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_SHUTDOWN, 2);
+   data[2] = lower_32_bits(shared_data_gtt_offset);
+   data[3] = upper_32_bits(shared_data_gtt_offset);
+
+   WARN_ON(0 != data[3]);
+
+   host2guc_slpc(dev_priv, data, 4);
+}
+
 static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
 {
struct drm_device *dev = obj->base.dev;
@@ -152,12 +169,14 @@ void intel_slpc_cleanup(struct drm_device *dev)
 
 void intel_slpc_suspend(struct drm_device *dev)
 {
-   return;
+   if (intel_slpc_active(dev))
+   host2guc_slpc_shutdown(dev);
 }
 
 void intel_slpc_disable(struct drm_device *dev)
 {
-   return;
+   if (intel_slpc_active(dev))
+   host2guc_slpc_shutdown(dev);
 }
 
 void intel_slpc_enable(struct drm_device *dev)
@@ -168,5 +187,8 @@ void intel_slpc_enable(struct drm_device *dev)
 
 void intel_slpc_reset(struct drm_device *dev)
 {
-   return;
+   if (intel_slpc_active(dev)) {
+   host2guc_slpc_shutdown(dev);
+   host2guc_slpc_reset(dev);
+   }
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH 11/21] drm/i915/slpc: Send reset event

[tom . orourke]

From: Tom O'Rourke 

Add host2guc SLPC reset event and send reset event
during enable.

v2: extract host2guc_slpc to handle slpc status code
coding style changes (Paulo)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_slpc.c | 33 -
 drivers/gpu/drm/i915/intel_slpc.h | 14 ++
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index bacbfed..3fd46ac 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -26,6 +26,36 @@
 #include "i915_drv.h"
 #include "intel_guc.h"
 
+static void host2guc_slpc(struct drm_i915_private *dev_priv, u32 *data, u32 
len)
+{
+   int ret = host2guc_action(_priv->guc, data, len);
+
+   if (!ret) {
+   ret = I915_READ(SOFT_SCRATCH(1));
+   ret &= SLPC_EVENT_STATUS_MASK;
+   }
+
+   if (ret)
+   DRM_ERROR("event 0x%x status %d\n", (data[1] >> 8), ret);
+}
+
+static void host2guc_slpc_reset(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_gem_object *obj = dev_priv->guc.slpc.shared_data_obj;
+   u32 data[4];
+   u64 shared_data_gtt_offset = i915_gem_obj_ggtt_offset(obj);
+
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_RESET, 2);
+   data[2] = lower_32_bits(shared_data_gtt_offset);
+   data[3] = upper_32_bits(shared_data_gtt_offset);
+
+   WARN_ON(data[3] != 0);
+
+   host2guc_slpc(dev_priv, data, 4);
+}
+
 static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
 {
struct drm_device *dev = obj->base.dev;
@@ -132,7 +162,8 @@ void intel_slpc_disable(struct drm_device *dev)
 
 void intel_slpc_enable(struct drm_device *dev)
 {
-   return;
+   if (intel_slpc_active(dev))
+   host2guc_slpc_reset(dev);
 }
 
 void intel_slpc_reset(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index 9badca9..0a9c0f2 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -28,6 +28,20 @@
 #define SLPC_MINOR_VER 4
 #define SLPC_VERSION ((2015 << 16) | (SLPC_MAJOR_VER << 8) | (SLPC_MINOR_VER))
 
+enum slpc_event_id {
+   SLPC_EVENT_RESET = 0,
+   SLPC_EVENT_SHUTDOWN = 1,
+   SLPC_EVENT_PLATFORM_INFO_CHANGE = 2,
+   SLPC_EVENT_DISPLAY_MODE_CHANGE = 3,
+   SLPC_EVENT_FLIP_COMPLETE = 4,
+   SLPC_EVENT_QUERY_TASK_STATE = 5,
+   SLPC_EVENT_PARAMETER_SET = 6,
+   SLPC_EVENT_PARAMETER_UNSET = 7,
+};
+
+#define SLPC_EVENT(id, argc) ((u32) (id) << 8 | (argc))
+#define SLPC_EVENT_STATUS_MASK 0xFF
+
 enum slpc_global_state {
SLPC_GLOBAL_STATE_NOT_RUNNING = 0,
SLPC_GLOBAL_STATE_INITIALIZING = 1,
-- 
1.9.1

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

[Intel-gfx] [PATCH 15/21] drm/i915/slpc: Notification of Refresh Rate change

[tom . orourke]

From: Sagar Arun Kamble 

This patch will inform GuC SLPC about changes in the refresh rate
due to Seamless DRRS. Refresh rate changes due to Static DRRS will
be notified via commit path.

v2: Rebased on previous changed patch and printed error message if
H2G action fails.
v2(torourke): Updates suggested by Paulo: replace HAS_SLPC with
intel_slpc_active. return void instead of ignored error code.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_dp.c   |  2 ++
 drivers/gpu/drm/i915/intel_slpc.c | 23 +++
 drivers/gpu/drm/i915/intel_slpc.h |  1 +
 3 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c12c414..3d41f7b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5379,6 +5379,8 @@ static void intel_dp_set_drrs_state(struct drm_device 
*dev, int refresh_rate)
dev_priv->drrs.refresh_rate_type = index;
 
DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
+
+   intel_slpc_update_display_rr_info(dev, refresh_rate);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 7f26284..9e0bc96 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -364,3 +364,26 @@ void intel_slpc_update_atomic_commit_info(struct 
drm_device *dev,
if (notify)
host2guc_slpc_display_mode_change(dev);
 }
+
+void intel_slpc_update_display_rr_info(struct drm_device *dev, u32 
refresh_rate)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc;
+   struct intel_display_pipe_info *per_pipe_info;
+   struct intel_slpc_display_mode_event_params *display_params;
+
+   if (!intel_slpc_active(dev))
+   return;
+
+   if (!refresh_rate)
+   return;
+
+   display_params = _priv->guc.slpc.display_mode_params;
+   crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+
+   per_pipe_info = 
_params->per_pipe_info[to_intel_crtc(crtc)->pipe];
+   per_pipe_info->refresh_rate = refresh_rate;
+   per_pipe_info->vsync_ft_usec = 100 / refresh_rate;
+
+   host2guc_slpc_display_mode_change(dev);
+}
diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index 39b4657..0b251a1 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -153,5 +153,6 @@ void intel_slpc_reset(struct drm_device *dev);
 void intel_slpc_update_display_mode_info(struct drm_device *dev);
 void intel_slpc_update_atomic_commit_info(struct drm_device *dev,
  struct drm_atomic_state *state);
+void intel_slpc_update_display_rr_info(struct drm_device *dev, u32 
refresh_rate);
 
 #endif
-- 
1.9.1

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

[Intel-gfx] [PATCH 13/21] drm/i915/slpc: Add Display mode event related data structures

[tom . orourke]

From: Sagar Arun Kamble 

v2: Cleaning up defines for number of pipes and other cosmetic changes.

v3: Checkpatch fixes.

Signed-off-by: Sagar Arun Kamble 
Acked-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_slpc.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index 0a9c0f2..b342fa2 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -109,8 +109,38 @@ struct slpc_shared_data {
u32 override_parameters_values[SLPC_MAX_OVERRIDE_PARAMETERS];
 } __packed;
 
+#define SLPC_MAX_NUM_OF_PIPES 4
+
+struct intel_display_pipe_info {
+   union {
+   u32 data;
+   struct {
+   u32 is_widi:1;
+   u32 refresh_rate:7;
+   u32 vsync_ft_usec:24;
+   };
+   };
+} __packed;
+
+struct intel_slpc_display_mode_event_params {
+   struct {
+   struct intel_display_pipe_info
+   per_pipe_info[SLPC_MAX_NUM_OF_PIPES];
+   union {
+   u32 global_data;
+   struct {
+   u32 active_pipes_bitmask:SLPC_MAX_NUM_OF_PIPES;
+   u32 fullscreen_pipes:SLPC_MAX_NUM_OF_PIPES;
+   u32 vbi_sync_on_pipes:SLPC_MAX_NUM_OF_PIPES;
+   u32 num_active_pipes:2;
+   };
+   };
+   };
+} __packed;
+
 struct intel_slpc {
struct drm_i915_gem_object *shared_data_obj;
+   struct intel_slpc_display_mode_event_params display_mode_params;
 };
 
 /* intel_slpc.c */
-- 
1.9.1

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

[Intel-gfx] [PATCH 07/21] drm/i915/slpc: If using SLPC, do not set frequency

[tom . orourke]

From: Tom O'Rourke 

When frequency requests are made by SLPC, host driver
should not attempt to make frequency requests due to
potential conflicts.

Host-based turbo operations are already avoided when
SLPC is used.  This change covers other frequency
requests such as from sysfs or debugfs interfaces.

A later patch in this series updates sysfs/debugfs
interfaces for setting max/min frequencies with SLPC.

v2: Use intel_slpc_active instead of HAS_SLPC (Paulo)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_pm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 35d7f19..f480551 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4581,6 +4581,9 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
 
 void intel_set_rps(struct drm_device *dev, u8 val)
 {
+   if (intel_slpc_active(dev))
+   return;
+
if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
valleyview_set_rps(dev, val);
else
-- 
1.9.1

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

[Intel-gfx] [PATCH 09/21] drm/i915/slpc: Setup rps frequency values during SLPC init

[tom . orourke]

From: Tom O'Rourke 

v2: Add mutex lock/unlock

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_drv.h  | 1 +
 drivers/gpu/drm/i915/intel_pm.c   | 2 +-
 drivers/gpu/drm/i915/intel_slpc.c | 5 +
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 47e538a..006a8c7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1612,6 +1612,7 @@ void intel_init_clock_gating_hooks(struct 
drm_i915_private *dev_priv);
 void intel_pm_setup(struct drm_device *dev);
 void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
 void intel_gpu_ips_teardown(void);
+void gen6_init_rps_frequencies(struct drm_device *dev);
 void intel_init_gt_powersave(struct drm_device *dev);
 void intel_cleanup_gt_powersave(struct drm_device *dev);
 void intel_enable_gt_powersave(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f480551..b4f753e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4738,7 +4738,7 @@ int intel_enable_rc6(const struct drm_device *dev)
return i915.enable_rc6;
 }
 
-static void gen6_init_rps_frequencies(struct drm_device *dev)
+void gen6_init_rps_frequencies(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t rp_state_cap;
diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 5e039d5..bacbfed 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -92,6 +92,11 @@ void intel_slpc_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
 
+   /* Initialize the rps frequecny values */
+   mutex_lock(_priv->rps.hw_lock);
+   gen6_init_rps_frequencies(dev);
+   mutex_unlock(_priv->rps.hw_lock);
+
/* Allocate shared data structure */
obj = dev_priv->guc.slpc.shared_data_obj;
if (!obj) {
-- 
1.9.1

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

[Intel-gfx] [PATCH 10/21] drm/i915/slpc: Update current requested frequency

[tom . orourke]

From: Tom O'Rourke 

When SLPC is controlling requested frequency, the rps.cur_freq
value is not used to make the frequency request.

Before using rps.cur_freq in sysfs or debugfs, read
requested frequency from register to get the value
most recently requested by SLPC firmware.

v2: replace HAS_SLPC with intel_slpc_active (Paulo)
v3: Avoid magic numbers (Nick)
Use a function for repeated code (Jon)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/i915_sysfs.c   | 3 +++
 4 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8b8d6f0..1295d8b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1168,6 +1168,9 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
 
flush_delayed_work(_priv->rps.delayed_resume_work);
 
+   if (intel_slpc_active(dev))
+   dev_priv->rps.cur_freq = gen9_read_requested_freq(dev_priv);
+
if (IS_GEN5(dev)) {
u16 rgvswctl = I915_READ16(MEMSWCTL);
u16 rgvstat = I915_READ16(MEMSTAT_ILK);
@@ -2399,6 +2402,9 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_file *file;
 
+   if (intel_slpc_active(dev))
+   dev_priv->rps.cur_freq = gen9_read_requested_freq(dev_priv);
+
seq_printf(m, "RPS enabled? %d\n", dev_priv->rps.enabled);
seq_printf(m, "GPU busy? %d\n", dev_priv->mm.busy);
seq_printf(m, "CPU waiting? %d\n", count_irq_waiters(dev_priv));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 393da67..55d31f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3728,4 +3728,9 @@ static inline void i915_trace_irq_get(struct 
intel_engine_cs *engine,
i915_gem_request_assign(>trace_irq_req, req);
 }
 
+static inline u8 gen9_read_requested_freq(struct drm_i915_private *dev_priv)
+{
+   return (u8) GEN9_GET_FREQUENCY(I915_READ(GEN6_RPNSWREQ));
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a2fd30..a7beb10 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6956,6 +6956,7 @@ enum skl_disp_power_wells {
 #define   GEN6_FREQUENCY(x)((x)<<25)
 #define   HSW_FREQUENCY(x) ((x)<<24)
 #define   GEN9_FREQUENCY(x)((x)<<23)
+#define   GEN9_GET_FREQUENCY(x)((x)>>23)
 #define   GEN6_OFFSET(x)   ((x)<<19)
 #define   GEN6_AGGRESSIVE_TURBO(0<<15)
 #define GEN6_RC_VIDEO_FREQ _MMIO(0xA00C)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 2d576b7..826e40c 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -318,6 +318,9 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
intel_runtime_pm_get(dev_priv);
 
mutex_lock(_priv->rps.hw_lock);
+   if (intel_slpc_active(dev))
+   dev_priv->rps.cur_freq = gen9_read_requested_freq(dev_priv);
+
ret = intel_gpu_freq(dev_priv, dev_priv->rps.cur_freq);
mutex_unlock(_priv->rps.hw_lock);
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 14/21] drm/i915/slpc: Notification of Display mode change

[tom . orourke]

From: Sagar Arun Kamble 

GuC SLPC needs to be sent data related to Active pipes, refresh rates,
widi pipes, fullscreen pipes related via host to GuC display mode
change event. Based on this, SLPC will track FPS on active pipes.
This patch defines the events and implements trigger of the events.

v2: Addressed review comments from Paulo and Ville. Changed the way
display mode information is collected in intel_atomic_commit. Coupled
display mode change event with SLPC enable/reset event. Updated inactive
crtc state in display mode data. Updated refresh rate and vsync_ft_usec
calculations to get more accurate value. (Paulo)
v2(torourke): Updates suggested by Paulo: replace HAS_SLPC with
intel_slpc_active. Return void instead of ignored error code.

v3: Addressed checkpatch issues. (Sagar)
Commit message update and bitmask op changes in display mode events.
(Nick)
Added check for mode parameters clock, htotal, vtotal. (Jon)

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_display.c |   2 +
 drivers/gpu/drm/i915/intel_slpc.c| 174 ++-
 drivers/gpu/drm/i915/intel_slpc.h|   3 +
 3 files changed, 178 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index eb7cb94..3bc61b7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13716,6 +13716,8 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
mutex_unlock(>struct_mutex);
 
+   intel_slpc_update_atomic_commit_info(dev, state);
+
drm_atomic_state_free(state);
 
/* As one of the primary mmio accessors, KMS has a high likelihood
diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 076d07b..7f26284 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -73,6 +73,24 @@ static void host2guc_slpc_shutdown(struct drm_device *dev)
host2guc_slpc(dev_priv, data, 4);
 }
 
+static void host2guc_slpc_display_mode_change(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 data[3 + SLPC_MAX_NUM_OF_PIPES];
+   int i;
+   struct intel_slpc_display_mode_event_params *display_mode_params;
+
+   display_mode_params = _priv->guc.slpc.display_mode_params;
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_DISPLAY_MODE_CHANGE,
+   SLPC_MAX_NUM_OF_PIPES + 1);
+   data[2] = display_mode_params->global_data;
+   for(i = 0; i < SLPC_MAX_NUM_OF_PIPES; ++i)
+   data[3+i] = display_mode_params->per_pipe_info[i].data;
+
+   host2guc_slpc(dev_priv, data, 3 + SLPC_MAX_NUM_OF_PIPES);
+}
+
 static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
 {
struct drm_device *dev = obj->base.dev;
@@ -181,8 +199,10 @@ void intel_slpc_disable(struct drm_device *dev)
 
 void intel_slpc_enable(struct drm_device *dev)
 {
-   if (intel_slpc_active(dev))
+   if (intel_slpc_active(dev)) {
host2guc_slpc_reset(dev);
+   intel_slpc_update_display_mode_info(dev);
+   }
 }
 
 void intel_slpc_reset(struct drm_device *dev)
@@ -192,3 +212,155 @@ void intel_slpc_reset(struct drm_device *dev)
host2guc_slpc_reset(dev);
}
 }
+
+void intel_slpc_update_display_mode_info(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc;
+   struct intel_display_pipe_info *per_pipe_info;
+   struct intel_slpc_display_mode_event_params *cur_params, old_params;
+   bool notify = false;
+
+   if (!intel_slpc_active(dev))
+   return;
+
+   /* Copy display mode parameters for comparison */
+   cur_params = _priv->guc.slpc.display_mode_params;
+   old_params.global_data  = cur_params->global_data;
+   cur_params->global_data = 0;
+
+   intel_runtime_pm_get(dev_priv);
+   drm_modeset_lock_all(dev);
+
+   for_each_intel_crtc(dev, intel_crtc) {
+   per_pipe_info = _params->per_pipe_info[intel_crtc->pipe];
+   old_params.per_pipe_info[intel_crtc->pipe].data =
+   per_pipe_info->data;
+   per_pipe_info->data = 0;
+
+   if (intel_crtc->active) {
+   struct drm_display_mode *mode = _crtc->base.mode;
+
+   if (mode->clock == 0 || mode->htotal == 0 ||
+   mode->vtotal == 0) {
+   DRM_DEBUG_DRIVER(
+   "Display Mode Info not sent to SLPC\n");
+   drm_modeset_unlock_all(dev);
+   

[Intel-gfx] [PATCH 06/21] drm/i915/slpc: Enable SLPC in guc if supported

[tom . orourke]

From: Tom O'Rourke 

If slpc enabled, then add enable SLPC flag to guc
control parameter during guc load.

v2: Use intel_slpc_enabled() (Paulo)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 174cc34..e9181b1 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -188,6 +188,9 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
params[GUC_CTL_FEATURE] |= GUC_CTL_DISABLE_SCHEDULER |
GUC_CTL_VCS2_ENABLED;
 
+   if (intel_slpc_enabled())
+   params[GUC_CTL_FEATURE] |= GUC_CTL_ENABLE_SLPC;
+
if (i915.guc_log_level >= 0) {
params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
params[GUC_CTL_DEBUG] =
-- 
1.9.1

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

[Intel-gfx] [PATCH 01/21] drm/i915/slpc: Expose guc functions for use with SLPC

[tom . orourke]

From: Tom O'Rourke 

Expose host2guc_action for use by SLPC in intel_slpc.c.

Expose functions to allocate and release objects used
by GuC to be used for SLPC shared memory object.

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 6 +++---
 drivers/gpu/drm/i915/intel_guc.h   | 4 
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 72d6665..aba1155 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -75,7 +75,7 @@ static inline bool host2guc_action_response(struct 
drm_i915_private *dev_priv,
return GUC2HOST_IS_RESPONSE(val);
 }
 
-static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
+int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 status;
@@ -581,7 +581,7 @@ int i915_guc_submit(struct i915_guc_client *client,
  *
  * Return: A drm_i915_gem_object if successful, otherwise NULL.
  */
-static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
+struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
u32 size)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -612,7 +612,7 @@ static struct drm_i915_gem_object 
*gem_allocate_guc_obj(struct drm_device *dev,
  * gem_release_guc_obj() - Release gem object allocated for GuC usage
  * @obj:   gem obj to be released
  */
-static void gem_release_guc_obj(struct drm_i915_gem_object *obj)
+void gem_release_guc_obj(struct drm_i915_gem_object *obj)
 {
if (!obj)
return;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9d79c4c..4d24856 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -146,10 +146,14 @@ extern int intel_guc_suspend(struct drm_device *dev);
 extern int intel_guc_resume(struct drm_device *dev);
 
 /* i915_guc_submission.c */
+int host2guc_action(struct intel_guc *guc, u32 *data, u32 len);
 int i915_guc_submission_init(struct drm_device *dev);
 int i915_guc_submission_enable(struct drm_device *dev);
 int i915_guc_submit(struct i915_guc_client *client,
struct drm_i915_gem_request *rq);
+struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
+   u32 size);
+void gem_release_guc_obj(struct drm_i915_gem_object *obj);
 void i915_guc_submission_disable(struct drm_device *dev);
 void i915_guc_submission_fini(struct drm_device *dev);
 int i915_guc_wq_check_space(struct i915_guc_client *client);
-- 
1.9.1

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

[Intel-gfx] [PATCH 02/21] drm/i915/slpc: Add has_slpc capability flag

[tom . orourke]

From: Tom O'Rourke 

Add has_slpc capablity flag to indicate GuC firmware
supports single loop power control (SLPC).  SLPC is
a replacement for some host-based power management
features.

v2: fix whitespace (Sagar)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 32f0597..393da67 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -740,6 +740,7 @@ struct intel_csr {
func(is_kabylake) sep \
func(is_preliminary) sep \
func(has_fbc) sep \
+   func(has_slpc) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2692,6 +2693,7 @@ struct drm_i915_cmd_table {
 
 #define HAS_GUC_UCODE(dev) (IS_GEN9(dev) && !IS_KABYLAKE(dev))
 #define HAS_GUC_SCHED(dev) (IS_GEN9(dev) && !IS_KABYLAKE(dev))
+#define HAS_SLPC(dev)  (INTEL_INFO(dev)->has_slpc)
 
 #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
-- 
1.9.1

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

[Intel-gfx] [PATCH 05/21] drm/i915/slpc: Use intel_slpc_* functions if supported

[tom . orourke]

From: Tom O'Rourke 

On platforms with SLPC support: call intel_slpc_*()
functions from corresponding intel_*_gt_powersave()
functions; and do not use rps functions.

v2: return void instead of ignored error code (Paulo)
enable/disable RC6 in SLPC flows (Sagar)
replace HAS_SLPC() use with intel_slpc_enabled()
or intel_slpc_active() (Paulo)
v3: Fix for renaming gen9_disable_rps to gen9_disable_rc6 in
"drm/i915/bxt: Explicitly clear the Turbo control register"

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/Makefile |  5 ++--
 drivers/gpu/drm/i915/intel_drv.h  |  4 +++
 drivers/gpu/drm/i915/intel_guc.h  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   | 37 +++---
 drivers/gpu/drm/i915/intel_slpc.c | 56 +++
 drivers/gpu/drm/i915/intel_slpc.h | 35 
 6 files changed, 126 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_slpc.c
 create mode 100644 drivers/gpu/drm/i915/intel_slpc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 723c502..0122673 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -43,8 +43,9 @@ i915-y += i915_cmd_parser.o \
  intel_uncore.o
 
 # general-purpose microcontroller (GuC) support
-i915-y += intel_guc_loader.o \
- i915_guc_submission.o
+i915-y += i915_guc_submission.o \
+ intel_guc_loader.o \
+ intel_slpc.o
 
 # autogenerated null render state
 i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ce78afe..9d02835 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1591,6 +1591,10 @@ void chv_phy_powergate_lanes(struct intel_encoder 
*encoder,
 bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum dpio_phy phy,
  enum dpio_channel ch, bool override);
 
+static inline int intel_slpc_active(struct drm_device *dev)
+{
+   return 0;
+}
 
 /* intel_pm.c */
 void intel_init_clock_gating(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index cecfe4e..2d4571e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -26,6 +26,7 @@
 
 #include "intel_guc_fwif.h"
 #include "i915_guc_reg.h"
+#include "intel_slpc.h"
 
 struct drm_i915_gem_request;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 695a464..35d7f19 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6227,7 +6227,9 @@ void intel_init_gt_powersave(struct drm_device *dev)
intel_runtime_pm_get(dev_priv);
}
 
-   if (IS_CHERRYVIEW(dev))
+   if (intel_slpc_enabled())
+   intel_slpc_init(dev);
+   else if (IS_CHERRYVIEW(dev))
cherryview_init_gt_powersave(dev);
else if (IS_VALLEYVIEW(dev))
valleyview_init_gt_powersave(dev);
@@ -6237,7 +6239,9 @@ void intel_cleanup_gt_powersave(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   if (IS_CHERRYVIEW(dev))
+   if (intel_slpc_active(dev))
+   intel_slpc_cleanup(dev);
+   else if (IS_CHERRYVIEW(dev))
return;
else if (IS_VALLEYVIEW(dev))
valleyview_cleanup_gt_powersave(dev);
@@ -6270,17 +6274,24 @@ void intel_suspend_gt_powersave(struct drm_device *dev)
if (INTEL_INFO(dev)->gen < 6)
return;
 
-   gen6_suspend_rps(dev);
+   if (intel_slpc_active(dev)) {
+   intel_slpc_suspend(dev);
+   } else {
+   gen6_suspend_rps(dev);
 
-   /* Force GPU to min freq during suspend */
-   gen6_rps_idle(dev_priv);
+   /* Force GPU to min freq during suspend */
+   gen6_rps_idle(dev_priv);
+   }
 }
 
 void intel_disable_gt_powersave(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   if (IS_IRONLAKE_M(dev)) {
+   if (intel_slpc_active(dev)) {
+   intel_slpc_disable(dev);
+   gen9_disable_rc6(dev);
+   } else if (IS_IRONLAKE_M(dev)) {
ironlake_disable_drps(dev);
} else if (INTEL_INFO(dev)->gen >= 6) {
intel_suspend_gt_powersave(dev);
@@ -6288,7 +6299,6 @@ void intel_disable_gt_powersave(struct drm_device *dev)
mutex_lock(_priv->rps.hw_lock);
if (INTEL_INFO(dev)->gen >= 9) {
gen9_disable_rc6(dev);
-   gen9_disable_rps(dev);
} else if (IS_CHERRYVIEW(dev))
cherryview_disable_rps(dev);
else if (IS_VALLEYVIEW(dev))
@@ -6352,7 +6362,10 @@ void intel_enable_gt_powersave(struct drm_device *dev)
if 

Re: [Intel-gfx] RFC: libdrm: Support Iris Graphics 540 & 550 (Skylake GT3e)

[Kenneth Graunke]

On Wednesday, April 27, 2016 9:37:07 AM PDT Thorsten Leemhuis wrote:
> Thorsten Leemhuis wrote on 26.04.2016 13:41:
> > Lo! Below patch adds the PCI-ID for the Intel(R) Iris Graphics 550 
(Skylake
> > GT3e mobile) to libdrm. It afaics is the last piece that is missing to
> > make those GPUs work properly, as Linux 4.6-rc(¹) and Mesa 11.2 already
> > support it – but without this patch I get a "error initializing buffer
> > manager" message from i965 when it tries to load. I tested it on a
> > laptop with a Core i5-6267U and it seems to work -- but I only did a
> > few quick tests so far.
> 
> Forget that patch -- a way better one was submitted weeks ago my Michal
> already:
> https://lists.freedesktop.org/archives/intel-gfx/2016-February/087819.html
> 
> Did that patch simply fall through the cracks or is there a reason why
> it wasn't applied to libdrm master? It is pretty obvious it would fix
> the problem I saw and tried to address with that rough patch I send
> yesterday.
> 
> CU, knurd
> 
> P.S.: Added intel-gfx and michal.winiarski to CC

It looks like it fell through the cracks.  Roland just mentioned this on
IRC...I've reviewed and pushed the patch to master.  I'm also making a
release.


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

[Intel-gfx] [PATCH 17/21] drm/i915/slpc: Add parameter unset/set/get functions

[tom . orourke]

From: Tom O'Rourke 

Add slpc_param_id enum values.
Add events for setting/unsetting parameters.

v2: use host2guc_slpc
update slcp_param_id enum values for SLPC 2015.2.4
return void instead of ignored error code (Paulo)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_slpc.c | 104 ++
 drivers/gpu/drm/i915/intel_slpc.h |  26 +-
 2 files changed, 129 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 9e0bc96..7b14a45 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -91,6 +91,33 @@ static void host2guc_slpc_display_mode_change(struct 
drm_device *dev)
host2guc_slpc(dev_priv, data, 3 + SLPC_MAX_NUM_OF_PIPES);
 }
 
+static void host2guc_slpc_set_param(struct drm_device *dev,
+   enum slpc_param_id id, u32 value)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 data[4];
+
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_PARAMETER_SET, 2);
+   data[2] = (u32) id;
+   data[3] = value;
+
+   host2guc_slpc(dev_priv, data, 4);
+}
+
+static void host2guc_slpc_unset_param(struct drm_device *dev,
+ enum slpc_param_id id)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 data[3];
+
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_PARAMETER_UNSET, 1);
+   data[2] = (u32) id;
+
+   host2guc_slpc(dev_priv, data, 3);
+}
+
 static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
 {
struct drm_device *dev = obj->base.dev;
@@ -387,3 +414,80 @@ void intel_slpc_update_display_rr_info(struct drm_device 
*dev, u32 refresh_rate)
 
host2guc_slpc_display_mode_change(dev);
 }
+
+void intel_slpc_unset_param(struct drm_device *dev, enum slpc_param_id id)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   struct slpc_shared_data *data = NULL;
+
+   obj = dev_priv->guc.slpc.shared_data_obj;
+   if (obj) {
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   data = kmap_atomic(page);
+   }
+
+   if (data) {
+   data->override_parameters_set_bits[id >> 5]
+   &= (~(1 << (id % 32)));
+   data->override_parameters_values[id] = 0;
+   kunmap_atomic(data);
+
+   host2guc_slpc_unset_param(dev, id);
+   }
+}
+
+void intel_slpc_set_param(struct drm_device *dev, enum slpc_param_id id,
+ u32 value)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   struct slpc_shared_data *data = NULL;
+
+   obj = dev_priv->guc.slpc.shared_data_obj;
+   if (obj) {
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   data = kmap_atomic(page);
+   }
+
+   if (data) {
+   data->override_parameters_set_bits[id >> 5]
+   |= (1 << (id % 32));
+   data->override_parameters_values[id] = value;
+   kunmap_atomic(data);
+
+   host2guc_slpc_set_param(dev, id, value);
+   }
+}
+
+void intel_slpc_get_param(struct drm_device *dev, enum slpc_param_id id,
+ int *overriding, u32 *value)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   struct slpc_shared_data *data = NULL;
+   u32 bits;
+
+   obj = dev_priv->guc.slpc.shared_data_obj;
+   if (obj) {
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   data = kmap_atomic(page);
+   }
+
+   if (data) {
+   if (overriding) {
+   bits = data->override_parameters_set_bits[id >> 5];
+   *overriding = (0 != (bits & (1 << (id % 32;
+   }
+   if (value)
+   *value = data->override_parameters_values[id];
+
+   kunmap_atomic(data);
+   }
+}
diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index 508642b..bf09f1b 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -69,6 +69,26 @@ enum slpc_event_id {
 #define SLPC_EVENT(id, argc) ((u32) (id) << 8 | (argc))
 #define SLPC_EVENT_STATUS_MASK 0xFF
 
+enum slpc_param_id {
+   SLPC_PARAM_TASK_ENABLE_GTPERF = 0,
+   SLPC_PARAM_TASK_DISABLE_GTPERF = 1,
+   SLPC_PARAM_TASK_ENABLE_BALANCER = 2,
+   

[Intel-gfx] [PATCH 03/21] drm/i915/slpc: Add slpc_version_check

[tom . orourke]

From: Tom O'Rourke 

The SLPC interface has changed and could continue to
change.  Only GuC versions known to be compatible are
supported here.

On Skylake, GuC firmware v6 is supported.  Other
platforms and versions can be added here later.

This patch also adds has_slpc to skylake info.

v2: Move slpc_version_check to intel_guc_ucode_init
v3: fix whitespace (Sagar)
---
 drivers/gpu/drm/i915/i915_drv.c |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d37c0a6..cc22fa0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -334,6 +334,7 @@ static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
+   .has_slpc = 1,
 };
 
 static const struct intel_device_info intel_skylake_gt3_info = {
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 876e5da..87702cd 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -116,6 +116,18 @@ static void direct_interrupts_to_guc(struct 
drm_i915_private *dev_priv)
I915_WRITE(GUC_WD_VECS_IER, ~irqs);
 }
 
+static void slpc_version_check(struct drm_device *dev,
+  struct intel_guc_fw *guc_fw)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_device_info *info;
+
+   if (IS_SKYLAKE(dev) && (guc_fw->guc_fw_major_found != 6)) {
+   info = (struct intel_device_info *) _priv->info;
+   info->has_slpc = 0;
+   }
+}
+
 static u32 get_gttype(struct drm_i915_private *dev_priv)
 {
/* XXX: GT type based on PCI device ID? field seems unused by fw */
@@ -666,6 +678,8 @@ void intel_guc_ucode_init(struct drm_device *dev)
DRM_DEBUG_DRIVER("GuC firmware pending, path %s\n", fw_path);
guc_fw_fetch(dev, guc_fw);
/* status must now be FAIL or SUCCESS */
+
+   slpc_version_check(dev, guc_fw);
 }
 
 /**
-- 
1.9.1

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

[Intel-gfx] [PATCH 18/21] drm/i915/slpc: Add slpc support for max/min freq

[tom . orourke]

From: Tom O'Rourke 

Update sysfs and debugfs functions to set SLPC
parameters when setting max/min frequency.

v2: Update for SLPC 2015.2.4 (params for both slice and unslice)
Replace HAS_SLPC with intel_slpc_active() (Paulo)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 16 
 drivers/gpu/drm/i915/i915_sysfs.c   | 18 ++
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1295d8b..f77d32c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5014,6 +5014,14 @@ i915_max_freq_set(void *data, u64 val)
}
 
dev_priv->rps.max_freq_softlimit = val;
+   if (intel_slpc_active(dev)) {
+   intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   }
 
intel_set_rps(dev, val);
 
@@ -5081,6 +5089,14 @@ i915_min_freq_set(void *data, u64 val)
}
 
dev_priv->rps.min_freq_softlimit = val;
+   if (intel_slpc_active(dev)) {
+   intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   }
 
intel_set_rps(dev, val);
 
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 826e40c..091a936 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -393,6 +393,15 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
 
dev_priv->rps.max_freq_softlimit = val;
 
+   if (intel_slpc_active(dev)) {
+   intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   }
+
val = clamp_t(int, dev_priv->rps.cur_freq,
  dev_priv->rps.min_freq_softlimit,
  dev_priv->rps.max_freq_softlimit);
@@ -457,6 +466,15 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
 
dev_priv->rps.min_freq_softlimit = val;
 
+   if (intel_slpc_active(dev)) {
+   intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   }
+
val = clamp_t(int, dev_priv->rps.cur_freq,
  dev_priv->rps.min_freq_softlimit,
  dev_priv->rps.max_freq_softlimit);
-- 
1.9.1

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

[Intel-gfx] [PATCH 16/21] drm/i915/slpc: Add slpc_status enum values

[tom . orourke]

From: Tom O'Rourke 

v2: fix whitespace (Sagar)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/intel_slpc.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index 0b251a1..508642b 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -28,6 +28,33 @@
 #define SLPC_MINOR_VER 4
 #define SLPC_VERSION ((2015 << 16) | (SLPC_MAJOR_VER << 8) | (SLPC_MINOR_VER))
 
+enum slpc_status {
+   SLPC_STATUS_OK = 0,
+   SLPC_STATUS_ERROR = 1,
+   SLPC_STATUS_ILLEGAL_COMMAND = 2,
+   SLPC_STATUS_INVALID_ARGS = 3,
+   SLPC_STATUS_INVALID_PARAMS = 4,
+   SLPC_STATUS_INVALID_DATA = 5,
+   SLPC_STATUS_OUT_OF_RANGE = 6,
+   SLPC_STATUS_NOT_SUPPORTED = 7,
+   SLPC_STATUS_NOT_IMPLEMENTED = 8,
+   SLPC_STATUS_NO_DATA = 9,
+   SLPC_STATUS_EVENT_NOT_REGISTERED = 10,
+   SLPC_STATUS_REGISTER_LOCKED = 11,
+   SLPC_STATUS_TEMPORARILY_UNAVAILABLE = 12,
+   SLPC_STATUS_VALUE_ALREADY_SET = 13,
+   SLPC_STATUS_VALUE_ALREADY_UNSET = 14,
+   SLPC_STATUS_VALUE_NOT_CHANGED = 15,
+   SLPC_STATUS_MISMATCHING_VERSION = 16,
+   SLPC_STATUS_MEMIO_ERROR = 17,
+   SLPC_STATUS_EVENT_QUEUED_REQ_DPC = 18,
+   SLPC_STATUS_EVENT_QUEUED_NOREQ_DPC = 19,
+   SLPC_STATUS_NO_EVENT_QUEUED = 20,
+   SLPC_STATUS_OUT_OF_SPACE = 21,
+   SLPC_STATUS_TIMEOUT = 22,
+   SLPC_STATUS_NO_LOCK = 23,
+};
+
 enum slpc_event_id {
SLPC_EVENT_RESET = 0,
SLPC_EVENT_SHUTDOWN = 1,
-- 
1.9.1

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

[Intel-gfx] [PATCH 19/21] drm/i915/slpc: Add enable/disable debugfs for slpc

[tom . orourke]

From: Tom O'Rourke 

Adds debugfs hooks for each slpc task.

The enable/disable debugfs files are
i915_slpc_gtperf, i915_slpc_balancer, and i915_slpc_dcc.

Each of these can take the values:
"default", "enabled", or "disabled"

v2: update for SLPC v2015.2.4
dfps and turbo merged and renamed "gtperf"
ibc split out and renamed "balancer"
v3: Avoid magic numbers (Jon Bloomfield)

Signed-off-by: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 250 
 drivers/gpu/drm/i915/intel_slpc.h   |   5 +
 2 files changed, 255 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f77d32c..8b39a13 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1157,6 +1157,253 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
i915_next_seqno_get, i915_next_seqno_set,
"0x%llx\n");
 
+static int slpc_enable_disable_get(struct drm_device *dev, u64 *val,
+  enum slpc_param_id enable_id,
+  enum slpc_param_id disable_id)
+{
+   int override_enable, override_disable;
+   u32 value_enable, value_disable;
+   int ret = 0;
+
+   if (!intel_slpc_active(dev)) {
+   ret = -ENODEV;
+   } else if (val) {
+   intel_slpc_get_param(dev, enable_id, _enable,
+_enable);
+   intel_slpc_get_param(dev, disable_id, _disable,
+_disable);
+
+   /* set the output value:
+   * 0: default
+   * 1: enabled
+   * 2: disabled
+   * 3: unknown (should not happen)
+   */
+   if (override_disable && (1 == value_disable))
+   *val = SLPC_PARAM_TASK_DISABLED;
+   else if (override_enable && (1 == value_enable))
+   *val = SLPC_PARAM_TASK_ENABLED;
+   else if (!override_enable && !override_disable)
+   *val = SLPC_PARAM_TASK_DEFAULT;
+   else
+   *val = SLPC_PARAM_TASK_UNKNOWN;
+
+   } else {
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+
+static int slpc_enable_disable_set(struct drm_device *dev, u64 val,
+  enum slpc_param_id enable_id,
+  enum slpc_param_id disable_id)
+{
+   int ret = 0;
+
+   if (!intel_slpc_active(dev)) {
+   ret = -ENODEV;
+   } else if (SLPC_PARAM_TASK_DEFAULT == val) {
+   /* set default */
+   intel_slpc_unset_param(dev, enable_id);
+   intel_slpc_unset_param(dev, disable_id);
+   } else if (SLPC_PARAM_TASK_ENABLED == val) {
+   /* set enable */
+   intel_slpc_set_param(dev, enable_id, 1);
+   intel_slpc_unset_param(dev, disable_id);
+   } else if (SLPC_PARAM_TASK_DISABLED == val) {
+   /* set disable */
+   intel_slpc_set_param(dev, disable_id, 1);
+   intel_slpc_unset_param(dev, enable_id);
+   } else {
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+
+static void slpc_param_show(struct seq_file *m, enum slpc_param_id enable_id,
+   enum slpc_param_id disable_id)
+{
+   struct drm_device *dev = m->private;
+   const char *status;
+   u64 val;
+   int ret;
+
+   ret = slpc_enable_disable_get(dev, , enable_id, disable_id);
+
+   if (ret) {
+   seq_printf(m, "error %d\n", ret);
+   } else {
+   switch (val) {
+   case SLPC_PARAM_TASK_DEFAULT:
+   status = "default\n";
+   break;
+
+   case SLPC_PARAM_TASK_ENABLED:
+   status = "enabled\n";
+   break;
+
+   case SLPC_PARAM_TASK_DISABLED:
+   status = "disabled\n";
+   break;
+
+   default:
+   status = "unknown\n";
+   break;
+   }
+
+   seq_puts(m, status);
+   }
+}
+
+static int slpc_param_write(struct seq_file *m, const char __user *ubuf,
+   size_t len, enum slpc_param_id enable_id,
+   enum slpc_param_id disable_id)
+{
+   struct drm_device *dev = m->private;
+   u64 val;
+   int ret = 0;
+   char buf[10];
+
+   if (len >= sizeof(buf))
+   ret = -EINVAL;
+   else if (copy_from_user(buf, ubuf, len))
+   ret = -EFAULT;
+   else
+   buf[len] = '\0';
+
+   if (!ret) {
+   if (!strncmp(buf, "default", 7))
+   val = SLPC_PARAM_TASK_DEFAULT;
+   else if 

[Intel-gfx] [PATCH v4 00/21] Add support for GuC-based SLPC

[tom . orourke]

From: Tom O'Rourke 

SLPC (Single Loop Power Controller) is a replacement for
some host-based power management features.  The SLPC
implemenation runs in firmware on GuC.

This series has been tested with SKL guc firmware
version 6.1.

The graphics power management features in SLPC in those
versions are called GTPERF, BALANCER, and DCC.

GTPERF is a combination of DFPS (Dynamic FPS) and Turbo.
DFPS adjusts requested graphics frequency to maintain
target framerate.  Turbo adjusts requested graphics
frequency to maintain target GT busyness; this includes
an adaptive boost turbo method.

BALANCER adjusts balance between power budgets for IA
and GT in power limited scenarios.  BALANCER is only
active when all display pipes are in "game" mode.

DCC (Duty Cycle Control) adjusts requested graphics
frequency and stalls guc-scheduler to maintain actual
graphics frequency in efficient range.

The v3 series can be found in the archive at
"[Intel-gfx] [PATCH v3 00/25] Add support for GuC-based SLPC"
https://lists.freedesktop.org/archives/intel-gfx/2016-April/091771.html

This v4 series incorporates feedback from internal code 
reviews for Android and Yocto projects.  This series also 
drops the Broxton patches; the Broxton firmware has not 
been published yet.  Broxton support can be added later 
when the Broxton firmware is available. 

Also, the "DO NOT MERGE" patches to enable SLPC and guc 
submission by default have been dropped.  These can be 
added later after SLPC has been shown to outperform 
host-based power management; this may require a newer 
version of the GuC firmware.

With SLPC disabled by default, this series should be 
safe to merge now. 

VIZ-6773, VIZ-6889

Sagar Arun Kamble (4):
  drm/i915/slpc: Add Display mode event related data structures
  drm/i915/slpc: Notification of Display mode change
  drm/i915/slpc: Notification of Refresh Rate change
  drm/i915/slpc: Fail intel_runtime_suspend if SLPC or RPS not active

Tom O'Rourke (17):
  drm/i915/slpc: Expose guc functions for use with SLPC
  drm/i915/slpc: Add has_slpc capability flag
  drm/i915/slpc: Add slpc_version_check
  drm/i915/slpc: Add enable_slpc module parameter
  drm/i915/slpc: Use intel_slpc_* functions if supported
  drm/i915/slpc: Enable SLPC in guc if supported
  drm/i915/slpc: If using SLPC, do not set frequency
  drm/i915/slpc: Allocate/Release/Initialize SLPC shared data
  drm/i915/slpc: Setup rps frequency values during SLPC init
  drm/i915/slpc: Update current requested frequency
  drm/i915/slpc: Send reset event
  drm/i915/slpc: Send shutdown event
  drm/i915/slpc: Add slpc_status enum values
  drm/i915/slpc: Add parameter unset/set/get functions
  drm/i915/slpc: Add slpc support for max/min freq
  drm/i915/slpc: Add enable/disable debugfs for slpc
  drm/i915/slpc: Add i915_slpc_info to debugfs

 drivers/gpu/drm/i915/Makefile  |   5 +-
 drivers/gpu/drm/i915/i915_debugfs.c| 456 +
 drivers/gpu/drm/i915/i915_drv.c|   4 +-
 drivers/gpu/drm/i915/i915_drv.h|   7 +
 drivers/gpu/drm/i915/i915_guc_submission.c |   6 +-
 drivers/gpu/drm/i915/i915_params.c |   6 +
 drivers/gpu/drm/i915/i915_params.h |   1 +
 drivers/gpu/drm/i915/i915_reg.h|   1 +
 drivers/gpu/drm/i915/i915_sysfs.c  |  21 ++
 drivers/gpu/drm/i915/intel_display.c   |   2 +
 drivers/gpu/drm/i915/intel_dp.c|   2 +
 drivers/gpu/drm/i915/intel_drv.h   |  11 +
 drivers/gpu/drm/i915/intel_guc.h   |  13 +
 drivers/gpu/drm/i915/intel_guc_loader.c|  36 ++
 drivers/gpu/drm/i915/intel_pm.c|  42 ++-
 drivers/gpu/drm/i915/intel_slpc.c  | 516 +
 drivers/gpu/drm/i915/intel_slpc.h  | 217 
 17 files changed, 1329 insertions(+), 17 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_slpc.c
 create mode 100644 drivers/gpu/drm/i915/intel_slpc.h

-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 01/19] drm/core: Add drm_accurate_vblank_count, v5.

[Mario Kleiner]

Anyway, although i would have liked the stricter check and warning docs, 
the v4 patch is ok with me:


Reviewed-by: Mario Kleiner 

-mario

On 04/25/2016 08:32 AM, Maarten Lankhorst wrote:

This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.

intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vblank handler has
run to completion. This function uses the timestamps to determine
when the last vblank has happened, and interpolates from there.

Changes since v1:
- Take vblank_time_lock and don't use drm_vblank_count_and_time.
Changes since v2:
- Don't return time of last vblank.
Changes since v3:
- Change pipe to unsigned int. (Ville)
- Remove unused documentation for tv_ret. (kbuild)
Changes since v4:
- Add warning to docs when the function is useful.
- Add a WARN_ON when get_vblank_timestamp is unavailable.
- Use drm_vblank_count.

Cc: Mario Kleiner 
Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä  #v4
Acked-by: David Airlie  #irc, v4
---

Unfortunately WARN_ON(!dev->disable_vblank_immediate) doesn't work on gen2,
which is the reason this function is created. So I used
WARN_ON(!get_vblank_timestamp) instead.

  drivers/gpu/drm/drm_irq.c | 31 +++
  include/drm/drmP.h|  1 +
  2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3c1a6f18e71c..d3124b67f4a5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -303,6 +303,37 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
store_vblank(dev, pipe, diff, _vblank, cur_vblank);
  }

+/**
+ * drm_accurate_vblank_count - retrieve the master vblank counter
+ * @crtc: which counter to retrieve
+ *
+ * This function is similar to @drm_crtc_vblank_count but this
+ * function interpolates to handle a race with vblank irq's.
+ *
+ * This is mostly useful for hardware that can obtain the scanout
+ * position, but doesn't have a frame counter.
+ */
+u32 drm_accurate_vblank_count(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   unsigned int pipe = drm_crtc_index(crtc);
+   u32 vblank;
+   unsigned long flags;
+
+   WARN(!dev->driver->get_vblank_timestamp,
+"This function requires support for accurate vblank timestamps.");
+
+   spin_lock_irqsave(>vblank_time_lock, flags);
+
+   drm_update_vblank_count(dev, pipe, 0);
+   vblank = drm_vblank_count(dev, pipe);
+
+   spin_unlock_irqrestore(>vblank_time_lock, flags);
+
+   return vblank;
+}
+EXPORT_SYMBOL(drm_accurate_vblank_count);
+
  /*
   * Disable vblank irq's on crtc, make sure that last vblank count
   * of hardware and corresponding consistent software vblank counter
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 005202ea5900..90527c41cd5a 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -995,6 +995,7 @@ extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
  extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
  extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
  extern void drm_vblank_cleanup(struct drm_device *dev);
+extern u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
  extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int 
pipe);

  extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,


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

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Imre Deak]

On Wed, 2016-04-27 at 22:33 +0200, Lukas Wunner wrote:
> Hi,
> 
> On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
> >  I'd like to propose that we push the i915
> > suspend_late/resume_early code
> >  into suspend_noirq/resume_noirq in order to reduce the total
> > suspend time
> >  by ~15ms. According to the comments, when i915_pm_suspend_late was
> > first
> >  added to the kernel back in April 2014, it was done so to ensure
> > that it
> >  was called after the snd_hda_intel driver had finished its
> > suspend.
> 
> Ordering issues like this one should be solved with
> device_pm_wait_for_dev(),
> not by shuffling code around among the callbacks.

We considered using device_pm_wait_for_dev() but decided not to, since
it may dead lock in case of suspend/resume:
https://lists.freedesktop.org/archives/intel-gfx/2014-December/057113.html

> In any case it would be good if you would name the sha1 of the commit
> that added i915_pm_suspend_late to spare readers the git blame / git
> log.
> 
> Thanks,
> 
> Lukas
> 
> > 
> > The comments in i915_drv.c are here:
> > 
> > /*
> >  * We have a suspedn ordering issue with the snd-hda driver
> > also
> >  * requiring our device to be power up. Due to the lack of a
> >  * parent/child relationship we currently solve this with an
> > late
> >  * suspend hook.
> >  *
> >  * FIXME: This should be solved with a special hdmi sink device
> > or
> >  * similar so that power domains can be employed.
> >  */
> > 
> > I believe we could achieve the same ordering by simply pushing it
> > to
> > suspend/resume_noirq. Thus we can effectively eliminate the
> > suspend_late
> > and resume_early phases altogether in most simple systems. Does
> > anyone see
> > a problem with this?
> > 
> > analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT
> > PATCH):
> > https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivy
> > bridge-dev-late/
> > https://01org.github.io/suspendresume/i915/suspend-160422-155735-iv
> > ybridge-dev-late/
> > https://01org.github.io/suspendresume/i915/hibernate-160422-163915-
> > ivybridge-dev-late/
> > 
> > analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> > https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivy
> > bridge-dev-noirq/
> > https://01org.github.io/suspendresume/i915/suspend-160422-162700-iv
> > ybridge-dev-noirq/
> > https://01org.github.io/suspendresume/i915/hibernate-160422-162952-
> > ivybridge-dev-noirq/
> > 
> > Signed-off-by: Todd Brandt 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 30798cb..759d93c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops =
> > {
> >      * PMSG_RESUME]
> >      */
> >     .suspend = i915_pm_suspend,
> > -   .suspend_late = i915_pm_suspend_late,
> > -   .resume_early = i915_pm_resume_early,
> > +   .suspend_noirq = i915_pm_suspend_late,
> > +   .resume_noirq = i915_pm_resume_early,
> >     .resume = i915_pm_resume,
> >  
> >     /*
> > @@ -1648,12 +1648,12 @@ static const struct dev_pm_ops i915_pm_ops
> > = {
> >      *hibernation image
> > [PMSG_RESTORE]
> >      */
> >     .freeze = i915_pm_suspend,
> > -   .freeze_late = i915_pm_suspend_late,
> > -   .thaw_early = i915_pm_resume_early,
> > +   .freeze_noirq = i915_pm_suspend_late,
> > +   .thaw_noirq = i915_pm_resume_early,
> >     .thaw = i915_pm_resume,
> >     .poweroff = i915_pm_suspend,
> > -   .poweroff_late = i915_pm_poweroff_late,
> > -   .restore_early = i915_pm_resume_early,
> > +   .poweroff_noirq = i915_pm_poweroff_late,
> > +   .restore_noirq = i915_pm_resume_early,
> >     .restore = i915_pm_resume,
> >  
> >     /* S0ix (via runtime suspend) event handlers */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Todd Brandt]

On Wed, 2016-04-27 at 23:49 +0300, Ville Syrjälä wrote:
> On Wed, Apr 27, 2016 at 01:17:15PM -0700, Todd Brandt wrote:
> > On Wed, 2016-04-27 at 22:31 +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
> > > >  I'd like to propose that we push the i915 suspend_late/resume_early 
> > > > code
> > > >  into suspend_noirq/resume_noirq in order to reduce the total suspend 
> > > > time
> > > >  by ~15ms. According to the comments, when i915_pm_suspend_late was 
> > > > first 
> > > >  added to the kernel back in April 2014, it was done so to ensure that 
> > > > it
> > > >  was called after the snd_hda_intel driver had finished its suspend.
> > > > 
> > > > The comments in i915_drv.c are here:
> > > > 
> > > > /*
> > > >  * We have a suspedn ordering issue with the snd-hda driver also
> > > >  * requiring our device to be power up. Due to the lack of a
> > > >  * parent/child relationship we currently solve this with an late
> > > >  * suspend hook.
> > > >  *
> > > >  * FIXME: This should be solved with a special hdmi sink device or
> > > >  * similar so that power domains can be employed.
> > > >  */
> > > > 
> > > > I believe we could achieve the same ordering by simply pushing it to
> > > > suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> > > > and resume_early phases altogether in most simple systems. Does anyone 
> > > > see
> > > > a problem with this?
> > > > 
> > > > analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> > > > https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> > > > https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> > > > https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> > > > 
> > > > analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> > > > https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> > > > https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> > > > https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/
> > > 
> > > Hmm. Looking at those makes me confused. Why isn't the pci bus
> > > .resume_noirq hook (pci_pm_resume_noirq()) waking up our pci device?
> > > Instead our wakeup gets delayed until .resume_early for some reason.
> > 
> > Which timeline are you referring to? The "late" ones are the unaltered
> > versions.
> 
> Referring to the current code, ie. the "late" timeline.
> 

Well it does wakeup with noirq in the suspend mode (S3) version:
https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/

It's in freeze (S2) that it gets delayed to resume_early, which I
assumed was normal (I'll try it on other systems to compare):
https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/



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

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Todd Brandt]

On Wed, 2016-04-27 at 13:49 -0700, Todd Brandt wrote:
> On Wed, 2016-04-27 at 22:33 +0200, Lukas Wunner wrote:
> > Hi,
> > 
> > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
> > >  I'd like to propose that we push the i915 suspend_late/resume_early code
> > >  into suspend_noirq/resume_noirq in order to reduce the total suspend time
> > >  by ~15ms. According to the comments, when i915_pm_suspend_late was first
> > >  added to the kernel back in April 2014, it was done so to ensure that it
> > >  was called after the snd_hda_intel driver had finished its suspend.
> > 
> > Ordering issues like this one should be solved with 
> > device_pm_wait_for_dev(),
> > not by shuffling code around among the callbacks.
> > 
> > In any case it would be good if you would name the sha1 of the commit
> > that added i915_pm_suspend_late to spare readers the git blame / git log.
> > 
> 
> Here's the actual commit that introduced it:
> 
> git checkout 76c4b250080fff6e4befaa3619942422fd0ea380
> git diff HEAD^ drivers/gpu/drm/i915/i915_drv.c
> 
> That shows the initial addition of the _late code.
> 

Oh, and here's the actual commit log text:

commit 76c4b250080fff6e4befaa3619942422fd0ea380
Author: Imre Deak 
Date:   Tue Apr 1 19:55:22 2014 +0300

drm/i915: move power domain init earlier during system resume

During resume the intel hda audio driver depends on the i915 driver
reinitializing the audio power domain. Since the order of calling
the
i915 resume handler wrt. that of the audio driver is not guaranteed,
move the power domain reinitialization step to the resume_early
handler. This is guaranteed to run before the resume handler of any
other driver.

The power domain initialization in turn requires us to enable the
i915
pci device first, so move that part earlier too.

Accordingly disabling of the i915 pci device should happen after the
audio suspend handler ran. So move the disabling later from the i915
resume handler to the resume_late handler.

v2:
- move intel_uncore_sanitize/early_sanitize earlier too, so they
don't
  get reordered wrt. intel_power_domains_init_hw()

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152
Signed-off-by: Imre Deak 
Reviewed-by: Takashi Iwai 
Cc: sta...@vger.kernel.org
[danvet: Add cc: stable and loud comments that this is just a hack.]
[danvet: Fix "Should it be static?" sparse warning reported by Wu
Fengguang's kbuilder.]
Signed-off-by: Daniel Vetter 


> 
> > Thanks,
> > 
> > Lukas
> > 
> > > 
> > > The comments in i915_drv.c are here:
> > > 
> > > /*
> > >  * We have a suspedn ordering issue with the snd-hda driver also
> > >  * requiring our device to be power up. Due to the lack of a
> > >  * parent/child relationship we currently solve this with an late
> > >  * suspend hook.
> > >  *
> > >  * FIXME: This should be solved with a special hdmi sink device or
> > >  * similar so that power domains can be employed.
> > >  */
> > > 
> > > I believe we could achieve the same ordering by simply pushing it to
> > > suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> > > and resume_early phases altogether in most simple systems. Does anyone see
> > > a problem with this?
> > > 
> > > analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> > > https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> > > https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> > > https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> > > 
> > > analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> > > https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> > > https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> > > https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/
> > > 
> > > Signed-off-by: Todd Brandt 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c | 12 ++--
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 30798cb..759d93c 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops = {
> > >* PMSG_RESUME]
> > >*/
> > >   .suspend = i915_pm_suspend,
> > > - .suspend_late = i915_pm_suspend_late,
> > > - .resume_early = i915_pm_resume_early,
> > > + .suspend_noirq = i915_pm_suspend_late,
> > > + .resume_noirq = i915_pm_resume_early,
> > >   .resume = i915_pm_resume,
> > >  
> > >   /*
> > > @@ -1648,12 +1648,12 @@ static const struct dev_pm_ops 

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 01:17:15PM -0700, Todd Brandt wrote:
> On Wed, 2016-04-27 at 22:31 +0300, Ville Syrjälä wrote:
> > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
> > >  I'd like to propose that we push the i915 suspend_late/resume_early code
> > >  into suspend_noirq/resume_noirq in order to reduce the total suspend time
> > >  by ~15ms. According to the comments, when i915_pm_suspend_late was first 
> > >  added to the kernel back in April 2014, it was done so to ensure that it
> > >  was called after the snd_hda_intel driver had finished its suspend.
> > > 
> > > The comments in i915_drv.c are here:
> > > 
> > > /*
> > >  * We have a suspedn ordering issue with the snd-hda driver also
> > >  * requiring our device to be power up. Due to the lack of a
> > >  * parent/child relationship we currently solve this with an late
> > >  * suspend hook.
> > >  *
> > >  * FIXME: This should be solved with a special hdmi sink device or
> > >  * similar so that power domains can be employed.
> > >  */
> > > 
> > > I believe we could achieve the same ordering by simply pushing it to
> > > suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> > > and resume_early phases altogether in most simple systems. Does anyone see
> > > a problem with this?
> > > 
> > > analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> > > https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> > > https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> > > https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> > > 
> > > analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> > > https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> > > https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> > > https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/
> > 
> > Hmm. Looking at those makes me confused. Why isn't the pci bus
> > .resume_noirq hook (pci_pm_resume_noirq()) waking up our pci device?
> > Instead our wakeup gets delayed until .resume_early for some reason.
> 
> Which timeline are you referring to? The "late" ones are the unaltered
> versions.

Referring to the current code, ie. the "late" timeline.

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

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Todd Brandt]

On Wed, 2016-04-27 at 22:33 +0200, Lukas Wunner wrote:
> Hi,
> 
> On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
> >  I'd like to propose that we push the i915 suspend_late/resume_early code
> >  into suspend_noirq/resume_noirq in order to reduce the total suspend time
> >  by ~15ms. According to the comments, when i915_pm_suspend_late was first
> >  added to the kernel back in April 2014, it was done so to ensure that it
> >  was called after the snd_hda_intel driver had finished its suspend.
> 
> Ordering issues like this one should be solved with device_pm_wait_for_dev(),
> not by shuffling code around among the callbacks.
> 
> In any case it would be good if you would name the sha1 of the commit
> that added i915_pm_suspend_late to spare readers the git blame / git log.
> 

Here's the actual commit that introduced it:

git checkout 76c4b250080fff6e4befaa3619942422fd0ea380
git diff HEAD^ drivers/gpu/drm/i915/i915_drv.c

That shows the initial addition of the _late code.


> Thanks,
> 
> Lukas
> 
> > 
> > The comments in i915_drv.c are here:
> > 
> > /*
> >  * We have a suspedn ordering issue with the snd-hda driver also
> >  * requiring our device to be power up. Due to the lack of a
> >  * parent/child relationship we currently solve this with an late
> >  * suspend hook.
> >  *
> >  * FIXME: This should be solved with a special hdmi sink device or
> >  * similar so that power domains can be employed.
> >  */
> > 
> > I believe we could achieve the same ordering by simply pushing it to
> > suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> > and resume_early phases altogether in most simple systems. Does anyone see
> > a problem with this?
> > 
> > analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> > https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> > https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> > https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> > 
> > analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> > https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> > https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> > https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/
> > 
> > Signed-off-by: Todd Brandt 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 30798cb..759d93c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops = {
> >  * PMSG_RESUME]
> >  */
> > .suspend = i915_pm_suspend,
> > -   .suspend_late = i915_pm_suspend_late,
> > -   .resume_early = i915_pm_resume_early,
> > +   .suspend_noirq = i915_pm_suspend_late,
> > +   .resume_noirq = i915_pm_resume_early,
> > .resume = i915_pm_resume,
> >  
> > /*
> > @@ -1648,12 +1648,12 @@ static const struct dev_pm_ops i915_pm_ops = {
> >  *hibernation image [PMSG_RESTORE]
> >  */
> > .freeze = i915_pm_suspend,
> > -   .freeze_late = i915_pm_suspend_late,
> > -   .thaw_early = i915_pm_resume_early,
> > +   .freeze_noirq = i915_pm_suspend_late,
> > +   .thaw_noirq = i915_pm_resume_early,
> > .thaw = i915_pm_resume,
> > .poweroff = i915_pm_suspend,
> > -   .poweroff_late = i915_pm_poweroff_late,
> > -   .restore_early = i915_pm_resume_early,
> > +   .poweroff_noirq = i915_pm_poweroff_late,
> > +   .restore_noirq = i915_pm_resume_early,
> > .restore = i915_pm_resume,
> >  
> > /* S0ix (via runtime suspend) event handlers */
> > -- 
> > 2.1.4
> > 
> > ___
> > 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] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Lukas Wunner]

Hi,

On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
>  I'd like to propose that we push the i915 suspend_late/resume_early code
>  into suspend_noirq/resume_noirq in order to reduce the total suspend time
>  by ~15ms. According to the comments, when i915_pm_suspend_late was first
>  added to the kernel back in April 2014, it was done so to ensure that it
>  was called after the snd_hda_intel driver had finished its suspend.

Ordering issues like this one should be solved with device_pm_wait_for_dev(),
not by shuffling code around among the callbacks.

In any case it would be good if you would name the sha1 of the commit
that added i915_pm_suspend_late to spare readers the git blame / git log.

Thanks,

Lukas

> 
> The comments in i915_drv.c are here:
> 
> /*
>  * We have a suspedn ordering issue with the snd-hda driver also
>  * requiring our device to be power up. Due to the lack of a
>  * parent/child relationship we currently solve this with an late
>  * suspend hook.
>  *
>  * FIXME: This should be solved with a special hdmi sink device or
>  * similar so that power domains can be employed.
>  */
> 
> I believe we could achieve the same ordering by simply pushing it to
> suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> and resume_early phases altogether in most simple systems. Does anyone see
> a problem with this?
> 
> analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> 
> analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/
> 
> Signed-off-by: Todd Brandt 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 30798cb..759d93c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops = {
>* PMSG_RESUME]
>*/
>   .suspend = i915_pm_suspend,
> - .suspend_late = i915_pm_suspend_late,
> - .resume_early = i915_pm_resume_early,
> + .suspend_noirq = i915_pm_suspend_late,
> + .resume_noirq = i915_pm_resume_early,
>   .resume = i915_pm_resume,
>  
>   /*
> @@ -1648,12 +1648,12 @@ static const struct dev_pm_ops i915_pm_ops = {
>*hibernation image [PMSG_RESTORE]
>*/
>   .freeze = i915_pm_suspend,
> - .freeze_late = i915_pm_suspend_late,
> - .thaw_early = i915_pm_resume_early,
> + .freeze_noirq = i915_pm_suspend_late,
> + .thaw_noirq = i915_pm_resume_early,
>   .thaw = i915_pm_resume,
>   .poweroff = i915_pm_suspend,
> - .poweroff_late = i915_pm_poweroff_late,
> - .restore_early = i915_pm_resume_early,
> + .poweroff_noirq = i915_pm_poweroff_late,
> + .restore_noirq = i915_pm_resume_early,
>   .restore = i915_pm_resume,
>  
>   /* S0ix (via runtime suspend) event handlers */
> -- 
> 2.1.4
> 
> ___
> 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] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Todd Brandt]

On Wed, 2016-04-27 at 22:31 +0300, Ville Syrjälä wrote:
> On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
> >  I'd like to propose that we push the i915 suspend_late/resume_early code
> >  into suspend_noirq/resume_noirq in order to reduce the total suspend time
> >  by ~15ms. According to the comments, when i915_pm_suspend_late was first 
> >  added to the kernel back in April 2014, it was done so to ensure that it
> >  was called after the snd_hda_intel driver had finished its suspend.
> > 
> > The comments in i915_drv.c are here:
> > 
> > /*
> >  * We have a suspedn ordering issue with the snd-hda driver also
> >  * requiring our device to be power up. Due to the lack of a
> >  * parent/child relationship we currently solve this with an late
> >  * suspend hook.
> >  *
> >  * FIXME: This should be solved with a special hdmi sink device or
> >  * similar so that power domains can be employed.
> >  */
> > 
> > I believe we could achieve the same ordering by simply pushing it to
> > suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> > and resume_early phases altogether in most simple systems. Does anyone see
> > a problem with this?
> > 
> > analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> > https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> > https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> > https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> > 
> > analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> > https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> > https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> > https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/
> 
> Hmm. Looking at those makes me confused. Why isn't the pci bus
> .resume_noirq hook (pci_pm_resume_noirq()) waking up our pci device?
> Instead our wakeup gets delayed until .resume_early for some reason.

Which timeline are you referring to? The "late" ones are the unaltered
versions.

> 
> > 
> > Signed-off-by: Todd Brandt 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 30798cb..759d93c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops = {
> >  * PMSG_RESUME]
> >  */
> > .suspend = i915_pm_suspend,
> > -   .suspend_late = i915_pm_suspend_late,
> > -   .resume_early = i915_pm_resume_early,
> > +   .suspend_noirq = i915_pm_suspend_late,
> > +   .resume_noirq = i915_pm_resume_early,
> > .resume = i915_pm_resume,
> >  
> > /*
> > @@ -1648,12 +1648,12 @@ static const struct dev_pm_ops i915_pm_ops = {
> >  *hibernation image [PMSG_RESTORE]
> >  */
> > .freeze = i915_pm_suspend,
> > -   .freeze_late = i915_pm_suspend_late,
> > -   .thaw_early = i915_pm_resume_early,
> > +   .freeze_noirq = i915_pm_suspend_late,
> > +   .thaw_noirq = i915_pm_resume_early,
> > .thaw = i915_pm_resume,
> > .poweroff = i915_pm_suspend,
> > -   .poweroff_late = i915_pm_poweroff_late,
> > -   .restore_early = i915_pm_resume_early,
> > +   .poweroff_noirq = i915_pm_poweroff_late,
> > +   .restore_noirq = i915_pm_resume_early,
> > .restore = i915_pm_resume,
> >  
> > /* S0ix (via runtime suspend) event handlers */
> > -- 
> > 2.1.4
> > 
> > ___
> > 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] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
>  I'd like to propose that we push the i915 suspend_late/resume_early code
>  into suspend_noirq/resume_noirq in order to reduce the total suspend time
>  by ~15ms. According to the comments, when i915_pm_suspend_late was first 
>  added to the kernel back in April 2014, it was done so to ensure that it
>  was called after the snd_hda_intel driver had finished its suspend.
> 
> The comments in i915_drv.c are here:
> 
> /*
>  * We have a suspedn ordering issue with the snd-hda driver also
>  * requiring our device to be power up. Due to the lack of a
>  * parent/child relationship we currently solve this with an late
>  * suspend hook.
>  *
>  * FIXME: This should be solved with a special hdmi sink device or
>  * similar so that power domains can be employed.
>  */
> 
> I believe we could achieve the same ordering by simply pushing it to
> suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> and resume_early phases altogether in most simple systems. Does anyone see
> a problem with this?
> 
> analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> 
> analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/

Hmm. Looking at those makes me confused. Why isn't the pci bus
.resume_noirq hook (pci_pm_resume_noirq()) waking up our pci device?
Instead our wakeup gets delayed until .resume_early for some reason.

> 
> Signed-off-by: Todd Brandt 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 30798cb..759d93c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops = {
>* PMSG_RESUME]
>*/
>   .suspend = i915_pm_suspend,
> - .suspend_late = i915_pm_suspend_late,
> - .resume_early = i915_pm_resume_early,
> + .suspend_noirq = i915_pm_suspend_late,
> + .resume_noirq = i915_pm_resume_early,
>   .resume = i915_pm_resume,
>  
>   /*
> @@ -1648,12 +1648,12 @@ static const struct dev_pm_ops i915_pm_ops = {
>*hibernation image [PMSG_RESTORE]
>*/
>   .freeze = i915_pm_suspend,
> - .freeze_late = i915_pm_suspend_late,
> - .thaw_early = i915_pm_resume_early,
> + .freeze_noirq = i915_pm_suspend_late,
> + .thaw_noirq = i915_pm_resume_early,
>   .thaw = i915_pm_resume,
>   .poweroff = i915_pm_suspend,
> - .poweroff_late = i915_pm_poweroff_late,
> - .restore_early = i915_pm_resume_early,
> + .poweroff_noirq = i915_pm_poweroff_late,
> + .restore_noirq = i915_pm_resume_early,
>   .restore = i915_pm_resume,
>  
>   /* S0ix (via runtime suspend) event handlers */
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 04:09:53PM +, Vivi, Rodrigo wrote:
> On Wed, 2016-04-27 at 19:08 +0300, Ville Syrjälä wrote:
> > On Wed, Apr 27, 2016 at 03:54:12PM +, Vivi, Rodrigo wrote:
> > > On Wed, 2016-04-27 at 17:43 +0300, ville.syrj...@linux.intel.com wr
> > > ote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > I just noticed that VLV/CHV have a RAWCLK_FREQ register just like
> > > > PCH
> > > > platforms. It lives in the display power well, so we should
> > > > update it
> > > > when enabling the power well.
> > > > 
> > > > Interestingly the BIOS seems to leave it at the reset value (125)
> > > > which
> > > > doesn't match the rawclk frequency on VLV/CHV (200 MHz). As
> > > > always
> > > > with
> > > > these register, the spec is extremely vague what the register
> > > > does.
> > > > All
> > > > it says is: "This is used to generate a divided down clock for
> > > > miscellaneous timers in display." Based on a quick test, at least
> > > > AUX
> > > > and PWM appear to be unaffected by this.
> > > > 
> > > > But since the register is there, let's configure it in accordance
> > > > with
> > > > the spec.
> > > > 
> > > > Note that we have to move intel_update_rawclk() to occur before
> > > > we
> > > > touch the power wells, so that the dev_priv->rawclk_freq is
> > > > already
> > > > populated when the disp2 enable hook gets called for the first
> > > > time.
> > > > I think this should be safe to do on other platforms as well.
> > > > 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_dma.c | 3 +++
> > > >  drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > > >  drivers/gpu/drm/i915/intel_display.c| 4 ++--
> > > >  drivers/gpu/drm/i915/intel_drv.h| 1 +
> > > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
> > > >  5 files changed, 13 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > > b/drivers/gpu/drm/i915/i915_dma.c
> > > > index 5c7615041b31..fd1260d2b6ec 100644
> > > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > > @@ -454,6 +454,9 @@ static int i915_load_modeset_init(struct
> > > > drm_device *dev)
> > > > if (ret)
> > > > goto cleanup_vga_client;
> > > >  
> > > > +   /* must happen before intel_power_domains_init_hw() on
> > > > VLV/CHV */
> > > > +   intel_update_rawclk(dev_priv);
> > > 
> > > separated patches since this affects all platforms?!
> > 
> > I was going to do that originally, but then I thought that if we have
> > to
> > revert due to some other platform, it's likely VLV/CHV would be
> > forgotten and only later someone would start to complain about the
> > WARN_ON() I added. So if this change needs to reverted, the VLV/CHV
> > stuff
> > needs to be redone anyway, so having it in the same commit seems like
> > the slightly better option to me.
> 
> oh! makes a lot of sense indeed!
> 
> > 
> > > 
> > > anyways I checked CHV spec here so feel free to ignore me and use
> > > Reviewed-by: Rodrigo Vivi 

Pushed to dinq. Thanks for the review.

> > > 
> > > 
> > > > +
> > > > intel_power_domains_init_hw(dev_priv, false);
> > > >  
> > > > intel_csr_ucode_init(dev_priv);
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 25e229b609a7..0a2fd3000f94 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -2449,6 +2449,8 @@ enum skl_disp_power_wells {
> > > >  #define   DPLL_MD_VGA_UDI_MULTIPLIER_MASK  0x003f
> > > >  #define   DPLL_MD_VGA_UDI_MULTIPLIER_SHIFT 0
> > > >  
> > > > +#define RAWCLK_FREQ_VLV_MMIO(VLV_DISPLAY_BASE +
> > > > 0x6024)
> > > > +
> > > >  #define _FPA0  0x6040
> > > >  #define _FPA1  0x6044
> > > >  #define _FPB0  0x6048
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index b7cb632a2a31..eb7cb9431209 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -185,6 +185,7 @@ intel_pch_rawclk(struct drm_i915_private
> > > > *dev_priv)
> > > >  static int
> > > >  intel_vlv_hrawclk(struct drm_i915_private *dev_priv)
> > > >  {
> > > > +   /* RAWCLK_FREQ_VLV register updated from power well code
> > > > */
> > > > return vlv_get_cck_clock_hpll(dev_priv, "hrawclk",
> > > >  
> > > >  CCK_DISPLAY_REF_CLOCK_CONTROL);
> > > >  }
> > > > @@ -218,7 +219,7 @@ intel_g4x_hrawclk(struct drm_i915_private
> > > > *dev_priv)
> > > > }
> > > >  }
> > > >  
> > > > -static void intel_update_rawclk(struct drm_i915_private
> > > > *dev_priv)
> > > > +void intel_update_rawclk(struct drm_i915_private *dev_priv)
> > > >  {
> > > >

Re: [Intel-gfx] [PATCH] drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

[Ville Syrjälä]

On Mon, Apr 18, 2016 at 08:26:46PM +0300, Jani Nikula wrote:
> On Mon, 18 Apr 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Check for VLV/CHV instead if !BXT when re-enabling DPOunit clock gating
> > after DSI disable. That's what we checked when disabling the clock
> > gating when enabling DSI.
> >
> > Also use the same temporary variable name in both cases, and toss in a
> > bit of dev vs. dev_priv cleanup while at it.
> >
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Jani Nikula 

Pushed to dinq. Thanks for the review.

> 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.c | 13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 34328ddaaab5..599045359538 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -516,7 +516,6 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> > *encoder)
> > struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> > struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> > enum port port;
> > -   u32 tmp;
> >  
> > DRM_DEBUG_KMS("\n");
> >  
> > @@ -535,11 +534,13 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> > *encoder)
> >  
> > msleep(intel_dsi->panel_on_delay);
> >  
> > -   if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> > +   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > +   u32 val;
> > +
> > /* Disable DPOunit clock gating, can stall pipe */
> > -   tmp = I915_READ(DSPCLK_GATE_D);
> > -   tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
> > -   I915_WRITE(DSPCLK_GATE_D, tmp);
> > +   val = I915_READ(DSPCLK_GATE_D);
> > +   val |= DPOUNIT_CLOCK_GATE_DISABLE;
> > +   I915_WRITE(DSPCLK_GATE_D, val);
> > }
> >  
> > /* put device in ready state */
> > @@ -677,7 +678,7 @@ static void intel_dsi_post_disable(struct intel_encoder 
> > *encoder)
> >  
> > intel_dsi_clear_device_ready(encoder);
> >  
> > -   if (!IS_BROXTON(dev_priv)) {
> > +   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > u32 val;
> >  
> > val = I915_READ(DSPCLK_GATE_D);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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

Re: [Intel-gfx] [CI-ping 15/15] drm/i915: Late request cancellations are harmful

[Dave Gordon]

On 22/04/16 23:57, John Harrison wrote:

On 21/04/2016 14:04, John Harrison wrote:

On 19/04/2016 13:35, Dave Gordon wrote:

On 13/04/16 15:21, John Harrison wrote:

On 13/04/2016 10:57, Daniel Vetter wrote:

On Tue, Apr 12, 2016 at 09:03:09PM +0100, Chris Wilson wrote:

Conceptually, each request is a record of a hardware transaction - we
build up a list of pending commands and then either commit them to
hardware, or cancel them. However, whilst building up the list of
pending commands, we may modify state outside of the request and make
references to the pending request. If we do so and then cancel that
request, external objects then point to the deleted request
leading to
both graphical and memory corruption.

The easiest example is to consider object/VMA tracking. When we
mark an
object as active in a request, we store a pointer to this, the most
recent request, in the object. Then we want to free that object,
we wait
for the most recent request to be idle before proceeding
(otherwise the
hardware will write to pages now owned by the system, or we will
attempt
to read from those pages before the hardware is finished writing). If
the request was cancelled instead, that wait completes
immediately. As a
result, all requests must be committed and not cancelled if the
external
state is unknown.

All that remains of i915_gem_request_cancel() users are just a
couple of
extremely unlikely allocation failures, so remove the API entirely.

A consequence of committing all incomplete requests is that we
generate
excess breadcrumbs and fill the ring much more often with dummy
work. We
have completely undone the outstanding_last_seqno optimisation.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93907
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: sta...@vger.kernel.org

Cc: John Harrison 

I'd like John's ack on this on too, but patch itself looks sound. Fast
r-b
since we've discussed this a while ago already ...


I think this is going to cause a problem with the scheduler. You are
effectively saying that the execbuf call cannot fail beyond the
point of
allocating a request. If it gets that far then it must go all the way
and submit the request to the hardware. With a scheduler, that means
adding it to the scheduler's queues and tracking it all the way through
the system to completion. If nothing else, that sounds like a lot of
extra overhead for no actual work. Or worse if the failure is at a
point
where the request cannot be sent further through the system because it
was something critical that failed then you are really stuffed.

I'm not sure what the other option would be though, short of being able
to undo the last read/write object tracking updates.


With the chained-ownership code we have in the scheduler, it becomes
perfectly possible to undo the last-read/write tracking changes.

I'd much rather see any failure during submission rewound and undone,
so we can just return -EAGAIN at any point and let someone retry if
required.

This just looks like a hack to work around not having a properly
transactional model of request submission :(

.Dave.


I was thinking if it would be possible to delay the tracking updates
until later in the execbuf process. I.e. only do it after all
potential failure points. That would be a much simpler change than
putting in chained ownership.

However, it seems that the patch has already been merged despite this
discussion and Daniel Vetter wanting an ack first? Is that correct?

John.


Dave Gordon and myself had a look at the option of delaying the object
tracking until beyond the point of last possible failure in the execbuf
call path. As far as we can tell, it already is. The object tracking
update occurs in i915_gem_execbuffer_move_to_active(). That function
cannot return a failure code and is immediately followed (in both LRC
and legacy mode) by a call to i915_gem_execbuffer_retire_commands()
which is what flushes out the request to the hardware. So it would
appear that this patch has no effect on object tracking within the
execbuf code path. If a request cancellation code path was taken then
the tracking would not have been updated and so the request is
irrelevant as it has no references to it. If the tracking was updated
and the request is being referenced then the request was also guaranteed
to have been submitted and not cancelled.

Either we are missing something major somewhere or this patch cannot fix
the stated bug in the stated manner?

I have tried running the failing test myself but when I try to run the
particular gem_concurrent_blit subtest it tells me that it requires more
'objects' and/or RAM than I have available. What does one need in order
to run the test? The bug report also does not say whether it is a
guaranteed failure every time or a sporadic, once in X many runs kind of
failure?

Thanks,
John.


Maybe it's 

[Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

[Todd Brandt]

 I'd like to propose that we push the i915 suspend_late/resume_early code
 into suspend_noirq/resume_noirq in order to reduce the total suspend time
 by ~15ms. According to the comments, when i915_pm_suspend_late was first 
 added to the kernel back in April 2014, it was done so to ensure that it
 was called after the snd_hda_intel driver had finished its suspend.

The comments in i915_drv.c are here:

/*
 * We have a suspedn ordering issue with the snd-hda driver also
 * requiring our device to be power up. Due to the lack of a
 * parent/child relationship we currently solve this with an late
 * suspend hook.
 *
 * FIXME: This should be solved with a special hdmi sink device or
 * similar so that power domains can be employed.
 */

I believe we could achieve the same ordering by simply pushing it to
suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
and resume_early phases altogether in most simple systems. Does anyone see
a problem with this?

analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/

analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/

Signed-off-by: Todd Brandt 
---
 drivers/gpu/drm/i915/i915_drv.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 30798cb..759d93c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops = {
 * PMSG_RESUME]
 */
.suspend = i915_pm_suspend,
-   .suspend_late = i915_pm_suspend_late,
-   .resume_early = i915_pm_resume_early,
+   .suspend_noirq = i915_pm_suspend_late,
+   .resume_noirq = i915_pm_resume_early,
.resume = i915_pm_resume,
 
/*
@@ -1648,12 +1648,12 @@ static const struct dev_pm_ops i915_pm_ops = {
 *hibernation image [PMSG_RESTORE]
 */
.freeze = i915_pm_suspend,
-   .freeze_late = i915_pm_suspend_late,
-   .thaw_early = i915_pm_resume_early,
+   .freeze_noirq = i915_pm_suspend_late,
+   .thaw_noirq = i915_pm_resume_early,
.thaw = i915_pm_resume,
.poweroff = i915_pm_suspend,
-   .poweroff_late = i915_pm_poweroff_late,
-   .restore_early = i915_pm_resume_early,
+   .poweroff_noirq = i915_pm_poweroff_late,
+   .restore_noirq = i915_pm_resume_early,
.restore = i915_pm_resume,
 
/* S0ix (via runtime suspend) event handlers */
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

[Dave Gordon]

On 27/04/16 15:53, Chris Wilson wrote:

On Wed, Apr 27, 2016 at 04:25:09PM +0300, Eero Tamminen wrote:

Hi,

On 26.04.2016 20:25, Frederick, Michael T wrote:

Sorry I'm not tracking all the MOCs discussions.  I just want to indicate what 
the coherency means in SoC for BXT.

GTI sets the non-inclusive bit on the IDI interface based on how it treats the memory.  
In BXT case where there is no uncore cache, "non-inclusive" just indicates 
snoop or not.  BXT has a snoop filter in order to make the latency of snooping GT from a 
core roughly similar to snooping another core.

For BXT:
If GTI sets non-inclusive=0 (i.e. coherent): transaction looks up in the SF and 
the SA snoops the cores.  The potential impact here is that for high BW 
coherent traffic, the SF will become the BW limiter of the system and cap BW at 
33% * 34GBps. For writes like WCILFs snoops to cores must be resolved before SA 
requests WR data from GT.  For reads the common case should have no impact 
because snoop latency is generally much less than memory data latency.  In 
general snoop latency for a core is relatively small, but there is also the 
prospect that a core could be down (e.g. ratio change) or loaded w/ snooping.
If GTI sets non-inclusive=1 (i.e. non-coherent): transaction takes the SF 
bypass and the SA does not snoop the cores.  This is best for high-BW since it 
removes the SF bottleneck and doesn't require core interaction.


Thanks for the explanation!

AFAIK:

* In regards to 3D driver operations, CPU side doesn't modify the
buffer contents while GPU is working on them.  CPU side sets up the
buffers (textures, VBOs, batches etc), and then (after a flush) GPU
is asked to act on them.

* For things like texture streaming, the driver either internally
synchronizes the data or creates a new copy of it whenever
application tells that data is updated.  There's always some kind of
"upload" involved (GL API needs it as non-integrated GPU's don't
share memory with CPU).

While it's possible that there's a case where snooping would be
needed, I cannot think of any myself.

Daniel, Chris, did you have some concrete example in mind where 3D
driver would require CPU to snoop GPU?


Not mesa, but X can do concurrent rendering to a Pixmap whilst also
rendering from other parts of that Pixmap into a GPU side buffer and
presentation/compositing thereof. X uses snooping both ways (from client
memory to GPU and from GPU to client memory) as well as mixed rendering.

Mesa should be using snooping for both SubTexImage and GetTexImage. On
the SubTexImage path you can use the sampler to do format conversions
that even including the sync overhead for correctness when using client
memory avoid the awful format conversion code in mesa. Using the GPU to
write into client memory and avoiding WC reads is approximately an
order of magnitude (8x) faster than the current code mesa uses.
-Chris


Presumably its useful for the CPU to snoop the h/w status page(s), and 
maybe the ring-context part of a context image (so that TAIL updates are 
coherent), but OTOH snooping the rest of the context image might add 
overhead, and AFAIK we don't normally read (or write) any of that after 
setup. So maybe we don't want vmap-whole-object after all?


.Dave.

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

Re: [Intel-gfx] Kernel Oops on 3.14.66

[Dave Gordon]

2016-04-27 12:03 GMT+02:00 Dave Gordon :


On 27/04/16 10:19, Andreas Lampersperger wrote:


Hello,

has anyone here a hint for me, what can cause this error.
The error occures highly sporadic on different machines with intel hd
graphics (ivb_gt1).
I did also some kernel coredumps and found out, that the failed
paging request came from drm_i915_gem_request->list.prev or ->list.next.

Thank you
Andreas


Try this patch.

.Dave.



On 27/04/16 13:20, Andreas Lampersperger wrote:

Hi Dave,

thank you for the patch, but I'm using longtime kernel 3.14.66 and so the
patch does not fit.
Do you have any suggestions for that kernel?

Andreas


I have no idea what the code would look like in that version; do you 
have any way to get the git commit hash or tag of the i915 driver?


But essentially, if you have the kernel sources for that version, you 
could look for a line that allocates a "struct drm_i915_gem_request". It 
might be


req = kmem_cache_zalloc(dev_priv->requests, GFP_KERNEL);

or in older versions it might be

request = kzalloc(sizeof(*request), GFP_KERNEL);

or some other variation. It should of course be followed by a test for 
successful allocation, e.g.


if (request == NULL)
return -ENOMEM;

If you can find that line (or lines, at one time there were TWO such 
places), then you just have to add


INIT_LIST_HEAD(>list);

after the test-for-NULL, or anywhere inline thereafter. For example:

request = kzalloc(sizeof(*request), GFP_KERNEL);
if (request == NULL)
return -ENOMEM;

ret = i915_gem_get_seqno(ring->dev, >seqno);
if (ret) {
kfree(request);
return ret;
}

+   INIT_LIST_HEAD(>list);
kref_init(>ref);
request->ring = ring;
request->uniq = dev_private->request_uniq++;

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

[Intel-gfx] [PATCH v2 5/5] DO NOT MERGE: change default to using GuC submission if possible

[Dave Gordon]

This patch simply changes the default value of "enable_guc_submission"
from 0 (never) to -1 (auto). This means that GuC submission will be
used if the platform has a GuC, the GuC supports the request submission
protocol, and any required GuC firmwware was successfully loaded. If any
of these conditions are not met, the driver will fall back to using
execlist mode.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 6a5578c..573e787 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,7 +55,7 @@ struct i915_params i915 __read_mostly = {
.nuclear_pageflip = 0,
.edp_vswing = 0,
.enable_guc_loading = -1,
-   .enable_guc_submission = 0,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -207,7 +207,7 @@ struct i915_params i915 __read_mostly = {
 module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
 MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

[Dave Gordon]

Mostly little optimisations; for instance, if the driver is correctly
following the submission protocol, the "out of space" condition is
impossible, so the previous runtime WARN_ON() is promoted to a
GEM_BUG_ON() for a more dramatic effect in development and less impact
in end-user systems.

Similarly we can replace other WARN_ON() conditions that don't relate to
the hardware state with either BUILD_BUG_ON() for compile-time-
detectable issues, or GEM_BUG_ON() for logical "can't happen" errors.

With those changes, we can convert it to void, as suggested by Chris
Wilson, and update the calling code appropriately.

Signed-off-by: Dave Gordon 
Cc: Chris Wilson 

---
 drivers/gpu/drm/i915/i915_guc_submission.c | 69 +++---
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  3 +-
 3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6626eff..4d2ea84 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -470,23 +470,28 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request 
*request)
return -EAGAIN;
 }
 
-static int guc_add_workqueue_item(struct i915_guc_client *gc,
- struct drm_i915_gem_request *rq)
+static void guc_add_workqueue_item(struct i915_guc_client *gc,
+  struct drm_i915_gem_request *rq)
 {
+   /* wqi_len is in DWords, and does not include the one-word header */
+   const size_t wqi_size = sizeof(struct guc_wq_item);
+   const u32 wqi_len = wqi_size/sizeof(u32) - 1;
struct guc_process_desc *desc;
struct guc_wq_item *wqi;
void *base;
-   u32 tail, wq_len, wq_off, space;
+   u32 space, tail, wq_off, wq_page;
 
desc = gc->client_base + gc->proc_desc_offset;
+
+   /* Space was checked earlier, in i915_guc_wq_check_space() above */
space = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
-   if (WARN_ON(space < sizeof(struct guc_wq_item)))
-   return -ENOSPC; /* shouldn't happen */
+   GEM_BUG_ON(space < wqi_size);
 
-   /* postincrement WQ tail for next time */
-   wq_off = gc->wq_tail;
-   gc->wq_tail += sizeof(struct guc_wq_item);
-   gc->wq_tail &= gc->wq_size - 1;
+   /* The GuC firmware wants the tail index in QWords, not bytes */
+   tail = rq->tail;
+   GEM_BUG_ON(tail & 7);
+   tail >>= 3;
+   GEM_BUG_ON(tail > WQ_RING_TAIL_MAX);
 
/* For now workqueue item is 4 DWs; workqueue buffer is 2 pages. So we
 * should not have the case where structure wqi is across page, neither
@@ -495,19 +500,23 @@ static int guc_add_workqueue_item(struct i915_guc_client 
*gc,
 * XXX: if not the case, we need save data to a temp wqi and copy it to
 * workqueue buffer dw by dw.
 */
-   WARN_ON(sizeof(struct guc_wq_item) != 16);
-   WARN_ON(wq_off & 3);
+   BUILD_BUG_ON(wqi_size != 16);
 
-   /* wq starts from the page after doorbell / process_desc */
-   base = kmap_atomic(i915_gem_object_get_page(gc->client_obj,
-   (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT));
+   /* postincrement WQ tail for next time */
+   wq_off = gc->wq_tail;
+   gc->wq_tail += wqi_size;
+   gc->wq_tail &= gc->wq_size - 1;
+   GEM_BUG_ON(wq_off & (wqi_size - 1));
+
+   /* WQ starts from the page after doorbell / process_desc */
+   wq_page = (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT;
wq_off &= PAGE_SIZE - 1;
+   base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, wq_page));
wqi = (struct guc_wq_item *)((char *)base + wq_off);
 
-   /* len does not include the header */
-   wq_len = sizeof(struct guc_wq_item) / sizeof(u32) - 1;
+   /* Now fill in the 4-word work queue item */
wqi->header = WQ_TYPE_INORDER |
-   (wq_len << WQ_LEN_SHIFT) |
+   (wqi_len << WQ_LEN_SHIFT) |
(rq->engine->guc_id << WQ_TARGET_SHIFT) |
WQ_NO_WCFLUSH_WAIT;
 
@@ -515,14 +524,10 @@ static int guc_add_workqueue_item(struct i915_guc_client 
*gc,
wqi->context_desc = (u32)intel_lr_context_descriptor(rq->ctx,
 rq->engine);
 
-   /* The GuC firmware wants the tail index in QWords, not bytes */
-   tail = rq->ringbuf->tail >> 3;
wqi->ring_tail = tail << WQ_RING_TAIL_SHIFT;
-   wqi->fence_id = 0; /*XXX: what fence to be here */
+   wqi->fence_id = rq->seqno;
 
kunmap_atomic(base);
-
-   return 0;
 }
 
 /**
@@ -537,26 +542,20 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
unsigned int engine_id = rq->engine->guc_id;
struct intel_guc *guc = >i915->guc;
  

[Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

[Dave Gordon]

Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)

We'll also add a counter to the GuC client statistics, to see how often
we find the WQ full.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  1 +
 drivers/gpu/drm/i915/i915_guc_submission.c | 16 +---
 drivers/gpu/drm/i915/intel_guc.h   |  8 
 3 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8b8d6f0..1024947 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2509,6 +2509,7 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
client->wq_size, client->wq_offset, client->wq_tail);
 
+   seq_printf(m, "\tWork queue full: %u\n", client->no_wq_space);
seq_printf(m, "\tFailed to queue: %u\n", client->q_fail);
seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
seq_printf(m, "\tLast submission result: %d\n", client->retcode);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 66af5ce..6626eff 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -453,27 +453,21 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
 
 int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
 {
-   const size_t size = sizeof(struct guc_wq_item);
+   const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
struct guc_process_desc *desc;
-   int ret = -ETIMEDOUT, timeout_counter = 200;
 
if (!gc)
return 0;
 
desc = gc->client_base + gc->proc_desc_offset;
 
-   while (timeout_counter-- > 0) {
-   if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) {
-   ret = 0;
-   break;
-   }
+   if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= wqi_size)
+   return 0;
 
-   if (timeout_counter)
-   usleep_range(1000, 2000);
-   };
+   gc->no_wq_space += 1;
 
-   return ret;
+   return -EAGAIN;
 }
 
 static int guc_add_workqueue_item(struct i915_guc_client *gc,
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b37c731..436f2d6 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -73,10 +73,10 @@ struct i915_guc_client {
 
/* GuC submission statistics & status */
uint64_t submissions[GUC_MAX_ENGINES_NUM];
-   uint32_t q_fail;
-   uint32_t b_fail;
-   int retcode;
-   int spare;  /* pad to 32 DWords */
+   uint32_t no_wq_space;   /* Space pre-check failed   */
+   uint32_t q_fail;/* Failed to queue (MBZ)*/
+   uint32_t b_fail;/* Doorbell failure (MBZ)   */
+   int retcode;/* Result of last guc_submit()  */
 };
 
 enum intel_guc_fw_status {
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

[Dave Gordon]

The knowledge of how to derive the relevant client from the request
should be localised within i915_guc_submission.c; the LRC code shouldn't
have to know about the internal details of the GuC submission process.
And all the information the GuC code needs should be encapsulated in (or
reachable from) the request.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 11 ++-
 drivers/gpu/drm/i915/intel_guc.h   |  5 ++---
 drivers/gpu/drm/i915/intel_lrc.c   |  9 +++--
 3 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 42d2efa..66af5ce 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -451,10 +451,11 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
 sizeof(desc) * client->ctx_index);
 }
 
-int i915_guc_wq_check_space(struct i915_guc_client *gc)
+int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
 {
+   const size_t size = sizeof(struct guc_wq_item);
+   struct i915_guc_client *gc = request->i915->guc.execbuf_client;
struct guc_process_desc *desc;
-   u32 size = sizeof(struct guc_wq_item);
int ret = -ETIMEDOUT, timeout_counter = 200;
 
if (!gc)
@@ -537,11 +538,11 @@ static int guc_add_workqueue_item(struct i915_guc_client 
*gc,
  *
  * Return: 0 if succeed
  */
-int i915_guc_submit(struct i915_guc_client *client,
-   struct drm_i915_gem_request *rq)
+int i915_guc_submit(struct drm_i915_gem_request *rq)
 {
-   struct intel_guc *guc = client->guc;
unsigned int engine_id = rq->engine->guc_id;
+   struct intel_guc *guc = >i915->guc;
+   struct i915_guc_client *client = guc->execbuf_client;
int q_ret, b_ret;
 
q_ret = guc_add_workqueue_item(client, rq);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9d79c4c..b37c731 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -148,10 +148,9 @@ extern int intel_guc_resume(struct drm_device *dev);
 /* i915_guc_submission.c */
 int i915_guc_submission_init(struct drm_device *dev);
 int i915_guc_submission_enable(struct drm_device *dev);
-int i915_guc_submit(struct i915_guc_client *client,
-   struct drm_i915_gem_request *rq);
+int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
+int i915_guc_submit(struct drm_i915_gem_request *rq);
 void i915_guc_submission_disable(struct drm_device *dev);
 void i915_guc_submission_fini(struct drm_device *dev);
-int i915_guc_wq_check_space(struct i915_guc_client *client);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2b7e6bb..b8ec8c6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -708,9 +708,7 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
 * going any further, as the i915_add_request() call
 * later on mustn't fail ...
 */
-   struct intel_guc *guc = >i915->guc;
-
-   ret = i915_guc_wq_check_space(guc->execbuf_client);
+   ret = i915_guc_wq_check_space(request);
if (ret)
return ret;
}
@@ -776,7 +774,6 @@ static int logical_ring_wait_for_space(struct 
drm_i915_gem_request *req,
 intel_logical_ring_advance_and_submit(struct drm_i915_gem_request *request)
 {
struct intel_ringbuffer *ringbuf = request->ringbuf;
-   struct drm_i915_private *dev_priv = request->i915;
struct intel_engine_cs *engine = request->engine;
 
intel_logical_ring_advance(ringbuf);
@@ -806,8 +803,8 @@ static int logical_ring_wait_for_space(struct 
drm_i915_gem_request *req,
}
}
 
-   if (dev_priv->guc.execbuf_client)
-   i915_guc_submit(dev_priv->guc.execbuf_client, request);
+   if (i915.enable_guc_submission)
+   i915_guc_submit(request);
else
execlists_context_queue(request);
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

[Dave Gordon]

Split the function of "enable_guc_submission" into two separate
options.  The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.

In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
 -1 (default) whatever the platform default is
  0  DISABLE  don't load/use the GuC
  1  BEST EFFORT  try to load/use the GuC, fallback if not available
  2  REQUIRE  must load/use the GuC, else leave the GPU wedged

The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_gem.c|  1 -
 drivers/gpu/drm/i915/i915_guc_submission.c |  4 +-
 drivers/gpu/drm/i915/i915_params.c | 14 -
 drivers/gpu/drm/i915/i915_params.h |  3 +-
 drivers/gpu/drm/i915/intel_guc_loader.c| 98 --
 drivers/gpu/drm/i915/intel_uncore.c|  2 +-
 6 files changed, 70 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d493e79..b04effc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4910,7 +4910,6 @@ int i915_gem_init_engines(struct drm_device *dev)
ret = intel_guc_ucode_load(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
-   ret = -EIO;
goto out;
}
}
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 72d6665..42d2efa 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -970,7 +970,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
 
-   if (!i915.enable_guc_submission)
+   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
 
ctx = dev_priv->kernel_context;
@@ -996,7 +996,7 @@ int intel_guc_resume(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
 
-   if (!i915.enable_guc_submission)
+   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
 
ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 383c076..6a5578c 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -54,7 +54,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_submission = false,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -198,8 +199,15 @@ struct i915_params i915 __read_mostly = {
 "(0=use value from vbt [default], 1=low power swing(200mV),"
 "2=default swing(400mV))");
 
-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission 
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
+MODULE_PARM_DESC(enable_guc_loading,
+   "Enable GuC firmware loading "
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+   "Enable GuC submission "
+   "(-1=auto, 0=never [default], 1=if available, 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 65e73dd..1323261 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,8 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+   int enable_guc_loading;
+   int enable_guc_submission;
int guc_log_level;
int use_mmio_flip;
int mmio_debug;
@@ -57,7 +59,6 @@ struct i915_params {
bool load_detect_test;
bool reset;
bool disable_display;
-   bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
bool enable_dp_mst;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

[Dave Gordon]

On 26/04/16 15:00, Daniel Vetter wrote:

On Mon, Apr 25, 2016 at 09:29:42AM +0100, Chris Wilson wrote:

On Mon, Apr 25, 2016 at 08:31:07AM +0100, Dave Gordon wrote:

On 22/04/16 19:51, Chris Wilson wrote:

On Fri, Apr 22, 2016 at 07:45:15PM +0100, Chris Wilson wrote:

On Fri, Apr 22, 2016 at 07:22:55PM +0100, Dave Gordon wrote:

This patch simply changes the default value of "enable_guc_submission"

>from 0 (never) to -1 (auto). This means that GuC submission will be

used if the platform has a GuC, the GuC supports the request submission
protocol, and any required GuC firmwware was successfully loaded. If any
of these conditions are not met, the driver will fall back to using
execlist mode.


I just remembered something else.

  * Work Items:
  * There are several types of work items that the host may place into a
  * workqueue, each with its own requirements and limitations. Currently only
  * WQ_TYPE_INORDER is needed to support legacy submission via GuC, which
  * represents in-order queue. The kernel driver packs ring tail pointer and an
  * ELSP context descriptor dword into Work Item.

Is this right? You only allocate a single client covering all engines and
specify INORDER. We expect parallel execution between engines, is this
supported? Empirically it seems like guc is only executing commands in
series across engines and not in parallel.
-Chris


AFAIK, INORDER represents in-order executions of elements in the
GuC's (internal) submission queue, which is per-engine; i.e. this
option bypasses the GuC's internal scheduling algorithms and makes
the GuC behave as a simple dispatcher. It demultiplexes work queue
items into the multiple submission queues, then executes them in
order from there.

Alex can probably confirm this in the GuC code, but I really think
we'd have noticed if execution were serialised across engines. For a
start, the validation tests that have one engine busy-spin while
waiting for a batch on a different engine to update a buffer
wouldn't ever finish.


That doesn't seem to be the issue, we can run in parallel it seems
(busy-spin on one engine doesn't prevent a write on the second). It's
just the latency it seems. Overall the execution latency goes up
substantially with guc, and in this case it does not seem to be executing
the second execbuf on the second ring until after the first completes.


That sounds like a decent bug in guc code, and defeats the point of all
the work to speed up execlist submission going on right now.

Can we have non-slow guc somehow? Do we need to escalate this to the
firmware folks and first make sure they have a firmware released which
doesn't like to twiddle thumsb (assuming it's a guc issue indeed and not
in how we submit things)?


According to the numbers I was getting yesterday, GuC submission is now 
slightly faster than execlists on the render engine (because execlists 
is slower on that engine), but still a bit slower on the others. See


http://www.spinics.net/lists/intel-gfx/msg94140.html


Afaiui the point of guc was to reduce submission latency by again having a
queue to submit to, instead of the 1.5 submit ports with execlist. There's
other reasons on top, but if firmware engineers butchered that it doesn't
look good.
-Daniel


I don't think it was ever about latency. I think the GuC was added to 
reduce the overhead of fielding context-switch interrupts on the CPU.


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Cdclk related fixes and polish

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 08:28:17PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 27, 2016 at 06:19:15AM -, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915: Cdclk related fixes and polish
> > URL   : https://patchwork.freedesktop.org/series/6354/
> > State : warning
> > 
> > == Summary ==
> > 
> > Series 6354v1 drm/i915: Cdclk related fixes and polish
> > http://patchwork.freedesktop.org/api/1.0/series/6354/revisions/1/mbox/
> > 
> > Test drv_module_reload_basic:
> > pass   -> SKIP   (skl-nuci5)
> 
> Reloading i915.ko with
> unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
> module successfully unloaded
> module successfully loaded again
> Reloading i915.ko with inject_load_failure=1
> unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
> Reloading i915.ko with inject_load_failure=2
> unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
> Reloading i915.ko with inject_load_failure=3
> unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
> Reloading i915.ko with inject_load_failure=4
> unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
> Reloading i915.ko with
> unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
> 
> rmmod: ERROR: Module i915 is in use
> rmmod: ERROR: Module i915 is in use
> rmmod: ERROR: Module i915 is in use
> rmmod: ERROR: Module i915 is in use
> rmmod: ERROR: Module i915 is in use
> 
> So it managed to unload once, and after that it was no longer possible
> to unload.
> 
> [  436.902443] Console: switching to colour dummy device 80x25
> ...
> [  439.185816] [drm] Module unloaded
> [  439.285377] [drm:intel_detect_pch] Found SunrisePoint LP PCH
> ...
> [  440.671701] [drm] Initialized i915 1.6.0 20160425 for :00:02.0 on 
> minor 0
> [  440.690772] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
> i915_audio_component_bind_ops [i915])
> [  440.719344] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC283: 
> line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:hp
> [  440.719352] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
> (0x0/0x0/0x0/0x0/0x0)
> [  440.719356] snd_hda_codec_realtek hdaudioC0D0:hp_outs=0 
> (0x0/0x0/0x0/0x0/0x0)
> [  440.719359] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
> [  440.719362] snd_hda_codec_realtek hdaudioC0D0:inputs:
> [  440.719366] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x19
> [  440.798836] input: HDA Intel PCH Mic as 
> /devices/pci:00/:00:1f.3/sound/card0/input13
> [  440.801278] input: HDA Intel PCH Headphone as 
> /devices/pci:00/:00:1f.3/sound/card0/input14
> [  440.802905] input: HDA Intel PCH HDMI/DP,pcm=3 as 
> /devices/pci:00/:00:1f.3/sound/card0/input15
> [  440.804662] input: HDA Intel PCH HDMI/DP,pcm=7 as 
> /devices/pci:00/:00:1f.3/sound/card0/input16
> [  440.806351] input: HDA Intel PCH HDMI/DP,pcm=8 as 
> /devices/pci:00/:00:1f.3/sound/card0/input17
> 
> after that nothing related. No real idea who/what was supposedly using
> the module afterwards. Could have been snd-hda I suppose. It doesn't
> seem to leave any trace in dmesg when it unloads, so can't tell from the 
> dmesg.

Oh there was actually 
[  440.936260] Console: switching to colour dummy device 80x25
afterwards, so at least the console unbind worked a second time.

> 
> > Test kms_pipe_crc_basic:
> > Subgroup hang-read-crc-pipe-b:
> > incomplete -> PASS   (snb-dellxps)
> > 
> > bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
> > bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
> > bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> > byt-nuc  total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> > hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
> > skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
> > skl-nuci5total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
> > snb-dellxps  total:200  pass:158  dwarn:0   dfail:0   fail:0   skip:42 
> > snb-x220ttotal:200  pass:158  dwarn:0   dfail:0   fail:1   skip:41 
> > 
> > Results at /archive/results/CI_IGT_test/Patchwork_2080/
> > 
> > e005db1cb2c60d18abe837ac683d8993ea77b239 drm-intel-nightly: 
> > 2016y-04m-26d-12h-51m-57s UTC integration manifest
> > b85d9d7 drm/i915: Fix comments about GMBUSFREQ register
> > f897835 drm/i915: Use cached cdclk value in 
> > i915_audio_component_get_cdclk_freq()
> > 4e443d4 drm/i915: Update CDCLK_FREQ register on BDW after changing cdclk 
> > frequency
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH] drm/i915: Fix enc_to_dig_port() for MST encoders

[Lyude]

For MST encoders, the encoder struct is stored in the intel_dp_mst
struct, not a intel_digital_port struct.

This fixes issues with hotplugging MST displays that support MST audio,
where hotplugging had a surprisingly good chance of accidentally
overwriting other parts of the kernel leading to seemingly unrelated
backtraces in sysfs, ext4, etc.

Cc: sta...@vger.kernel.org
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_drv.h | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4c027d6..81f2212 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -918,18 +918,23 @@ intel_attached_encoder(struct drm_connector *connector)
return to_intel_connector(connector)->encoder;
 }
 
-static inline struct intel_digital_port *
-enc_to_dig_port(struct drm_encoder *encoder)
-{
-   return container_of(encoder, struct intel_digital_port, base.base);
-}
-
 static inline struct intel_dp_mst_encoder *
 enc_to_mst(struct drm_encoder *encoder)
 {
return container_of(encoder, struct intel_dp_mst_encoder, base.base);
 }
 
+static inline struct intel_digital_port *
+enc_to_dig_port(struct drm_encoder *encoder)
+{
+   if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST)
+   return enc_to_mst(encoder)->primary;
+   else {
+   return container_of(encoder, struct intel_digital_port,
+   base.base);
+   }
+}
+
 static inline struct intel_dp *enc_to_intel_dp(struct drm_encoder *encoder)
 {
return _to_dig_port(encoder)->dp;
-- 
2.5.5

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

Re: [Intel-gfx] [PATCH] drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

[Vivi, Rodrigo]

On Wed, 2016-04-27 at 16:53 +0100, Chris Wilson wrote:
> On Wed, Apr 27, 2016 at 08:47:54AM -0700, Rodrigo Vivi wrote:
> > We have in the history some changes on this behaviour, but
> > there are many platforms out there and we don't know all panels.
> > 
> > VBT might not be reliable but it knows the platform better than
> > us usually. Or at least it should.
> > So, first of all let's respect the VBT. If something bad happens
> > again with one platform or another it is better to create a
> > quirk than to bypass the VBT.
> > 
> > Cc: Mihai Dontu 
> > Cc: Jani Nikula 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index c3abae4..e65e2c3 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -788,14 +788,11 @@ void intel_psr_init(struct drm_device *dev)
> > }
> >  
> > /* Set link_standby x link_off defaults */
> > -   if (IS_HASWELL(dev) || IS_BROADWELL(dev))
> > -   /* HSW and BDW require workarounds that we don't
> > implement. */
> > -   dev_priv->psr.link_standby = false;
> 
> This patch has nothing to do with respecting the VBT or not, it's
> about
> whether the comment that we still require w/a is valid or not.
> 
> That's not even mentioned in the changelog.

Oh you are right... Looking to the logs and HSD it seems that we still
need the workaround on HSW and BDW, since HSW has no single frame
update and we don't implement on BDW because it requires other 3 W/a...

Maybe we should just disable PSR for the cases VBT tells only link
standby is supported on HSW and BDW.

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Cdclk related fixes and polish

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 06:19:15AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Cdclk related fixes and polish
> URL   : https://patchwork.freedesktop.org/series/6354/
> State : warning
> 
> == Summary ==
> 
> Series 6354v1 drm/i915: Cdclk related fixes and polish
> http://patchwork.freedesktop.org/api/1.0/series/6354/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> SKIP   (skl-nuci5)

Reloading i915.ko with
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
module successfully unloaded
module successfully loaded again
Reloading i915.ko with inject_load_failure=1
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
Reloading i915.ko with inject_load_failure=2
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
Reloading i915.ko with inject_load_failure=3
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
Reloading i915.ko with inject_load_failure=4
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
Reloading i915.ko with
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device

rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use

So it managed to unload once, and after that it was no longer possible
to unload.

[  436.902443] Console: switching to colour dummy device 80x25
...
[  439.185816] [drm] Module unloaded
[  439.285377] [drm:intel_detect_pch] Found SunrisePoint LP PCH
...
[  440.671701] [drm] Initialized i915 1.6.0 20160425 for :00:02.0 on minor 0
[  440.690772] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[  440.719344] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC283: 
line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:hp
[  440.719352] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[  440.719356] snd_hda_codec_realtek hdaudioC0D0:hp_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[  440.719359] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[  440.719362] snd_hda_codec_realtek hdaudioC0D0:inputs:
[  440.719366] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x19
[  440.798836] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[  440.801278] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[  440.802905] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[  440.804662] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[  440.806351] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input17

after that nothing related. No real idea who/what was supposedly using
the module afterwards. Could have been snd-hda I suppose. It doesn't
seem to leave any trace in dmesg when it unloads, so can't tell from the dmesg.

> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-b:
> incomplete -> PASS   (snb-dellxps)
> 
> bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
> bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> byt-nuc  total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
> skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
> skl-nuci5total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
> snb-dellxps  total:200  pass:158  dwarn:0   dfail:0   fail:0   skip:42 
> snb-x220ttotal:200  pass:158  dwarn:0   dfail:0   fail:1   skip:41 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2080/
> 
> e005db1cb2c60d18abe837ac683d8993ea77b239 drm-intel-nightly: 
> 2016y-04m-26d-12h-51m-57s UTC integration manifest
> b85d9d7 drm/i915: Fix comments about GMBUSFREQ register
> f897835 drm/i915: Use cached cdclk value in 
> i915_audio_component_get_cdclk_freq()
> 4e443d4 drm/i915: Update CDCLK_FREQ register on BDW after changing cdclk 
> frequency

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

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915/bxt: Adjusting the error in horizontal timings retrieval

[Ville Syrjälä]

On Tue, Apr 19, 2016 at 01:48:14PM +0530, Ramalingam C wrote:
> In BXT DSI there is no regs programmed with few horizontal timings
> in Pixels but txbyteclkhs.. So retrieval process adds some
> ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs.
> 
> Actually here for the given adjusted_mode, we are calculating the
> value programmed to the port and then back to the horizontal timing
> param in pixels. This is the expected value at the end of get_config,
> including roundup errors. And if that is same as retrieved value
> from port, then retrieved (HW state) adjusted_mode's horizontal
> timings are corrected to match with SW state to nullify the errors.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c |   97 
> ++
>  1 file changed, 88 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index e0259e6..8a1b872 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -46,6 +46,14 @@ static const struct {
>   },
>  };
>  
> +/* return pixels in terms of txbyteclkhs */
> +static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
> +u16 burst_mode_ratio)
> +{
> + return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
> +  8 * 100), lane_count);
> +}
> +
>  /* return pixels equvalent to txbyteclkhs */
>  static u16 pixels_from_txbyteclkhs(u16 clk_hs, int bpp, int lane_count,
>   u16 burst_mode_ratio)
> @@ -779,11 +787,19 @@ static void bxt_dsi_get_pipe_config(struct 
> intel_encoder *encoder,
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_display_mode *adjusted_mode =
>   _config->base.adjusted_mode;
> + struct drm_display_mode *adjusted_mode_sw;
> + struct intel_crtc *intel_crtc;
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
>   unsigned int lane_count = intel_dsi->lane_count;
>   unsigned int bpp, fmt;
>   enum port port;
>   u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
> + u16 hfp_sw, hsync_sw, hbp_sw;
> + u16 crtc_htotal_sw, crtc_hsync_start_sw, crtc_hsync_end_sw,
> + crtc_hblank_start_sw, crtc_hblank_end_sw;
> +
> + intel_crtc = to_intel_crtc(encoder->base.crtc);
> + adjusted_mode_sw = _crtc->config->base.adjusted_mode;
>
 
>   /*
>* Atleast one port is active as encoder->get_config called only if
> @@ -847,8 +863,79 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder 
> *encoder,
>   adjusted_mode->crtc_vsync_end = vsync + adjusted_mode->crtc_vsync_start;
>   adjusted_mode->crtc_vblank_start = adjusted_mode->crtc_vdisplay;
>   adjusted_mode->crtc_vblank_end = adjusted_mode->crtc_vtotal;
> -}
>  
> + /*
> +  * In BXT DSI there is no regs programmed with few horizontal timings
> +  * in Pixels but txbyteclkhs.. So retrieval process adds some
> +  * ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs.
> +  * Actually here for the given adjusted_mode, we are calculating the
> +  * value programmed to the port and then back to the horizontal timing
> +  * param in pixels. This is the expected value, including roundup errors
> +  * And if that is same as retrieved value from port, then
> +  * (HW state) adjusted_mode's horizontal timings are corrected to
> +  * match with SW state to nullify the errors.
> +  */
> + /* Calculating the value programmed to the Port register */
> + hfp_sw = adjusted_mode_sw->crtc_hsync_start -
> + adjusted_mode_sw->crtc_hdisplay;
> + hsync_sw = adjusted_mode_sw->crtc_hsync_end -
> + adjusted_mode_sw->crtc_hsync_start;
> + hbp_sw = adjusted_mode_sw->crtc_htotal -
> + adjusted_mode_sw->crtc_hsync_end;

So during the initial state readout we get passed crtc->config as
pipe_config, and so we'll end up comparing the thing with itself. That
should be fine. A bit of extra care is needed to make sure we don't use
anything from crtc->config before we've filled it out with something,
but looks like the code does things in the right order (given the
previous patch which fills out all the htimings with something).

I think the biggest issue with this patch is seeing the forest from the
trees. Some refactoring would be good so that we'd have some kind of
htimings_{to,from}_txbyteclkhs() functions instead of duplicating the
same code multiple times.

So while it does look quite strange to be using crtc->config in the
.get_config() I think it should work out.

Acked-by: Ville Syrjälä 

> +
> + if (intel_dsi->dual_link) {
> + hfp_sw /= 2;
> + hsync_sw /= 2;
> + hbp_sw /= 2;
> + }

Re: [Intel-gfx] [PATCH 07/12] drm/rcar-du: Rename async to nonblock.

[Laurent Pinchart]

Hi Maarten,

Thank you for the patch.

On Tuesday 26 Apr 2016 16:11:40 Maarten Lankhorst wrote:
> The async name is deprecated and should be changed to nonblocking.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Maarten Lankhorst 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 24725bf859b4..e70a4f33d970
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -283,7 +283,8 @@ static void rcar_du_atomic_work(struct work_struct
> *work) }
> 
>  static int rcar_du_atomic_commit(struct drm_device *dev,
> -  struct drm_atomic_state *state, bool async)
> +  struct drm_atomic_state *state,
> +  bool nonblock)
>  {
>   struct rcar_du_device *rcdu = dev->dev_private;
>   struct rcar_du_commit *commit;
> @@ -328,7 +329,7 @@ static int rcar_du_atomic_commit(struct drm_device *dev,
> /* Swap the state, this is the point of no return. */
>   drm_atomic_helper_swap_state(dev, state);
> 
> - if (async)
> + if (nonblock)
>   schedule_work(>work);
>   else
>   rcar_du_atomic_complete(commit);

-- 
Regards,

Laurent Pinchart

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/BXT: Retrieving the horizontal timing for DSI

[Imre Deak]

On ti, 2016-04-19 at 13:48 +0530, Ramalingam C wrote:
> Retriving the horizontal timings from the port registers as
> part of get_config()
> 
> Signed-off-by: Ramalingam C 

I saw the crash below with current -nightly on a BXT-M board and Jani
pointed me to these two patches which get rid of it, so
Acked-by: Imre Deak 

[   56.916557] divide error:  [#1] PREEMPT SMP 
[   56.921741] Modules linked in: i915(+) drm_kms_helper syscopyarea 
sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart cf
g80211 rfkill binfmt_misc ax88179_178a kvm_intel kvm irqbypass crc32c_intel 
efivars tpm_tis tpm fuse
[   56.944106] CPU: 3 PID: 1097 Comm: modprobe Not tainted 4.6.0-rc4+ #433
[   56.951501] Hardware name: Intel Corp. Broxton M/RVP, BIOS 
BXT1RVPA.X64.0131.B30.1604142217 04/14/2016
[   56.961908] task: 88007a854d00 ti: 88007aea task.ti: 
88007aea
[   56.970273] RIP: 0010:[]  [] 
drm_mode_hsync+0x22/0x40 [drm]
[   56.980043] RSP: 0018:88007aea3788  EFLAGS: 00010206
[   56.985982] RAX: 0788b600 RBX: 880073c22108 RCX: 
[   56.993957] RDX:  RSI: 88007ab06800 RDI: 880073c22108
[   57.001935] RBP: 88007aea3788 R08: 0001 R09: 880073c221e8
[   57.009903] R10: 880073c22108 R11: 0001 R12: 88007a30
[   57.017872] R13: 880073c22000 R14: 880175f78000 R15: 880175f78798
[   57.025849] FS:  7f105d3e6700() GS:88017fd8() 
knlGS:
[   57.034894] CS:  0010 DS:  ES:  CR0: 80050033
[   57.041317] CR2: 7f4d485101d0 CR3: 7a82 CR4: 003406e0
[   57.049292] Stack:
[   57.051539]  88007aea37a0 a043b632 880175f787c8 
88007aea3810
[   57.059825]  a043d59e 880175f787b0 88007ab68c00 
88007aea37f0
[   57.068128]  880073c221e8 880073c22108 880175f78780 
8801
[   57.076430] Call Trace:
[   57.079254]  [] intel_mode_from_pipe_config+0x82/0xb0 
[i915]
[   57.087405]  [] intel_modeset_setup_hw_state+0x55e/0xd60 
[i915]
[   57.095847]  [] intel_modeset_init+0x8e4/0x1630 [i915]
[   57.103415]  [] i915_driver_load+0xbe0/0x1980 [i915]
[   57.110745]  [] drm_dev_register+0xa9/0xc0 [drm]
[   57.117681]  [] drm_get_pci_dev+0x8d/0x1e0 [drm]
[   57.124600]  [] ? _raw_spin_unlock_irqrestore+0x42/0x70
[   57.132253]  [] i915_pci_probe+0x34/0x50 [i915]
[   57.139070]  [] local_pci_probe+0x45/0xa0
[   57.145303]  [] ? pci_match_device+0xe0/0x110
[   57.151924]  [] pci_device_probe+0xdb/0x130
[   57.158355]  [] driver_probe_device+0x223/0x440
[   57.165169]  [] __driver_attach+0xd5/0x100
[   57.171500]  [] ? driver_probe_device+0x440/0x440
[   57.178510]  [] bus_for_each_dev+0x66/0xa0
[   57.184841]  [] driver_attach+0x1e/0x20
[   57.190881]  [] bus_add_driver+0x1ee/0x280
[   57.197212]  [] driver_register+0x60/0xe0
[   57.203447]  [] __pci_register_driver+0x60/0x70
[   57.210285]  [] drm_pci_init+0xe0/0x110 [drm]
[   57.216911]  [] ? trace_hardirqs_on+0xd/0x10
[   57.223434]  [] ? 0xa023a000
[   57.229237]  [] i915_init+0x92/0x99 [i915]
[   57.235570]  [] do_one_initcall+0xab/0x1d0
[   57.241900]  [] ? rcu_read_lock_sched_held+0x7f/0x90
[   57.249205]  [] ? kmem_cache_alloc_trace+0x248/0x2b0
[   57.256509]  [] ? do_init_module+0x27/0x1d9
[   57.262934]  [] do_init_module+0x5f/0x1d9
[   57.269167]  [] load_module+0x20ef/0x27b0
[   57.275401]  [] ? store_uevent+0x40/0x40
[   57.281541]  [] SYSC_finit_module+0xc3/0xf0
[   57.287969]  [] SyS_finit_module+0xe/0x10
[   57.294203]  [] entry_SYSCALL_64_fastpath+0x1c/0xac
[   57.301406] Code: ff 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 8b 87 d8 00 00 
00 55 48 89 e5 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99  f9 
b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 5d c3 
[   57.322964] RIP  [] drm_mode_hsync+0x22/0x40 [drm]
[   57.330103]  RSP 
[   57.334276] ---[ end trace d414224cb2e2a4cf ]---
[   57.339861] modprobe (1097) used greatest stack depth: 12048 bytes left

> ---
>  drivers/gpu/drm/i915/intel_dsi.c |   44 
> --
>  1 file changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 9ff6435..e0259e6 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -46,6 +46,14 @@ static const struct {
>   },
>  };
>  
> +/* return pixels equvalent to txbyteclkhs */
> +static u16 pixels_from_txbyteclkhs(u16 clk_hs, int bpp, int lane_count,
> + u16 burst_mode_ratio)
> +{
> + return DIV_ROUND_UP((clk_hs * lane_count * 8 * 100),
> + (bpp * burst_mode_ratio));
> +}
> +
>  enum mipi_dsi_pixel_format pixel_format_from_register_bits(u32 fmt)
>  {
>   /* It just so happens the VBT matches register contents. */
> @@ -772,9 +780,10 @@ static void bxt_dsi_get_pipe_config(struct 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

[Patchwork]

== Series Details ==

Series: drm/i915: respect VBT PSR link standby configuration for HSW/BDW.
URL   : https://patchwork.freedesktop.org/series/6416/
State : success

== Summary ==

Series 6416v1 drm/i915: respect VBT PSR link standby configuration for HSW/BDW.
http://patchwork.freedesktop.org/api/1.0/series/6416/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (bdw-nuci7)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (bdw-ultra)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
dmesg-warn -> PASS   (snb-dellxps)

bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:200  pass:178  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:200  pass:139  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:200  pass:169  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:200  pass:158  dwarn:0   dfail:0   fail:0   skip:42 
snb-x220ttotal:200  pass:158  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/Patchwork_2094/

e6c43160f35ad64114e1156e3f995e5dabe74835 drm-intel-nightly: 
2016y-04m-27d-13h-17m-05s UTC integration manifest
adbbc5d drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

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

Re: [Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

[Vivi, Rodrigo]

On Wed, 2016-04-27 at 19:08 +0300, Ville Syrjälä wrote:
> On Wed, Apr 27, 2016 at 03:54:12PM +, Vivi, Rodrigo wrote:
> > On Wed, 2016-04-27 at 17:43 +0300, ville.syrj...@linux.intel.com wr
> > ote:
> > > From: Ville Syrjälä 
> > > 
> > > I just noticed that VLV/CHV have a RAWCLK_FREQ register just like
> > > PCH
> > > platforms. It lives in the display power well, so we should
> > > update it
> > > when enabling the power well.
> > > 
> > > Interestingly the BIOS seems to leave it at the reset value (125)
> > > which
> > > doesn't match the rawclk frequency on VLV/CHV (200 MHz). As
> > > always
> > > with
> > > these register, the spec is extremely vague what the register
> > > does.
> > > All
> > > it says is: "This is used to generate a divided down clock for
> > > miscellaneous timers in display." Based on a quick test, at least
> > > AUX
> > > and PWM appear to be unaffected by this.
> > > 
> > > But since the register is there, let's configure it in accordance
> > > with
> > > the spec.
> > > 
> > > Note that we have to move intel_update_rawclk() to occur before
> > > we
> > > touch the power wells, so that the dev_priv->rawclk_freq is
> > > already
> > > populated when the disp2 enable hook gets called for the first
> > > time.
> > > I think this should be safe to do on other platforms as well.
> > > 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/i915_dma.c | 3 +++
> > >  drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > >  drivers/gpu/drm/i915/intel_display.c| 4 ++--
> > >  drivers/gpu/drm/i915/intel_drv.h| 1 +
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
> > >  5 files changed, 13 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > b/drivers/gpu/drm/i915/i915_dma.c
> > > index 5c7615041b31..fd1260d2b6ec 100644
> > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > @@ -454,6 +454,9 @@ static int i915_load_modeset_init(struct
> > > drm_device *dev)
> > >   if (ret)
> > >   goto cleanup_vga_client;
> > >  
> > > + /* must happen before intel_power_domains_init_hw() on
> > > VLV/CHV */
> > > + intel_update_rawclk(dev_priv);
> > 
> > separated patches since this affects all platforms?!
> 
> I was going to do that originally, but then I thought that if we have
> to
> revert due to some other platform, it's likely VLV/CHV would be
> forgotten and only later someone would start to complain about the
> WARN_ON() I added. So if this change needs to reverted, the VLV/CHV
> stuff
> needs to be redone anyway, so having it in the same commit seems like
> the slightly better option to me.

oh! makes a lot of sense indeed!

> 
> > 
> > anyways I checked CHV spec here so feel free to ignore me and use
> > Reviewed-by: Rodrigo Vivi 
> > 
> > 
> > > +
> > >   intel_power_domains_init_hw(dev_priv, false);
> > >  
> > >   intel_csr_ucode_init(dev_priv);
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 25e229b609a7..0a2fd3000f94 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -2449,6 +2449,8 @@ enum skl_disp_power_wells {
> > >  #define   DPLL_MD_VGA_UDI_MULTIPLIER_MASK0x003f
> > >  #define   DPLL_MD_VGA_UDI_MULTIPLIER_SHIFT   0
> > >  
> > > +#define RAWCLK_FREQ_VLV  _MMIO(VLV_DISPLAY_BASE +
> > > 0x6024)
> > > +
> > >  #define _FPA00x6040
> > >  #define _FPA10x6044
> > >  #define _FPB00x6048
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index b7cb632a2a31..eb7cb9431209 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -185,6 +185,7 @@ intel_pch_rawclk(struct drm_i915_private
> > > *dev_priv)
> > >  static int
> > >  intel_vlv_hrawclk(struct drm_i915_private *dev_priv)
> > >  {
> > > + /* RAWCLK_FREQ_VLV register updated from power well code
> > > */
> > >   return vlv_get_cck_clock_hpll(dev_priv, "hrawclk",
> > >
> > >  CCK_DISPLAY_REF_CLOCK_CONTROL);
> > >  }
> > > @@ -218,7 +219,7 @@ intel_g4x_hrawclk(struct drm_i915_private
> > > *dev_priv)
> > >   }
> > >  }
> > >  
> > > -static void intel_update_rawclk(struct drm_i915_private
> > > *dev_priv)
> > > +void intel_update_rawclk(struct drm_i915_private *dev_priv)
> > >  {
> > >   if (HAS_PCH_SPLIT(dev_priv))
> > >   dev_priv->rawclk_freq =
> > > intel_pch_rawclk(dev_priv);
> > > @@ -15455,7 +15456,6 @@ void intel_modeset_init(struct drm_device
> > > *dev)
> > >   }
> > >  
> > >   intel_update_czclk(dev_priv);
> > > - intel_update_rawclk(dev_priv);
> > >   intel_update_cdclk(dev);
> > >  
> > >   intel_shared_dpll_init(dev);
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> 

Re: [Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 03:54:12PM +, Vivi, Rodrigo wrote:
> On Wed, 2016-04-27 at 17:43 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > I just noticed that VLV/CHV have a RAWCLK_FREQ register just like PCH
> > platforms. It lives in the display power well, so we should update it
> > when enabling the power well.
> > 
> > Interestingly the BIOS seems to leave it at the reset value (125)
> > which
> > doesn't match the rawclk frequency on VLV/CHV (200 MHz). As always
> > with
> > these register, the spec is extremely vague what the register does.
> > All
> > it says is: "This is used to generate a divided down clock for
> > miscellaneous timers in display." Based on a quick test, at least AUX
> > and PWM appear to be unaffected by this.
> > 
> > But since the register is there, let's configure it in accordance
> > with
> > the spec.
> > 
> > Note that we have to move intel_update_rawclk() to occur before we
> > touch the power wells, so that the dev_priv->rawclk_freq is already
> > populated when the disp2 enable hook gets called for the first time.
> > I think this should be safe to do on other platforms as well.
> > 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_dma.c | 3 +++
> >  drivers/gpu/drm/i915/i915_reg.h | 2 ++
> >  drivers/gpu/drm/i915/intel_display.c| 4 ++--
> >  drivers/gpu/drm/i915/intel_drv.h| 1 +
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
> >  5 files changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 5c7615041b31..fd1260d2b6ec 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -454,6 +454,9 @@ static int i915_load_modeset_init(struct
> > drm_device *dev)
> > if (ret)
> > goto cleanup_vga_client;
> >  
> > +   /* must happen before intel_power_domains_init_hw() on
> > VLV/CHV */
> > +   intel_update_rawclk(dev_priv);
> 
> separated patches since this affects all platforms?!

I was going to do that originally, but then I thought that if we have to
revert due to some other platform, it's likely VLV/CHV would be
forgotten and only later someone would start to complain about the
WARN_ON() I added. So if this change needs to reverted, the VLV/CHV stuff
needs to be redone anyway, so having it in the same commit seems like
the slightly better option to me.

> 
> anyways I checked CHV spec here so feel free to ignore me and use
> Reviewed-by: Rodrigo Vivi 
> 
> 
> > +
> > intel_power_domains_init_hw(dev_priv, false);
> >  
> > intel_csr_ucode_init(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 25e229b609a7..0a2fd3000f94 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2449,6 +2449,8 @@ enum skl_disp_power_wells {
> >  #define   DPLL_MD_VGA_UDI_MULTIPLIER_MASK  0x003f
> >  #define   DPLL_MD_VGA_UDI_MULTIPLIER_SHIFT 0
> >  
> > +#define RAWCLK_FREQ_VLV_MMIO(VLV_DISPLAY_BASE +
> > 0x6024)
> > +
> >  #define _FPA0  0x6040
> >  #define _FPA1  0x6044
> >  #define _FPB0  0x6048
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index b7cb632a2a31..eb7cb9431209 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -185,6 +185,7 @@ intel_pch_rawclk(struct drm_i915_private
> > *dev_priv)
> >  static int
> >  intel_vlv_hrawclk(struct drm_i915_private *dev_priv)
> >  {
> > +   /* RAWCLK_FREQ_VLV register updated from power well code */
> > return vlv_get_cck_clock_hpll(dev_priv, "hrawclk",
> >  
> >  CCK_DISPLAY_REF_CLOCK_CONTROL);
> >  }
> > @@ -218,7 +219,7 @@ intel_g4x_hrawclk(struct drm_i915_private
> > *dev_priv)
> > }
> >  }
> >  
> > -static void intel_update_rawclk(struct drm_i915_private *dev_priv)
> > +void intel_update_rawclk(struct drm_i915_private *dev_priv)
> >  {
> > if (HAS_PCH_SPLIT(dev_priv))
> > dev_priv->rawclk_freq = intel_pch_rawclk(dev_priv);
> > @@ -15455,7 +15456,6 @@ void intel_modeset_init(struct drm_device
> > *dev)
> > }
> >  
> > intel_update_czclk(dev_priv);
> > -   intel_update_rawclk(dev_priv);
> > intel_update_cdclk(dev);
> >  
> > intel_shared_dpll_init(dev);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index cb89a35a6755..ce78afefe3cd 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1110,6 +1110,7 @@ void i915_audio_component_init(struct
> > drm_i915_private *dev_priv);
> >  void i915_audio_component_cleanup(struct drm_i915_private
> > *dev_priv);
> >  
> >  /* intel_display.c 

Re: [Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

[Vivi, Rodrigo]

On Wed, 2016-04-27 at 17:43 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> I just noticed that VLV/CHV have a RAWCLK_FREQ register just like PCH
> platforms. It lives in the display power well, so we should update it
> when enabling the power well.
> 
> Interestingly the BIOS seems to leave it at the reset value (125)
> which
> doesn't match the rawclk frequency on VLV/CHV (200 MHz). As always
> with
> these register, the spec is extremely vague what the register does.
> All
> it says is: "This is used to generate a divided down clock for
> miscellaneous timers in display." Based on a quick test, at least AUX
> and PWM appear to be unaffected by this.
> 
> But since the register is there, let's configure it in accordance
> with
> the spec.
> 
> Note that we have to move intel_update_rawclk() to occur before we
> touch the power wells, so that the dev_priv->rawclk_freq is already
> populated when the disp2 enable hook gets called for the first time.
> I think this should be safe to do on other platforms as well.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 3 +++
>  drivers/gpu/drm/i915/i915_reg.h | 2 ++
>  drivers/gpu/drm/i915/intel_display.c| 4 ++--
>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
>  5 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> b/drivers/gpu/drm/i915/i915_dma.c
> index 5c7615041b31..fd1260d2b6ec 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -454,6 +454,9 @@ static int i915_load_modeset_init(struct
> drm_device *dev)
>   if (ret)
>   goto cleanup_vga_client;
>  
> + /* must happen before intel_power_domains_init_hw() on
> VLV/CHV */
> + intel_update_rawclk(dev_priv);

separated patches since this affects all platforms?!

anyways I checked CHV spec here so feel free to ignore me and use
Reviewed-by: Rodrigo Vivi 


> +
>   intel_power_domains_init_hw(dev_priv, false);
>  
>   intel_csr_ucode_init(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 25e229b609a7..0a2fd3000f94 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2449,6 +2449,8 @@ enum skl_disp_power_wells {
>  #define   DPLL_MD_VGA_UDI_MULTIPLIER_MASK0x003f
>  #define   DPLL_MD_VGA_UDI_MULTIPLIER_SHIFT   0
>  
> +#define RAWCLK_FREQ_VLV  _MMIO(VLV_DISPLAY_BASE +
> 0x6024)
> +
>  #define _FPA00x6040
>  #define _FPA10x6044
>  #define _FPB00x6048
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b7cb632a2a31..eb7cb9431209 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -185,6 +185,7 @@ intel_pch_rawclk(struct drm_i915_private
> *dev_priv)
>  static int
>  intel_vlv_hrawclk(struct drm_i915_private *dev_priv)
>  {
> + /* RAWCLK_FREQ_VLV register updated from power well code */
>   return vlv_get_cck_clock_hpll(dev_priv, "hrawclk",
>
>  CCK_DISPLAY_REF_CLOCK_CONTROL);
>  }
> @@ -218,7 +219,7 @@ intel_g4x_hrawclk(struct drm_i915_private
> *dev_priv)
>   }
>  }
>  
> -static void intel_update_rawclk(struct drm_i915_private *dev_priv)
> +void intel_update_rawclk(struct drm_i915_private *dev_priv)
>  {
>   if (HAS_PCH_SPLIT(dev_priv))
>   dev_priv->rawclk_freq = intel_pch_rawclk(dev_priv);
> @@ -15455,7 +15456,6 @@ void intel_modeset_init(struct drm_device
> *dev)
>   }
>  
>   intel_update_czclk(dev_priv);
> - intel_update_rawclk(dev_priv);
>   intel_update_cdclk(dev);
>  
>   intel_shared_dpll_init(dev);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index cb89a35a6755..ce78afefe3cd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1110,6 +1110,7 @@ void i915_audio_component_init(struct
> drm_i915_private *dev_priv);
>  void i915_audio_component_cleanup(struct drm_i915_private
> *dev_priv);
>  
>  /* intel_display.c */
> +void intel_update_rawclk(struct drm_i915_private *dev_priv);
>  int vlv_get_cck_clock(struct drm_i915_private *dev_priv,
> const char *name, u32 reg, int ref_freq);
>  extern const struct drm_plane_funcs intel_plane_funcs;
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 7fb1da4e7fc3..b69b935516fb 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -948,6 +948,11 @@ static void vlv_init_display_clock_gating(struct
> drm_i915_private *dev_priv)
>*/
>   I915_WRITE(MI_ARB_VLV, 

Re: [Intel-gfx] [PATCH] drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

[Chris Wilson]

On Wed, Apr 27, 2016 at 08:47:54AM -0700, Rodrigo Vivi wrote:
> We have in the history some changes on this behaviour, but
> there are many platforms out there and we don't know all panels.
> 
> VBT might not be reliable but it knows the platform better than
> us usually. Or at least it should.
> So, first of all let's respect the VBT. If something bad happens
> again with one platform or another it is better to create a
> quirk than to bypass the VBT.
> 
> Cc: Mihai Dontu 
> Cc: Jani Nikula 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3abae4..e65e2c3 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -788,14 +788,11 @@ void intel_psr_init(struct drm_device *dev)
>   }
>  
>   /* Set link_standby x link_off defaults */
> - if (IS_HASWELL(dev) || IS_BROADWELL(dev))
> - /* HSW and BDW require workarounds that we don't implement. */
> - dev_priv->psr.link_standby = false;

This patch has nothing to do with respecting the VBT or not, it's about
whether the comment that we still require w/a is valid or not.

That's not even mentioned in the changelog.
-Chris

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

[Intel-gfx] [PATCH] drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

[Rodrigo Vivi]

We have in the history some changes on this behaviour, but
there are many platforms out there and we don't know all panels.

VBT might not be reliable but it knows the platform better than
us usually. Or at least it should.
So, first of all let's respect the VBT. If something bad happens
again with one platform or another it is better to create a
quirk than to bypass the VBT.

Cc: Mihai Dontu 
Cc: Jani Nikula 
Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3abae4..e65e2c3 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -788,14 +788,11 @@ void intel_psr_init(struct drm_device *dev)
}
 
/* Set link_standby x link_off defaults */
-   if (IS_HASWELL(dev) || IS_BROADWELL(dev))
-   /* HSW and BDW require workarounds that we don't implement. */
-   dev_priv->psr.link_standby = false;
else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
/* On VLV and CHV only standby mode is supported. */
dev_priv->psr.link_standby = true;
else
-   /* For new platforms let's respect VBT back again */
+   /* For other platforms let's respect VBT back again */
dev_priv->psr.link_standby = dev_priv->vbt.psr.full_link;
 
/* Override link_standby x link_off defaults */
-- 
2.4.3

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 03:02:01PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable
> URL   : https://patchwork.freedesktop.org/series/5886/
> State : warning
> 
> == Summary ==
> 
> Series 5886v1 drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable
> http://patchwork.freedesktop.org/api/1.0/series/5886/revisions/1/mbox/
> 
> Test kms_force_connector_basic:
> Subgroup force-load-detect:
> skip   -> PASS   (snb-x220t)
> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-a:
> pass   -> DMESG-WARN (snb-dellxps)

[  345.841921] [ cut here ]
[  345.841947] WARNING: CPU: 1 PID: 6167 at 
drivers/gpu/drm/i915/intel_display.c:13529 intel_atomic_commit+0x1271/0x1400 
[i915]
[  345.841948] pipe A vblank wait timed out
[  345.841950] Modules linked in: smsc75xx usbnet mii snd_hda_codec_hdmi 
snd_hda_codec_realtek x86_pkg_temp_thermal snd_hda_codec_generic 
intel_powerclamp coretemp crct10dif_pclmul i915 crc32_pclmul 
ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core mei_me 
snd_pcm mei lpc_ich
[  345.841964] CPU: 1 PID: 6167 Comm: kms_pipe_crc_ba Tainted: G U  
4.6.0-rc4-CI-Patchwork_1933+ #1
[  345.841965] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
[  345.841967]   8800bfe77b28 81405e35 
8800bfe77b78
[  345.841970]   8800bfe77b68 81079c7c 
34d9c0c84520
[  345.841972]  0001 8801299722a8  

[  345.841974] Call Trace:
[  345.841978]  [] dump_stack+0x67/0x92
[  345.841981]  [] __warn+0xcc/0xf0
[  345.841983]  [] warn_slowpath_fmt+0x4a/0x50
[  345.841986]  [] ? finish_wait+0x59/0x70
[  345.842001]  [] intel_atomic_commit+0x1271/0x1400 [i915]
[  345.842003]  [] ? wait_woken+0x90/0x90
[  345.842005]  [] drm_atomic_commit+0x32/0x50
[  345.842007]  [] drm_atomic_helper_set_config+0x7d/0xb0
[  345.842010]  [] drm_mode_set_config_internal+0x60/0x110
[  345.842011]  [] drm_mode_setcrtc+0x186/0x4f0
[  345.842013]  [] drm_ioctl+0x13d/0x590
[  345.842014]  [] ? drm_mode_setplane+0x1b0/0x1b0
[  345.842016]  [] do_vfs_ioctl+0x8a/0x670
[  345.842018]  [] ? __fget_light+0x6a/0x90
[  345.842020]  [] SyS_ioctl+0x3c/0x70
[  345.842022]  [] entry_SYSCALL_64_fastpath+0x1c/0xac
[  345.842023] ---[ end trace caa7340649a55fcb ]---
[  354.764853] drm/i915: Resetting chip after gpu hang

https://bugs.freedesktop.org/show_bug.cgi?id=95125

> 
> bdw-nuci7total:192  pass:180  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
> bsw-nuc-2total:191  pass:152  dwarn:0   dfail:0   fail:0   skip:39 
> hsw-brixbox  total:192  pass:168  dwarn:0   dfail:0   fail:0   skip:24 
> ivb-t430stotal:192  pass:164  dwarn:0   dfail:0   fail:0   skip:28 
> skl-i7k-2total:192  pass:167  dwarn:0   dfail:0   fail:0   skip:25 
> skl-nuci5total:192  pass:181  dwarn:0   dfail:0   fail:0   skip:11 
> snb-dellxps  total:192  pass:153  dwarn:1   dfail:0   fail:0   skip:38 
> snb-x220ttotal:192  pass:154  dwarn:0   dfail:0   fail:1   skip:37 
> byt-nuc failed to collect. IGT log at Patchwork_1933/byt-nuc/igt.log
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1933/
> 
> b1b2678f7bf90de8cecba84acb8f8c967a5f5d80 drm-intel-nightly: 
> 2016y-04m-18d-17h-17m-00s UTC integration manifest
> ce15fac drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update RAWCLK_FREQ register on VLV/CHV

[Patchwork]

== Series Details ==

Series: drm/i915: Update RAWCLK_FREQ register on VLV/CHV
URL   : https://patchwork.freedesktop.org/series/6410/
State : success

== Summary ==

Series 6410v1 drm/i915: Update RAWCLK_FREQ register on VLV/CHV
http://patchwork.freedesktop.org/api/1.0/series/6410/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (bdw-nuci7)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (bdw-ultra)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
dmesg-warn -> PASS   (snb-dellxps)

bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:200  pass:178  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:200  pass:139  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:200  pass:169  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:200  pass:158  dwarn:0   dfail:0   fail:0   skip:42 
snb-x220ttotal:200  pass:158  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/Patchwork_2093/

e6c43160f35ad64114e1156e3f995e5dabe74835 drm-intel-nightly: 
2016y-04m-27d-13h-17m-05s UTC integration manifest
db80506 drm/i915: Update RAWCLK_FREQ register on VLV/CHV

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

[Intel-gfx] [PATCH i-g-t 3/3] kms_flip: Reduce dmesg spam by not calling drmModeGetResources too much

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Configuration reported in drmModeGetResources is static - pass it
into kmstest_get_connector_config so it can be reused there.

Signed-off-by: Tvrtko Ursulin 
---
 tests/kms_flip.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index fec69254e4da..a85153fa3d52 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1042,7 +1042,7 @@ static void connector_find_preferred_mode(uint32_t 
connector_id, int crtc_idx,
 {
struct kmstest_connector_config config;
 
-   if (!kmstest_get_connector_config(drm_fd, NULL,
+   if (!kmstest_get_connector_config(drm_fd, resources,
  connector_id, 1 << crtc_idx,
  )) {
o->mode_valid = 0;
@@ -1087,11 +1087,11 @@ static void connector_find_compatible_mode(int 
crtc_idx0, int crtc_idx1,
drmModeModeInfo *mode[2];
int n, m;
 
-   if (!kmstest_get_connector_config(drm_fd, NULL, o->_connector[0],
+   if (!kmstest_get_connector_config(drm_fd, resources, o->_connector[0],
  1 << crtc_idx0, [0]))
return;
 
-   if (!kmstest_get_connector_config(drm_fd, NULL, o->_connector[1],
+   if (!kmstest_get_connector_config(drm_fd, resources, o->_connector[1],
  1 << crtc_idx1, [1])) {
kmstest_free_connector_config([0]);
return;
-- 
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 2/3] igt_kms: Allow kmstest_get_connector_config to take provided drmModeGetResources

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

This will enable the following patch to generate less dmesg spam.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_kms.c   | 33 +++--
 lib/igt_kms.h   |  3 ++-
 tests/kms_3d.c  |  2 +-
 tests/kms_flip.c|  7 ---
 tests/kms_render.c  |  5 +++--
 tests/testdisplay.c |  2 +-
 6 files changed, 34 insertions(+), 18 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7557bdc20fa4..07f523e2c39b 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -749,6 +749,7 @@ bool kmstest_get_connector_default_mode(int drm_fd, 
drmModeConnector *connector,
 /**
  * _kmstest_connector_config:
  * @drm_fd: DRM fd
+ * @resources: pointer to drmModeRes or NULL
  * @connector_id: DRM connector id
  * @crtc_idx_mask: mask of allowed DRM CRTC indices
  * @config: structure filled with the possible configuration
@@ -757,17 +758,24 @@ bool kmstest_get_connector_default_mode(int drm_fd, 
drmModeConnector *connector,
  * This tries to find a suitable configuration for the given connector and CRTC
  * constraint and fills it into @config.
  */
-static bool _kmstest_connector_config(int drm_fd, uint32_t connector_id,
+static bool _kmstest_connector_config(int drm_fd, drmModeRes *resources,
+ uint32_t connector_id,
  unsigned long crtc_idx_mask,
  struct kmstest_connector_config *config,
  bool probe)
 {
-   drmModeRes *resources;
drmModeConnector *connector;
drmModeEncoder *encoder;
+   bool free_resources;
int i, j;
 
-   resources = drmModeGetResources(drm_fd);
+   if (resources == NULL) {
+   resources = drmModeGetResources(drm_fd);
+   free_resources = true;
+   } else {
+   free_resources = false;
+   }
+
if (!resources) {
igt_warn("drmModeGetResources failed");
goto err1;
@@ -840,7 +848,8 @@ found:
config->pipe = kmstest_get_pipe_from_crtc_id(drm_fd,
 config->crtc->crtc_id);
 
-   drmModeFreeResources(resources);
+   if (free_resources)
+   drmModeFreeResources(resources);
 
return true;
 err4:
@@ -848,7 +857,8 @@ err4:
 err3:
drmModeFreeConnector(connector);
 err2:
-   drmModeFreeResources(resources);
+   if (free_resources)
+   drmModeFreeResources(resources);
 err1:
return false;
 }
@@ -856,6 +866,7 @@ err1:
 /**
  * kmstest_get_connector_config:
  * @drm_fd: DRM fd
+ * @resources: pointer to drmModeRes or NULL
  * @connector_id: DRM connector id
  * @crtc_idx_mask: mask of allowed DRM CRTC indices
  * @config: structure filled with the possible configuration
@@ -863,12 +874,13 @@ err1:
  * This tries to find a suitable configuration for the given connector and CRTC
  * constraint and fills it into @config.
  */
-bool kmstest_get_connector_config(int drm_fd, uint32_t connector_id,
+bool kmstest_get_connector_config(int drm_fd, drmModeRes *resources,
+ uint32_t connector_id,
  unsigned long crtc_idx_mask,
  struct kmstest_connector_config *config)
 {
-   return _kmstest_connector_config(drm_fd, connector_id, crtc_idx_mask,
-config, 0);
+   return _kmstest_connector_config(drm_fd, resources, connector_id,
+crtc_idx_mask, config, 0);
 }
 
 /**
@@ -886,8 +898,8 @@ bool kmstest_probe_connector_config(int drm_fd, uint32_t 
connector_id,
unsigned long crtc_idx_mask,
struct kmstest_connector_config *config)
 {
-   return _kmstest_connector_config(drm_fd, connector_id, crtc_idx_mask,
-config, 1);
+   return _kmstest_connector_config(drm_fd, NULL, connector_id,
+crtc_idx_mask, config, 1);
 }
 
 /**
@@ -1160,6 +1172,7 @@ static void igt_output_refresh(igt_output_t *output)
kmstest_free_connector_config(>config);
 
ret = kmstest_get_connector_config(display->drm_fd,
+  NULL,
   output->id,
   crtc_idx_mask,
   >config);
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 5c8340171ab6..8cbba1673d28 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -158,7 +158,8 @@ void kmstest_force_edid(int drm_fd, drmModeConnector 
*connector,
 
 bool kmstest_get_connector_default_mode(int drm_fd, drmModeConnector 
*connector,
drmModeModeInfo *mode);
-bool kmstest_get_connector_config(int 

[Intel-gfx] [PATCH i-g-t 1/3] igt_kms: Fix use after free in kmstest_get_pipe_from_crtc_id

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_kms.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index ef24a4965567..7557bdc20fa4 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -402,10 +402,10 @@ int kmstest_get_pipe_from_crtc_id(int fd, int crtc_id)
break;
}
 
-   drmModeFreeResources(res);
-
igt_assert(i < res->count_crtcs);
 
+   drmModeFreeResources(res);
+
return i;
 }
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

[Tomi Sarvela]

On Wednesday 27 April 2016 17:49:26 Ville Syrjälä wrote:
> On Mon, Apr 18, 2016 at 07:18:25PM +0300, ville.syrj...@linux.intel.com 
wrote:
> > From: Ville Syrjälä 
> > 
> > Check for VLV/CHV instead if !BXT when re-enabling DPOunit clock gating
> > after DSI disable. That's what we checked when disabling the clock
> > gating when enabling DSI.
> > 
> > Also use the same temporary variable name in both cases, and toss in a
> > bit of dev vs. dev_priv cleanup while at it.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Anyone know why this wasn't picked up by the .fi CI?

Was tested, but posting had failed. Retried.

> Tomi?

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Set legacy properties when using legacy gamma set IOCTL. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Set legacy properties when using legacy gamma set IOCTL. 
(rev2)
URL   : https://patchwork.freedesktop.org/series/5466/
State : failure

== Summary ==

  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
Makefile:538: recipe for target 'olddefconfig' failed
make: *** [olddefconfig] Terminated

Full logs at /archive/deploy/logs/CI_Patchwork_build_2092

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

[Patchwork]

== Series Details ==

Series: drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable
URL   : https://patchwork.freedesktop.org/series/5886/
State : warning

== Summary ==

Series 5886v1 drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable
http://patchwork.freedesktop.org/api/1.0/series/5886/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup force-load-detect:
skip   -> PASS   (snb-x220t)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (snb-dellxps)

bdw-nuci7total:192  pass:180  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:191  pass:152  dwarn:0   dfail:0   fail:0   skip:39 
hsw-brixbox  total:192  pass:168  dwarn:0   dfail:0   fail:0   skip:24 
ivb-t430stotal:192  pass:164  dwarn:0   dfail:0   fail:0   skip:28 
skl-i7k-2total:192  pass:167  dwarn:0   dfail:0   fail:0   skip:25 
skl-nuci5total:192  pass:181  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:192  pass:153  dwarn:1   dfail:0   fail:0   skip:38 
snb-x220ttotal:192  pass:154  dwarn:0   dfail:0   fail:1   skip:37 
byt-nuc failed to collect. IGT log at Patchwork_1933/byt-nuc/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_1933/

b1b2678f7bf90de8cecba84acb8f8c967a5f5d80 drm-intel-nightly: 
2016y-04m-18d-17h-17m-00s UTC integration manifest
ce15fac drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

[Chris Wilson]

On Wed, Apr 27, 2016 at 04:25:09PM +0300, Eero Tamminen wrote:
> Hi,
> 
> On 26.04.2016 20:25, Frederick, Michael T wrote:
> >Sorry I'm not tracking all the MOCs discussions.  I just want to indicate 
> >what the coherency means in SoC for BXT.
> >
> >GTI sets the non-inclusive bit on the IDI interface based on how it treats 
> >the memory.  In BXT case where there is no uncore cache, "non-inclusive" 
> >just indicates snoop or not.  BXT has a snoop filter in order to make the 
> >latency of snooping GT from a core roughly similar to snooping another core.
> >
> >For BXT:
> >If GTI sets non-inclusive=0 (i.e. coherent): transaction looks up in the SF 
> >and the SA snoops the cores.  The potential impact here is that for high BW 
> >coherent traffic, the SF will become the BW limiter of the system and cap BW 
> >at 33% * 34GBps. For writes like WCILFs snoops to cores must be resolved 
> >before SA requests WR data from GT.  For reads the common case should have 
> >no impact because snoop latency is generally much less than memory data 
> >latency.  In general snoop latency for a core is relatively small, but there 
> >is also the prospect that a core could be down (e.g. ratio change) or loaded 
> >w/ snooping.
> >If GTI sets non-inclusive=1 (i.e. non-coherent): transaction takes the SF 
> >bypass and the SA does not snoop the cores.  This is best for high-BW since 
> >it removes the SF bottleneck and doesn't require core interaction.
> 
> Thanks for the explanation!
> 
> AFAIK:
> 
> * In regards to 3D driver operations, CPU side doesn't modify the
> buffer contents while GPU is working on them.  CPU side sets up the
> buffers (textures, VBOs, batches etc), and then (after a flush) GPU
> is asked to act on them.
> 
> * For things like texture streaming, the driver either internally
> synchronizes the data or creates a new copy of it whenever
> application tells that data is updated.  There's always some kind of
> "upload" involved (GL API needs it as non-integrated GPU's don't
> share memory with CPU).
> 
> While it's possible that there's a case where snooping would be
> needed, I cannot think of any myself.
> 
> Daniel, Chris, did you have some concrete example in mind where 3D
> driver would require CPU to snoop GPU?

Not mesa, but X can do concurrent rendering to a Pixmap whilst also
rendering from other parts of that Pixmap into a GPU side buffer and
presentation/compositing thereof. X uses snooping both ways (from client
memory to GPU and from GPU to client memory) as well as mixed rendering.

Mesa should be using snooping for both SubTexImage and GetTexImage. On
the SubTexImage path you can use the sampler to do format conversions
that even including the sync overhead for correctness when using client
memory avoid the awful format conversion code in mesa. Using the GPU to
write into client memory and avoiding WC reads is approximately an
order of magnitude (8x) faster than the current code mesa uses.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

[Ville Syrjälä]

On Mon, Apr 18, 2016 at 07:18:25PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Check for VLV/CHV instead if !BXT when re-enabling DPOunit clock gating
> after DSI disable. That's what we checked when disabling the clock
> gating when enabling DSI.
> 
> Also use the same temporary variable name in both cases, and toss in a
> bit of dev vs. dev_priv cleanup while at it.
> 
> Signed-off-by: Ville Syrjälä 

Anyone know why this wasn't picked up by the .fi CI?
Tomi?

> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 34328ddaaab5..599045359538 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -516,7 +516,6 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> *encoder)
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
>   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
>   enum port port;
> - u32 tmp;
>  
>   DRM_DEBUG_KMS("\n");
>  
> @@ -535,11 +534,13 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> *encoder)
>  
>   msleep(intel_dsi->panel_on_delay);
>  
> - if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + u32 val;
> +
>   /* Disable DPOunit clock gating, can stall pipe */
> - tmp = I915_READ(DSPCLK_GATE_D);
> - tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
> - I915_WRITE(DSPCLK_GATE_D, tmp);
> + val = I915_READ(DSPCLK_GATE_D);
> + val |= DPOUNIT_CLOCK_GATE_DISABLE;
> + I915_WRITE(DSPCLK_GATE_D, val);
>   }
>  
>   /* put device in ready state */
> @@ -677,7 +678,7 @@ static void intel_dsi_post_disable(struct intel_encoder 
> *encoder)
>  
>   intel_dsi_clear_device_ready(encoder);
>  
> - if (!IS_BROXTON(dev_priv)) {
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>   u32 val;
>  
>   val = I915_READ(DSPCLK_GATE_D);
> -- 
> 2.7.4

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

[Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

[ville . syrjala]

From: Ville Syrjälä 

I just noticed that VLV/CHV have a RAWCLK_FREQ register just like PCH
platforms. It lives in the display power well, so we should update it
when enabling the power well.

Interestingly the BIOS seems to leave it at the reset value (125) which
doesn't match the rawclk frequency on VLV/CHV (200 MHz). As always with
these register, the spec is extremely vague what the register does. All
it says is: "This is used to generate a divided down clock for
miscellaneous timers in display." Based on a quick test, at least AUX
and PWM appear to be unaffected by this.

But since the register is there, let's configure it in accordance with
the spec.

Note that we have to move intel_update_rawclk() to occur before we
touch the power wells, so that the dev_priv->rawclk_freq is already
populated when the disp2 enable hook gets called for the first time.
I think this should be safe to do on other platforms as well.

Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_dma.c | 3 +++
 drivers/gpu/drm/i915/i915_reg.h | 2 ++
 drivers/gpu/drm/i915/intel_display.c| 4 ++--
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
 5 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5c7615041b31..fd1260d2b6ec 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -454,6 +454,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_vga_client;
 
+   /* must happen before intel_power_domains_init_hw() on VLV/CHV */
+   intel_update_rawclk(dev_priv);
+
intel_power_domains_init_hw(dev_priv, false);
 
intel_csr_ucode_init(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 25e229b609a7..0a2fd3000f94 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2449,6 +2449,8 @@ enum skl_disp_power_wells {
 #define   DPLL_MD_VGA_UDI_MULTIPLIER_MASK  0x003f
 #define   DPLL_MD_VGA_UDI_MULTIPLIER_SHIFT 0
 
+#define RAWCLK_FREQ_VLV_MMIO(VLV_DISPLAY_BASE + 0x6024)
+
 #define _FPA0  0x6040
 #define _FPA1  0x6044
 #define _FPB0  0x6048
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b7cb632a2a31..eb7cb9431209 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -185,6 +185,7 @@ intel_pch_rawclk(struct drm_i915_private *dev_priv)
 static int
 intel_vlv_hrawclk(struct drm_i915_private *dev_priv)
 {
+   /* RAWCLK_FREQ_VLV register updated from power well code */
return vlv_get_cck_clock_hpll(dev_priv, "hrawclk",
  CCK_DISPLAY_REF_CLOCK_CONTROL);
 }
@@ -218,7 +219,7 @@ intel_g4x_hrawclk(struct drm_i915_private *dev_priv)
}
 }
 
-static void intel_update_rawclk(struct drm_i915_private *dev_priv)
+void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = intel_pch_rawclk(dev_priv);
@@ -15455,7 +15456,6 @@ void intel_modeset_init(struct drm_device *dev)
}
 
intel_update_czclk(dev_priv);
-   intel_update_rawclk(dev_priv);
intel_update_cdclk(dev);
 
intel_shared_dpll_init(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cb89a35a6755..ce78afefe3cd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1110,6 +1110,7 @@ void i915_audio_component_init(struct drm_i915_private 
*dev_priv);
 void i915_audio_component_cleanup(struct drm_i915_private *dev_priv);
 
 /* intel_display.c */
+void intel_update_rawclk(struct drm_i915_private *dev_priv);
 int vlv_get_cck_clock(struct drm_i915_private *dev_priv,
  const char *name, u32 reg, int ref_freq);
 extern const struct drm_plane_funcs intel_plane_funcs;
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 7fb1da4e7fc3..b69b935516fb 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -948,6 +948,11 @@ static void vlv_init_display_clock_gating(struct 
drm_i915_private *dev_priv)
 */
I915_WRITE(MI_ARB_VLV, MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE);
I915_WRITE(CBR1_VLV, 0);
+
+   WARN_ON(dev_priv->rawclk_freq == 0);
+
+   I915_WRITE(RAWCLK_FREQ_VLV,
+  DIV_ROUND_CLOSEST(dev_priv->rawclk_freq, 1000));
 }
 
 static void vlv_display_power_well_init(struct drm_i915_private *dev_priv)
-- 
2.7.4

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Unduplicate CHV phy code (rev5)

[Tomi Sarvela]

Hello,

On Wednesday 27 April 2016 16:36:13 Ander Conselvan De Oliveira wrote:
> > Subgroup suspend-read-crc-pipe-a:
> > pass   -> INCOMPLETE (hsw-gt2)
> 
> dmesg ends with
> 
> [  505.669959] kms_pipe_crc_basic: starting subtest suspend-read-crc-pipe-A
> 
> Seems very unlikely this would be caused by this series. The only code that
> is run on hsw machines is setting the lane count field in crtc_state, but
> that is not used anywhere.
> 
> Are there any know issues with this machine?

There is no known issues with this hardware itself. There is one known issue 
with HSW and drm-intel kernel, which has taken a while to figure out. I think 
it still exists in the baseline kernel where patch is applied.

(It's hard to replicate with IGT, but newest Mesa seems to hit it quite 
regularly).

Regards,

Tomi




> 
> 
> Ander
> 
> > bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12
> > bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25
> > bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41
> > byt-nuc  total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41
> > hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26
> > hsw-gt2  total:199  pass:176  dwarn:0   dfail:0   fail:1   skip:21
> > ilk-hp8440p  total:200  pass:139  dwarn:0   dfail:0   fail:0   skip:61
> > ivb-t430stotal:200  pass:169  dwarn:0   dfail:0   fail:0   skip:31
> > skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27
> > skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11
> > snb-dellxps  total:200  pass:157  dwarn:1   dfail:0   fail:0   skip:42
> > snb-x220ttotal:200  pass:158  dwarn:0   dfail:0   fail:1   skip:41
> > 
> > Results at /archive/results/CI_IGT_test/Patchwork_2090/
> > 
> > 4fa405ab5848b76c8568c7fb771d389a6695108c drm-intel-nightly:
> > 2016y-04m-27d-10h -47m-35s UTC integration manifest
> > 9e163c0 drm/i915: Move VLV HDMI lane reset work around logic to
> > intel_dpio_phy.c
> > b7b843d drm/i915: Unduplicate pre encoder enabling phy code
> > 4165303 drm/i915: Unduplicate VLV phy pre pll enabling code
> > 7241e40 drm/i915: Unduplicate VLV signal level code
> > 1879a24 drm/i915: Unduplicate CHV encoders' post pll disable code
> > 3b54e74 drm/i915: Unduplicate CHV pre-encoder enabling phy logic
> > 66e88ec drm/i915: Unduplicate CHV phy-releated pre pll enabling code
> > 8a2b013 drm/i915: Unduplicate chv_data_lane_soft_reset()
> > 4a6d52d drm/i915: Unduplicate CHV signal level code
> > 5a20188 drm/i915: Set crtc_state->lane_count for HDMI

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

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Add support for detecting vblanks when hw frame counter is unavailable.

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 04:06:16PM +0200, Patrik Jakobsson wrote:
> On Tue, Apr 19, 2016 at 09:52:24AM +0200, Maarten Lankhorst wrote:
> > This uses the newly created drm_accurate_vblank_count_and_time to accurately
> > get a vblank count when the hw counter is unavailable.
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 10 ++
> >  drivers/gpu/drm/i915/intel_drv.h |  3 +++
> >  drivers/gpu/drm/i915/intel_sprite.c  |  8 ++--
> >  3 files changed, 15 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ccbc2a448258..2086e8bd10da 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13530,6 +13530,16 @@ static int intel_atomic_prepare_commit(struct 
> > drm_device *dev,
> > return ret;
> >  }
> >  
> > +u32 intel_crtc_get_vblank_counter(struct intel_crtc *crtc)
> > +{
> > +   struct drm_device *dev = crtc->base.dev;
> > +
> > +   if (!dev->max_vblank_count)
> > +   return drm_accurate_vblank_count(>base);
> > +
> > +   return dev->driver->get_vblank_counter(dev, crtc->pipe);
> > +}
> > +
> >  static void intel_atomic_wait_for_vblanks(struct drm_device *dev,
> >   struct drm_i915_private *dev_priv,
> >   unsigned crtc_mask)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index fecc89600667..8efeb90eac07 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1146,6 +1146,9 @@ intel_wait_for_vblank_if_active(struct drm_device 
> > *dev, int pipe)
> > if (crtc->active)
> > intel_wait_for_vblank(dev, pipe);
> >  }
> > +
> > +u32 intel_crtc_get_vblank_counter(struct intel_crtc *crtc);
> > +
> >  int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp);
> >  void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
> >  struct intel_digital_port *dport,
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 0f3e2303e0e9..e2de6b0df5a8 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -80,9 +80,7 @@ static int usecs_to_scanlines(const struct 
> > drm_display_mode *adjusted_mode,
> >   */
> >  void intel_pipe_update_start(struct intel_crtc *crtc)
> >  {
> > -   struct drm_device *dev = crtc->base.dev;
> > const struct drm_display_mode *adjusted_mode = 
> > >config->base.adjusted_mode;
> > -   enum pipe pipe = crtc->pipe;
> > long timeout = msecs_to_jiffies_timeout(1);
> > int scanline, min, max, vblank_start;
> > wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
> > @@ -139,8 +137,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
> >  
> > crtc->debug.scanline_start = scanline;
> > crtc->debug.start_vbl_time = ktime_get();
> > -   crtc->debug.start_vbl_count =
> > -   dev->driver->get_vblank_counter(dev, pipe);
> > +   crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
> >  
> > trace_i915_pipe_update_vblank_evaded(crtc);
> >  }
> > @@ -156,10 +153,9 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
> >   */
> >  void intel_pipe_update_end(struct intel_crtc *crtc)
> >  {
> > -   struct drm_device *dev = crtc->base.dev;
> > enum pipe pipe = crtc->pipe;
> > int scanline_end = intel_get_crtc_scanline(crtc);
> > -   u32 end_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
> > +   u32 end_vbl_count = intel_crtc_get_vblank_counter(crtc);
> > ktime_t end_vbl_time = ktime_get();
> >  
> > trace_i915_pipe_update_end(crtc, end_vbl_count, scanline_end);
> 
> Do we need to use intel_crtc_get_vblank_counter() in
> display_pipe_crc_irq_handler() as well?

There was a bit of talk whether we should use hw or sw counter for the
crc frame numbers, but I can't remember if we reached any real
conclusion. In the meantime the crc frame counters are all still zero
on gen2, meaning the tests don't work all that well. See [1].

And we still have the %8d bug highlited in that same patch series. Not
sure we reached any conclusion about that on either.

In any case using drm_accurate_vblank_count() from the irq handler
would be somewhat silly since the irq handler should have just updated
the sw counter to be uptodate, assuming we had vblank irqs enabled.

[1] https://lists.freedesktop.org/archives/intel-gfx/2015-December/083035.html

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

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Add support for detecting vblanks when hw frame counter is unavailable.

[Patrik Jakobsson]

On Tue, Apr 19, 2016 at 09:52:24AM +0200, Maarten Lankhorst wrote:
> This uses the newly created drm_accurate_vblank_count_and_time to accurately
> get a vblank count when the hw counter is unavailable.
> ---
>  drivers/gpu/drm/i915/intel_display.c | 10 ++
>  drivers/gpu/drm/i915/intel_drv.h |  3 +++
>  drivers/gpu/drm/i915/intel_sprite.c  |  8 ++--
>  3 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ccbc2a448258..2086e8bd10da 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13530,6 +13530,16 @@ static int intel_atomic_prepare_commit(struct 
> drm_device *dev,
>   return ret;
>  }
>  
> +u32 intel_crtc_get_vblank_counter(struct intel_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->base.dev;
> +
> + if (!dev->max_vblank_count)
> + return drm_accurate_vblank_count(>base);
> +
> + return dev->driver->get_vblank_counter(dev, crtc->pipe);
> +}
> +
>  static void intel_atomic_wait_for_vblanks(struct drm_device *dev,
> struct drm_i915_private *dev_priv,
> unsigned crtc_mask)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index fecc89600667..8efeb90eac07 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1146,6 +1146,9 @@ intel_wait_for_vblank_if_active(struct drm_device *dev, 
> int pipe)
>   if (crtc->active)
>   intel_wait_for_vblank(dev, pipe);
>  }
> +
> +u32 intel_crtc_get_vblank_counter(struct intel_crtc *crtc);
> +
>  int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp);
>  void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
>struct intel_digital_port *dport,
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 0f3e2303e0e9..e2de6b0df5a8 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -80,9 +80,7 @@ static int usecs_to_scanlines(const struct drm_display_mode 
> *adjusted_mode,
>   */
>  void intel_pipe_update_start(struct intel_crtc *crtc)
>  {
> - struct drm_device *dev = crtc->base.dev;
>   const struct drm_display_mode *adjusted_mode = 
> >config->base.adjusted_mode;
> - enum pipe pipe = crtc->pipe;
>   long timeout = msecs_to_jiffies_timeout(1);
>   int scanline, min, max, vblank_start;
>   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
> @@ -139,8 +137,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>  
>   crtc->debug.scanline_start = scanline;
>   crtc->debug.start_vbl_time = ktime_get();
> - crtc->debug.start_vbl_count =
> - dev->driver->get_vblank_counter(dev, pipe);
> + crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
>  
>   trace_i915_pipe_update_vblank_evaded(crtc);
>  }
> @@ -156,10 +153,9 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>   */
>  void intel_pipe_update_end(struct intel_crtc *crtc)
>  {
> - struct drm_device *dev = crtc->base.dev;
>   enum pipe pipe = crtc->pipe;
>   int scanline_end = intel_get_crtc_scanline(crtc);
> - u32 end_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
> + u32 end_vbl_count = intel_crtc_get_vblank_counter(crtc);
>   ktime_t end_vbl_time = ktime_get();
>  
>   trace_i915_pipe_update_end(crtc, end_vbl_count, scanline_end);

Do we need to use intel_crtc_get_vblank_counter() in
display_pipe_crc_irq_handler() as well?

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

-- 
Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, 
Sweden Registration Number: 556189-6027 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix comments about GMBUSFREQ register

[Ville Syrjälä]

On Wed, Apr 27, 2016 at 04:30:14PM +0300, Mika Kahola wrote:
> s/Programmng/Programming

It's straight from the spec, hence the [sic]

> 
> With this nitpick fixed, this is
> 
> Reviewed-by: Mika Kahola 
> 
> On Tue, 2016-04-26 at 19:46 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > The comment about GMBUSFREQ is confused. The spec actually explains
> > the 4MHz thing perfectly by noting that the 4MHz divider values is
> > actually just bits [9:2] not [9:0], hence the divide by 1000 correct.
> > Replace the confused note with a quote from the spec, and eliminate
> > the duplicated comment that snuck in.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 15 +--
> >  1 file changed, 5 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ea55dd331fac..ec9144ded255 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5311,18 +5311,13 @@ static void intel_update_cdclk(struct drm_device 
> > *dev)
> >  dev_priv->cdclk_freq);
> >  
> > /*
> > -* Program the gmbus_freq based on the cdclk frequency.
> > -* BSpec erroneously claims we should aim for 4MHz, but
> > -* in fact 1MHz is the correct frequency.
> > +* 9:0 CMBUS [sic] CDCLK frequency (cdfreq):
> > +* Programmng [sic] note: bit[9:2] should be programmed to the number
> > +* of cdclk that generates 4MHz reference clock freq which is used to
> > +* generate GMBus clock. This will vary with the cdclk freq.
> >  */
> > -   if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> > -   /*
> > -* Program the gmbus_freq based on the cdclk frequency.
> > -* BSpec erroneously claims we should aim for 4MHz, but
> > -* in fact 1MHz is the correct frequency.
> > -*/
> > +   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq, 
> > 1000));
> > -   }
> >  
> > if (dev_priv->max_cdclk_freq == 0)
> > intel_update_max_cdclk(dev);
> 
> -- 
> Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH] drm/i915: In render_state_init reset obj in teardown path

[Joonas Lahtinen]

On ti, 2016-04-26 at 11:04 +0100, Dave Gordon wrote:
> On 26/04/16 10:21, Matthew Auld wrote:
> > 
> > The teardown path in render_state_init leaves so->obj != NULL.
> > 
> > Suggested-by: Joonas Lahtinen 
> > Signed-off-by: Matthew Auld 
> > ---
> >   drivers/gpu/drm/i915/i915_gem_render_state.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
> > b/drivers/gpu/drm/i915/i915_gem_render_state.c
> > index 71611bf..10f3cf0 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
> > @@ -70,6 +70,7 @@ static int render_state_init(struct render_state *so, 
> > struct drm_device *dev)
> > 
> >   free_gem:
> >     drm_gem_object_unreference(>obj->base);
> > +   so->obj = NULL;

This is object_init style function, if it fails, the contents of "so"
is expected to be uninitialized, and should only be freed or attempted
to re-initialize by caller, never inspected, so no need for this.

See gen8_ppgtt_init for an example, it would be rather cubersome to
undo all assignments on error.

In short, I do not see this as a necessary step.

Regards, Joonas

> >     return ret;
> >   }
> It doesn't actually matter, because 'so' is pointing to a local object a 
> few frames up the callstack. But I don't think this function is entitled 
> to assume that; it should leave everything in a consistent state so 
> there aren't any dangling pointers to objects that have been freed lying 
> around - someday the argument may turn into a per-engine static or some 
> other long-lived thing. So,
> 
> Reviewed-by: Dave Gordon 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Propagate error from drm_gem_object_init() (rev2)

[Chris Wilson]

On Wed, Apr 27, 2016 at 04:35:33PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-04-25 at 13:24 +, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915: Propagate error from drm_gem_object_init() (rev2)
> > URL   : https://patchwork.freedesktop.org/series/6149/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 6149v2 drm/i915: Propagate error from drm_gem_object_init()
> > http://patchwork.freedesktop.org/api/1.0/series/6149/revisions/2/mbox/
> > 
> > Test drv_module_reload_basic:
> > pass   -> DMESG-WARN (ilk-hp8440p)
> 
> This seems like a problem that has not previously appeared. Please give
> it a look.
>   
> [  474.322285] 
> =
> [  474.322294] BUG dentry(4:session-c1.scope) (Tainted: G U ): 
> Redzone overwritten
> [  474.322299] 
> -
> 
> [  474.322304] Disabling lock debugging due to kernel taint
> [  474.322306] INFO: 0x8800b561f0c0-0x8800b561f0c3. First byte 0x0 
> instead of 0xcc
> [  474.322316] INFO: Allocated in __d_alloc+0x20/0x1b0 age=3579 cpu=3 pid=6426
> [  474.322323]    ___slab_alloc.constprop.62+0x37c/0x3b0
> [  474.322327]    __slab_alloc.isra.59.constprop.61+0x43/0x80
> [  474.322331]    kmem_cache_alloc+0x259/0x300
> [  474.322334]    __d_alloc+0x20/0x1b0
> [  474.322337]    d_alloc+0x18/0x70
> [  474.322342]    __lookup_hash+0x2e/0x50
> [  474.322344]    lookup_one_len+0xcd/0x120
> [  474.322350]    start_creating+0x71/0x100
> [  474.322353]    debugfs_create_file+0x2e/0xe0
> [  474.322396]    i915_debugfs_init+0xc8/0x120 [i915]
> [  474.322401]    drm_debugfs_init+0xa3/0x130
> [  474.322405]    drm_minor_register+0x5a/0x110
> [  474.322411]    drm_dev_register+0x2a/0xb0
> [  474.322416]    drm_get_pci_dev+0xce/0x1e0
> [  474.322431]    i915_pci_probe+0x2f/0x50 [i915]
> [  474.322437]    pci_device_probe+0x87/0xf0
> [  474.322442] INFO: Slab 0xea0002d58700 objects=26 used=14 
> fp=0x8800b561cc38 flags=0x40004081
> [  474.322451] INFO: Object 0x8800b561f0c8 @offset=12488 
> fp=0x8800b561ee58

[  474.322463] Redzone 8800b561f0c0: 00 f0 ff ff cc cc cc cc 

-> 255.255.240.0

I don't this is ours. A pass through with kasan / kmemcheck would still
be good to rule it out.
-Chris

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Unduplicate CHV phy code (rev5)

[Ander Conselvan De Oliveira]

On Wed, 2016-04-27 at 13:23 +, Patchwork wrote:
> == Series Details ==
> 
> Series: Unduplicate CHV phy code (rev5)
> URL   : https://patchwork.freedesktop.org/series/5463/
> State : failure
> 
> == Summary ==
> 
> Series 5463v5 Unduplicate CHV phy code
> http://patchwork.freedesktop.org/api/1.0/series/5463/revisions/5/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (snb-x220t)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> fail   -> PASS   (snb-x220t)
> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-a:
> pass   -> DMESG-WARN (snb-dellxps)

[  303.915830] [ cut here ]
[  303.915859] WARNING: CPU: 5 PID: 6657 at 
drivers/gpu/drm/i915/intel_display.c:13529 intel_atomic_commit+0x1271/0x1400 
[i915]
[  303.915861] pipe A vblank wait timed out

https://bugs.freedesktop.org/show_bug.cgi?id=95125

> Subgroup suspend-read-crc-pipe-a:
> pass   -> INCOMPLETE (hsw-gt2)

dmesg ends with

[  505.669959] kms_pipe_crc_basic: starting subtest suspend-read-crc-pipe-A

Seems very unlikely this would be caused by this series. The only code that is
run on hsw machines is setting the lane count field in crtc_state, but that is
not used anywhere.

Are there any know issues with this machine?


Ander

> 
> bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
> bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> byt-nuc  total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
> hsw-gt2  total:199  pass:176  dwarn:0   dfail:0   fail:1   skip:21 
> ilk-hp8440p  total:200  pass:139  dwarn:0   dfail:0   fail:0   skip:61 
> ivb-t430stotal:200  pass:169  dwarn:0   dfail:0   fail:0   skip:31 
> skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
> skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11 
> snb-dellxps  total:200  pass:157  dwarn:1   dfail:0   fail:0   skip:42 
> snb-x220ttotal:200  pass:158  dwarn:0   dfail:0   fail:1   skip:41 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2090/
> 
> 4fa405ab5848b76c8568c7fb771d389a6695108c drm-intel-nightly: 2016y-04m-27d-10h
> -47m-35s UTC integration manifest
> 9e163c0 drm/i915: Move VLV HDMI lane reset work around logic to
> intel_dpio_phy.c
> b7b843d drm/i915: Unduplicate pre encoder enabling phy code
> 4165303 drm/i915: Unduplicate VLV phy pre pll enabling code
> 7241e40 drm/i915: Unduplicate VLV signal level code
> 1879a24 drm/i915: Unduplicate CHV encoders' post pll disable code
> 3b54e74 drm/i915: Unduplicate CHV pre-encoder enabling phy logic
> 66e88ec drm/i915: Unduplicate CHV phy-releated pre pll enabling code
> 8a2b013 drm/i915: Unduplicate chv_data_lane_soft_reset()
> 4a6d52d drm/i915: Unduplicate CHV signal level code
> 5a20188 drm/i915: Set crtc_state->lane_count for HDMI
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Propagate error from drm_gem_object_init() (rev2)

[Joonas Lahtinen]

On ma, 2016-04-25 at 13:24 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Propagate error from drm_gem_object_init() (rev2)
> URL   : https://patchwork.freedesktop.org/series/6149/
> State : failure
> 
> == Summary ==
> 
> Series 6149v2 drm/i915: Propagate error from drm_gem_object_init()
> http://patchwork.freedesktop.org/api/1.0/series/6149/revisions/2/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (ilk-hp8440p)

This seems like a problem that has not previously appeared. Please give
it a look.
    
[  474.322285] 
=
[  474.322294] BUG dentry(4:session-c1.scope) (Tainted: G U ): 
Redzone overwritten
[  474.322299] 
-

[  474.322304] Disabling lock debugging due to kernel taint
[  474.322306] INFO: 0x8800b561f0c0-0x8800b561f0c3. First byte 0x0 
instead of 0xcc
[  474.322316] INFO: Allocated in __d_alloc+0x20/0x1b0 age=3579 cpu=3 pid=6426
[  474.322323]  ___slab_alloc.constprop.62+0x37c/0x3b0
[  474.322327]  __slab_alloc.isra.59.constprop.61+0x43/0x80
[  474.322331]  kmem_cache_alloc+0x259/0x300
[  474.322334]  __d_alloc+0x20/0x1b0
[  474.322337]  d_alloc+0x18/0x70
[  474.322342]  __lookup_hash+0x2e/0x50
[  474.322344]  lookup_one_len+0xcd/0x120
[  474.322350]  start_creating+0x71/0x100
[  474.322353]  debugfs_create_file+0x2e/0xe0
[  474.322396]  i915_debugfs_init+0xc8/0x120 [i915]
[  474.322401]  drm_debugfs_init+0xa3/0x130
[  474.322405]  drm_minor_register+0x5a/0x110
[  474.322411]  drm_dev_register+0x2a/0xb0
[  474.322416]  drm_get_pci_dev+0xce/0x1e0
[  474.322431]  i915_pci_probe+0x2f/0x50 [i915]
[  474.322437]  pci_device_probe+0x87/0xf0
[  474.322442] INFO: Slab 0xea0002d58700 objects=26 used=14 
fp=0x8800b561cc38 flags=0x40004081
[  474.322451] INFO: Object 0x8800b561f0c8 @offset=12488 
fp=0x8800b561ee58

> pass   -> SKIP   (ivb-t430s)

This was still caused by Piglit.

> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> FAIL   (hsw-gt2)

Already reported;

(kms_flip:6157) CRITICAL: Test assertion failure function check_final_state, 
file kms_flip.c:1192:
(kms_flip:6157) CRITICAL: Failed assertion: count >= expected * 99/100 && count 
<= expected * 101/100
(kms_flip:6157) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:6157) CRITICAL: dropped frames, expected 99, counted 100, encoder 
type 1
Subtest basic-flip-vs-wf_vblank failed.

https://bugs.freedesktop.org/show_bug.cgi?id=94294

Regards, Joonas

> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b-frame-sequence:
> skip   -> PASS   (bdw-nuci7)
> 
> bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
> bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> byt-nuc  total:199  pass:155  dwarn:0   dfail:0   fail:0   skip:44 
> hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
> hsw-gt2  total:200  pass:178  dwarn:0   dfail:0   fail:1   skip:21 
> ilk-hp8440p  total:200  pass:136  dwarn:1   dfail:0   fail:0   skip:63 
> ivb-t430stotal:200  pass:165  dwarn:0   dfail:0   fail:0   skip:35 
> skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
> skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11 
> snb-dellxps  total:51   pass:40   dwarn:0   dfail:0   fail:0   skip:10 
> snb-x220t failed to collect. IGT log at Patchwork_2062/snb-x220t/igt.log
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2062/
> 
> f814551aa7232ed36d71244dd148b48660b53a78 drm-intel-nightly: 
> 2016y-04m-25d-11h-36m-27s UTC integration manifest
> c3f40d8 drm/i915: Propagate error from drm_gem_object_init()
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Jani Nikula]

On Wed, 27 Apr 2016, Florian Zumbiehl  wrote:
>> Florian, if you're using drm-intel-nigthly submit a bug at
>> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI, with DRM/intel
>> as component. This way we can track some kind of progress/regress. The FIFO
>
> Gee ... is there any way without "creating an account"? Having to create
> accounts everywhere to be able to communicate with people just sucks. I
> mean, do you want to create an account in my todo tracker and use my todo
> tracker's web interface to coordinate the bug investigation? Use whatever
> software you like for managing your todo lists, but please, don't bother me
> with having to use it for you.

The Bugzilla at https://bugs.freedesktop.org is our tool of choice for
tracking bugs in drm/i915. It's your choice to not create an account
there, but please, don't expect us to work as a proxy between you and
bugzilla either. It's a much bigger and unscalable inconvenience for us
than it is for you to create that account.

I won't claim your bug will be fixed any faster if you choose to create
an account, but it's much more likely it won't get lost and forgotten in
the never ending stream of emails we all get.

> You mean the ones I reported a month ago should be fixed? Should I try a
> newer nightly to check?

Yes, please.

I'd also like to get a full dmesg from you, with drm.debug=14 module
parameter set, all the way from boot to the problem.

However, personally I find it a bit obnoxious to send big logs by mail
to hundreds or thousands of other people on the lists who really aren't
at all interested in them. Maybe you don't mind bothering them? It's
also not good to hide it away in my private inbox alone, because there
are other developers who will be interested. It has also proven to be
problematic to upload files to pastebins etc. where they expire at some
point in time, usually when we'd like to have a look.

Again, the obvious solution to the above is to file that bug and attach
the dmesg there, at the unfortunate slight inconvenience of you creating
an account there.

Your call.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix comments about GMBUSFREQ register

[Mika Kahola]

s/Programmng/Programming

With this nitpick fixed, this is

Reviewed-by: Mika Kahola 

On Tue, 2016-04-26 at 19:46 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The comment about GMBUSFREQ is confused. The spec actually explains
> the 4MHz thing perfectly by noting that the 4MHz divider values is
> actually just bits [9:2] not [9:0], hence the divide by 1000 correct.
> Replace the confused note with a quote from the spec, and eliminate
> the duplicated comment that snuck in.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 15 +--
>  1 file changed, 5 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ea55dd331fac..ec9144ded255 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5311,18 +5311,13 @@ static void intel_update_cdclk(struct drm_device *dev)
>dev_priv->cdclk_freq);
>  
>   /*
> -  * Program the gmbus_freq based on the cdclk frequency.
> -  * BSpec erroneously claims we should aim for 4MHz, but
> -  * in fact 1MHz is the correct frequency.
> +  * 9:0 CMBUS [sic] CDCLK frequency (cdfreq):
> +  * Programmng [sic] note: bit[9:2] should be programmed to the number
> +  * of cdclk that generates 4MHz reference clock freq which is used to
> +  * generate GMBus clock. This will vary with the cdclk freq.
>*/
> - if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> - /*
> -  * Program the gmbus_freq based on the cdclk frequency.
> -  * BSpec erroneously claims we should aim for 4MHz, but
> -  * in fact 1MHz is the correct frequency.
> -  */
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq, 
> 1000));
> - }
>  
>   if (dev_priv->max_cdclk_freq == 0)
>   intel_update_max_cdclk(dev);

-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH v6 15/25] drm/i915: Preallocate enough space for the average request

[Chris Wilson]

On Wed, Apr 27, 2016 at 02:15:29PM +0100, Tvrtko Ursulin wrote:
> 
> On 26/04/16 21:06, Chris Wilson wrote:
> >Rather than being interrupted when we run out of space halfway through
> >the request, and having to restart from the beginning (and returning to
> >userspace), flush a little more free space when we prepare the request.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >---
> >  drivers/gpu/drm/i915/intel_lrc.c|  7 +++
> >  drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +++-
> >  2 files changed, 22 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 01517dd7069b..b5c2c1931a5f 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -700,6 +700,12 @@ int intel_logical_ring_alloc_request_extras(struct 
> >drm_i915_gem_request *request
> >  {
> > int ret;
> >
> >+/* Flush enough space to reduce the likelihood of waiting after
> >+ * we start building the request - in which case we will just
> >+ * have to repeat work.
> >+ */
> >+request->reserved_space += MIN_SPACE_FOR_ADD_REQUEST;
> >+
> > request->ringbuf = request->ctx->engine[request->engine->id].ringbuf;
> >
> > if (i915.enable_guc_submission) {
> >@@ -725,6 +731,7 @@ int intel_logical_ring_alloc_request_extras(struct 
> >drm_i915_gem_request *request
> > if (ret)
> > goto err_unpin;
> >
> >+request->reserved_space -= MIN_SPACE_FOR_ADD_REQUEST;
> 
> Without any previous experience with ringbuf space reservation and
> related, this does make sense to me. :)
> 
> So why add and subtract and not just increase
> MIN_SPACE_FOR_ADD_REQUEST? Or if MIN_SPACE_FOR_ADD_REQUEST is
> completely unrelated to the subsequent stuff to go in, and perhaps
> only represent the typical driver prologue & epilogue, why increase
> the reserved size temporarily by that amount and not something else?

The game being played here is to first free up enough space inside the
ringbuffer that we shouldn't have to pause again, and then ensure that
we always have enough space to submit the request. So step 1 is flush,
then step 2 is reserve, step 3 is to use the reserve.

MIN_SPACE_FOR_ADD_REQUEST is being used as a conservative estimate. What
we actually use is approx. 1 flush and 1 bb for lrc. 1 flush, several
LRI, 1 switch context, more LRI, another flush and then 1 bb for
ringbuffer. The amount of space we flush and reserve could be fine
tuned, and will likely need to be adjusted in future for various
features. But the flush is just an optimisation, the reserve is
mandatory.
-Chris

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

Re: [Intel-gfx] [PATCH 02/19] drm/i915: Remove stallcheck special handling, v2.

[Patrik Jakobsson]

On Tue, Apr 19, 2016 at 09:52:22AM +0200, Maarten Lankhorst wrote:
> Both intel_unpin_work.pending and intel_unpin_work.enable_stall_check
> were used to see if work should be enabled. By only using pending
> some special cases are gone, and access to unpin_work can be simplified.
> 
> Use this to only access work members untilintel_mark_page_flip_active
> is called, or intel_queue_mmio_flip is used. This will prevent
> use-after-free, and makes it easier to verify accesses.
> 
> Changes since v1:
> - Reword commit message.
> - Do not access unpin_work after intel_mark_page_flip_active.
> - Add the right memory barriers.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  | 11 +++---
>  drivers/gpu/drm/i915/intel_display.c | 71 
> ++--
>  drivers/gpu/drm/i915/intel_drv.h |  1 -
>  3 files changed, 34 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 931dc6086f3b..0092aaf47c43 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -612,9 +612,14 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>   seq_printf(m, "No flip due on pipe %c (plane %c)\n",
>  pipe, plane);
>   } else {
> + u32 pending;
>   u32 addr;
>  
> - if (atomic_read(>pending) < INTEL_FLIP_COMPLETE) {
> + pending = atomic_read(>pending);
> + if (pending == INTEL_FLIP_INACTIVE) {
> + seq_printf(m, "Flip ioctl preparing on pipe %c 
> (plane %c)\n",
> +pipe, plane);
> + } else if (pending >= INTEL_FLIP_COMPLETE) {
>   seq_printf(m, "Flip queued on pipe %c (plane 
> %c)\n",
>  pipe, plane);
>   } else {
> @@ -636,10 +641,6 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>  work->flip_queued_vblank,
>  work->flip_ready_vblank,
>  drm_crtc_vblank_count(>base));
> - if (work->enable_stall_check)
> - seq_puts(m, "Stall check enabled, ");
> - else
> - seq_puts(m, "Stall check waiting for page flip 
> ioctl, ");
>   seq_printf(m, "%d prepares\n", 
> atomic_read(>pending));
>  
>   if (INTEL_INFO(dev)->gen >= 4)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 4cb830e2a62e..97a8418f6539 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3896,8 +3896,6 @@ static void page_flip_completed(struct intel_crtc 
> *intel_crtc)
>   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
>   struct intel_unpin_work *work = intel_crtc->unpin_work;
>  
> - /* ensure that the unpin work is consistent wrt ->pending. */
> - smp_rmb();
>   intel_crtc->unpin_work = NULL;
>  
>   if (work->event)
> @@ -10980,16 +10978,13 @@ static void do_intel_finish_page_flip(struct 
> drm_device *dev,
>   spin_lock_irqsave(>event_lock, flags);
>   work = intel_crtc->unpin_work;
>  
> - /* Ensure we don't miss a work->pending update ... */
> - smp_rmb();
> + if (work && atomic_read(>pending) >= INTEL_FLIP_COMPLETE) {
> + /* ensure that the unpin work is consistent wrt ->pending. */
> + smp_mb__after_atomic();

The docs on smp_mb__after/before_atomic() states that they are used with atomic
functions that do not return a value. Why are we using it together with
atomic_read() here?

>  
> - if (work == NULL || atomic_read(>pending) < INTEL_FLIP_COMPLETE) {
> - spin_unlock_irqrestore(>event_lock, flags);
> - return;
> + page_flip_completed(intel_crtc);
>   }
>  
> - page_flip_completed(intel_crtc);
> -
>   spin_unlock_irqrestore(>event_lock, flags);
>  }
>  
> @@ -11087,10 +11082,8 @@ void intel_prepare_page_flip(struct drm_device *dev, 
> int plane)
>  static inline void intel_mark_page_flip_active(struct intel_unpin_work *work)
>  {
>   /* Ensure that the work item is consistent when activating it ... */
> - smp_wmb();
> + smp_mb__before_atomic();
>   atomic_set(>pending, INTEL_FLIP_PENDING);
> - /* and that it is marked active as soon as the irq could fire. */
> - smp_wmb();
>  }
>  
>  static int intel_gen2_queue_flip(struct drm_device *dev,
> @@ -11124,7 +7,6 @@ static int intel_gen2_queue_flip(struct drm_device 
> *dev,
>   intel_ring_emit(engine, intel_crtc->unpin_work->gtt_offset);

[Intel-gfx] ✗ Fi.CI.BAT: failure for Unduplicate CHV phy code (rev5)

[Patchwork]

== Series Details ==

Series: Unduplicate CHV phy code (rev5)
URL   : https://patchwork.freedesktop.org/series/5463/
State : failure

== Summary ==

Series 5463v5 Unduplicate CHV phy code
http://patchwork.freedesktop.org/api/1.0/series/5463/revisions/5/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (snb-x220t)
Test gem_exec_suspend:
Subgroup basic-s3:
fail   -> PASS   (snb-x220t)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (snb-dellxps)
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (hsw-gt2)

bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:199  pass:176  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:200  pass:139  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:200  pass:169  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:200  pass:157  dwarn:1   dfail:0   fail:0   skip:42 
snb-x220ttotal:200  pass:158  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/Patchwork_2090/

4fa405ab5848b76c8568c7fb771d389a6695108c drm-intel-nightly: 
2016y-04m-27d-10h-47m-35s UTC integration manifest
9e163c0 drm/i915: Move VLV HDMI lane reset work around logic to intel_dpio_phy.c
b7b843d drm/i915: Unduplicate pre encoder enabling phy code
4165303 drm/i915: Unduplicate VLV phy pre pll enabling code
7241e40 drm/i915: Unduplicate VLV signal level code
1879a24 drm/i915: Unduplicate CHV encoders' post pll disable code
3b54e74 drm/i915: Unduplicate CHV pre-encoder enabling phy logic
66e88ec drm/i915: Unduplicate CHV phy-releated pre pll enabling code
8a2b013 drm/i915: Unduplicate chv_data_lane_soft_reset()
4a6d52d drm/i915: Unduplicate CHV signal level code
5a20188 drm/i915: Set crtc_state->lane_count for HDMI

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

Re: [Intel-gfx] [PATCH v6 16/25] drm/i915: Update execlists context descriptor format commentary

[Tvrtko Ursulin]

On 26/04/16 21:06, Chris Wilson wrote:

The comments describing the Context Descriptor Format are off by a bit
for the size of the context ID.

Signed-off-by: Chris Wilson 
Cc: Dave Gordon 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b5c2c1931a5f..5d8ee9059eee 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -305,10 +305,11 @@ logical_ring_init_platform_invariants(struct 
intel_engine_cs *engine)
   * which remains valid until the context is unpinned.
   *
   * This is what a descriptor looks like, from LSB to MSB:
- *bits 0-11:flags, GEN8_CTX_* (cached in ctx_desc_template)
+ *bits  0-11:flags, GEN8_CTX_* (cached in ctx_desc_template)
   *bits 12-31:LRCA, GTT address of (the HWSP of) this context
- *bits 32-51:ctx ID, a globally unique tag (the LRCA again!)
- *bits 52-63:reserved, may encode the engine ID (for GuC)
+ *bits 32-52:ctx ID, a globally unique tag (the LRCA again!)
+ *bits 53-54:mbz, reserved for use by hardware
+ *bits 55-63:group ID, currently unused and set to 0
   */
  static void
  intel_lr_context_descriptor_update(struct intel_context *ctx,
@@ -319,9 +320,9 @@ intel_lr_context_descriptor_update(struct intel_context 
*ctx,
lrca = ctx->engine[engine->id].lrc_vma->node.start +
   LRC_PPHWSP_PN * PAGE_SIZE;

-   desc = engine->ctx_desc_template;   /* bits  0-11 */
+   desc = engine->ctx_desc_template;   /* bits  0-11 */
desc |= lrca;  /* bits 12-31 */
-   desc |= (lrca >> PAGE_SHIFT) << GEN8_CTX_ID_SHIFT; /* bits 32-51 */
+   desc |= (lrca >> PAGE_SHIFT) << GEN8_CTX_ID_SHIFT; /* bits 32-52 */

ctx->engine[engine->id].lrc_desc = desc;
  }



Verified against the docs and it is correct.

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH v6 15/25] drm/i915: Preallocate enough space for the average request

[Tvrtko Ursulin]

On 26/04/16 21:06, Chris Wilson wrote:

Rather than being interrupted when we run out of space halfway through
the request, and having to restart from the beginning (and returning to
userspace), flush a little more free space when we prepare the request.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c|  7 +++
  drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +++-
  2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 01517dd7069b..b5c2c1931a5f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -700,6 +700,12 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
  {
int ret;

+   /* Flush enough space to reduce the likelihood of waiting after
+* we start building the request - in which case we will just
+* have to repeat work.
+*/
+   request->reserved_space += MIN_SPACE_FOR_ADD_REQUEST;
+
request->ringbuf = request->ctx->engine[request->engine->id].ringbuf;

if (i915.enable_guc_submission) {
@@ -725,6 +731,7 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
if (ret)
goto err_unpin;

+   request->reserved_space -= MIN_SPACE_FOR_ADD_REQUEST;


Without any previous experience with ringbuf space reservation and 
related, this does make sense to me. :)


So why add and subtract and not just increase MIN_SPACE_FOR_ADD_REQUEST? 
Or if MIN_SPACE_FOR_ADD_REQUEST is completely unrelated to the 
subsequent stuff to go in, and perhaps only represent the typical driver 
prologue & epilogue, why increase the reserved size temporarily by that 
amount and not something else?


Regards,

Tvrtko


return 0;

  err_unpin:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1193372f74fd..1285605f25c7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2332,8 +2332,22 @@ int intel_engine_idle(struct intel_engine_cs *engine)

  int intel_ring_alloc_request_extras(struct drm_i915_gem_request *request)
  {
+   int ret;
+
+   /* Flush enough space to reduce the likelihood of waiting after
+* we start building the request - in which case we will just
+* have to repeat work.
+*/
+   request->reserved_space += MIN_SPACE_FOR_ADD_REQUEST;
+
request->ringbuf = request->engine->buffer;
-   return intel_ring_begin(request, 0);
+
+   ret = intel_ring_begin(request, 0);
+   if (ret)
+   return ret;
+
+   request->reserved_space -= MIN_SPACE_FOR_ADD_REQUEST;
+   return 0;
  }

  static int wait_for_space(struct drm_i915_gem_request *req, int bytes)


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: tidy up gen8_init_scratch (rev2)

[Joonas Lahtinen]

On ke, 2016-04-27 at 12:49 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: tidy up gen8_init_scratch (rev2)
> URL   : https://patchwork.freedesktop.org/series/6315/
> State : failure
> 
> == Summary ==
> 
> Series 6315v2 drm/i915: tidy up gen8_init_scratch
> http://patchwork.freedesktop.org/api/1.0/series/6315/revisions/2/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (snb-x220t)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> fail   -> PASS   (snb-x220t)
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> FAIL   (snb-x220t)
> 

Already reported;

(kms_flip:6253) CRITICAL: Test assertion failure function check_state, file 
kms_flip.c:698:
(kms_flip:6253) CRITICAL: Failed assertion: fabsdouble) diff.tv_usec) - 
usec_interflip) / usec_interflip) <= 0.005
(kms_flip:6253) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:6253) CRITICAL: inter-vblank ts jitter: 0s, 183886usec
Subtest basic-flip-vs-wf_vblank failed.

https://bugs.freedesktop.org/show_bug.cgi?id=94294

So merging in.

Thanks for the patch.

> bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
> bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
> hsw-gt2  total:200  pass:178  dwarn:0   dfail:0   fail:1   skip:21 
> ilk-hp8440p  total:200  pass:139  dwarn:0   dfail:0   fail:0   skip:61 
> ivb-t430stotal:200  pass:169  dwarn:0   dfail:0   fail:0   skip:31 
> skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
> skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11 
> snb-dellxps  total:200  pass:158  dwarn:0   dfail:0   fail:0   skip:42 
> snb-x220ttotal:200  pass:157  dwarn:0   dfail:0   fail:2   skip:41 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2089/
> 
> 4fa405ab5848b76c8568c7fb771d389a6695108c drm-intel-nightly: 
> 2016y-04m-27d-10h-47m-35s UTC integration manifest
> 6107550 drm/i915: tidy up gen8_init_scratch
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

[Eero Tamminen]

Hi,

On 26.04.2016 20:25, Frederick, Michael T wrote:

Sorry I'm not tracking all the MOCs discussions.  I just want to indicate what 
the coherency means in SoC for BXT.

GTI sets the non-inclusive bit on the IDI interface based on how it treats the memory.  
In BXT case where there is no uncore cache, "non-inclusive" just indicates 
snoop or not.  BXT has a snoop filter in order to make the latency of snooping GT from a 
core roughly similar to snooping another core.

For BXT:
If GTI sets non-inclusive=0 (i.e. coherent): transaction looks up in the SF and 
the SA snoops the cores.  The potential impact here is that for high BW 
coherent traffic, the SF will become the BW limiter of the system and cap BW at 
33% * 34GBps. For writes like WCILFs snoops to cores must be resolved before SA 
requests WR data from GT.  For reads the common case should have no impact 
because snoop latency is generally much less than memory data latency.  In 
general snoop latency for a core is relatively small, but there is also the 
prospect that a core could be down (e.g. ratio change) or loaded w/ snooping.
If GTI sets non-inclusive=1 (i.e. non-coherent): transaction takes the SF 
bypass and the SA does not snoop the cores.  This is best for high-BW since it 
removes the SF bottleneck and doesn't require core interaction.


Thanks for the explanation!

AFAIK:

* In regards to 3D driver operations, CPU side doesn't modify the buffer 
contents while GPU is working on them.  CPU side sets up the buffers 
(textures, VBOs, batches etc), and then (after a flush) GPU is asked to 
act on them.


* For things like texture streaming, the driver either internally 
synchronizes the data or creates a new copy of it whenever application 
tells that data is updated.  There's always some kind of "upload" 
involved (GL API needs it as non-integrated GPU's don't share memory 
with CPU).


While it's possible that there's a case where snooping would be needed, 
I cannot think of any myself.


Daniel, Chris, did you have some concrete example in mind where 3D 
driver would require CPU to snoop GPU?



- Eero

Disclaimer: I'm not a 3D driver developer myself.



Thanks, Mike


-Original Message-
From: Tamminen, Eero T
Sent: Tuesday, April 26, 2016 10:19 AM
To: Daniel Vetter 
Cc: Chris Wilson ; Deak, Imre ; 
intel-gfx@lists.freedesktop.org; Rantala, Valtteri ; Frederick, Michael T 
; Ville Syrjälä 
Subject: Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU 
snooping due to incorrect MOCS config

Hi,

On 26.04.2016 17:30, Daniel Vetter wrote:

On Tue, Apr 26, 2016 at 05:26:43PM +0300, Eero Tamminen wrote:

[...]

What this kernel ABI (index entry #2) has been agreed & documented to
provide?

I thought this entry is supposed to replace the writeback LLC/eLLC
cache MOCS setting Mesa is using on (e.g. BDW) to speed up accesses
to a memory area which it knows always to be accessed so that it can be cached.

If app runs on HW where LLC/eLLC is missing, giving the app extra
slowdown instead of potential speedup sounds like failed HW
abstraction. :-)


Well mesa needs to know llc vs. !llc anyway to not totally suck,


What do you think it should do with that information?

I assume you to mean, that Mesa needs to know the *amount* of LLC and change 
its behavior based on that amount, not just whether it's present.

In that case Mesa does, and has always totally "sucked".  Mesa on earlier 
GEN(s) cached everything that can be cached, and I assume it to try to do that with GEN9 
too.


However, based on our MOCS testing on BDW, that actually gives the best overall perf 
results.  On average it doesn't give much, but it was better than any straightforward 
(buffer size/type) heuristics for making something not to be cached in effort to utilize 
LLC "better".

It seemed that LLC is too small to have meaningful generic heuristics for normal 3D 
workloads (or they need to be very complex, something needing months of testing 
& iteration, or be per application, not generic).

eLLC could be a different matter as it's large enough that one can put e.g. 
color/depth buffer there.

Skip cache setting for LLC may also be useful, if it works (as it in a sense 
extends the cache size), and render compression can also change things.  
Problem with RBC is that it makes assumptions about memory areas usage even 
less reliable as you don't know how well the content compresses.



and defining entry #2 as "coherent, always" makes sense. I thought
entry 0 was the reaonable default aka pte passthrough and hence managed by 
kernel?

If mesa asks for nonsense, the kernel is happy to oblige.



- Eero



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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: tidy up gen8_init_scratch (rev2)

[Mika Kuoppala]

Patchwork  writes:

> [ text/plain ]
> == Series Details ==
>
> Series: drm/i915: tidy up gen8_init_scratch (rev2)
> URL   : https://patchwork.freedesktop.org/series/6315/
> State : failure
>
> == Summary ==
>
> Series 6315v2 drm/i915: tidy up gen8_init_scratch
> http://patchwork.freedesktop.org/api/1.0/series/6315/revisions/2/mbox/
>
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (snb-x220t)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> fail   -> PASS   (snb-x220t)
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> FAIL   (snb-x220t)

https://bugs.freedesktop.org/show_bug.cgi?id=94294

>
> bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
> bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
> hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
> hsw-gt2  total:200  pass:178  dwarn:0   dfail:0   fail:1   skip:21 
> ilk-hp8440p  total:200  pass:139  dwarn:0   dfail:0   fail:0   skip:61 
> ivb-t430stotal:200  pass:169  dwarn:0   dfail:0   fail:0   skip:31 
> skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
> skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11 
> snb-dellxps  total:200  pass:158  dwarn:0   dfail:0   fail:0   skip:42 
> snb-x220ttotal:200  pass:157  dwarn:0   dfail:0   fail:2   skip:41 
>
> Results at /archive/results/CI_IGT_test/Patchwork_2089/
>
> 4fa405ab5848b76c8568c7fb771d389a6695108c drm-intel-nightly: 
> 2016y-04m-27d-10h-47m-35s UTC integration manifest
> 6107550 drm/i915: tidy up gen8_init_scratch
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: tidy up gen8_init_scratch

[Joonas Lahtinen]

On ke, 2016-04-27 at 15:30 +0300, Mika Kuoppala wrote:
> Matthew Auld  writes:
> 
> > 
> > [ text/plain ]
> > Prefer a goto teardown path to do all the required cleanup.
> > 
> > v2:
> > (Joonas Lahtinen)
> >   - remove NULL assignments
> >   - rename goto labels
> > 
> > Cc: Mika Kuoppala 
> > Cc: Dave Gordon 
> > Cc: Joonas Lahtinen 
> > Signed-off-by: Matthew Auld 
> Reviewed-by: Mika Kuoppala 
> 

Reviewed-by: Joonas Lahtinen 

> > 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_gtt.c | 25 -
> >  1 file changed, 16 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 0d666b3..87947ec 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -866,6 +866,7 @@ static void gen8_free_page_tables(struct drm_device 
> > *dev,
> >  static int gen8_init_scratch(struct i915_address_space *vm)
> >  {
> >     struct drm_device *dev = vm->dev;
> > +   int ret;
> >  
> >     vm->scratch_page = alloc_scratch_page(dev);
> >     if (IS_ERR(vm->scratch_page))
> > @@ -873,24 +874,21 @@ static int gen8_init_scratch(struct 
> > i915_address_space *vm)
> >  
> >     vm->scratch_pt = alloc_pt(dev);
> >     if (IS_ERR(vm->scratch_pt)) {
> > -   free_scratch_page(dev, vm->scratch_page);
> > -   return PTR_ERR(vm->scratch_pt);
> > +   ret = PTR_ERR(vm->scratch_pt);
> > +   goto free_scratch_page;
> >     }
> >  
> >     vm->scratch_pd = alloc_pd(dev);
> >     if (IS_ERR(vm->scratch_pd)) {
> > -   free_pt(dev, vm->scratch_pt);
> > -   free_scratch_page(dev, vm->scratch_page);
> > -   return PTR_ERR(vm->scratch_pd);
> > +   ret = PTR_ERR(vm->scratch_pd);
> > +   goto free_pt;
> >     }
> >  
> >     if (USES_FULL_48BIT_PPGTT(dev)) {
> >     vm->scratch_pdp = alloc_pdp(dev);
> >     if (IS_ERR(vm->scratch_pdp)) {
> > -   free_pd(dev, vm->scratch_pd);
> > -   free_pt(dev, vm->scratch_pt);
> > -   free_scratch_page(dev, vm->scratch_page);
> > -   return PTR_ERR(vm->scratch_pdp);
> > +   ret = PTR_ERR(vm->scratch_pdp);
> > +   goto free_pd;
> >     }
> >     }
> >  
> > @@ -900,6 +898,15 @@ static int gen8_init_scratch(struct i915_address_space 
> > *vm)
> >     gen8_initialize_pdp(vm, vm->scratch_pdp);
> >  
> >     return 0;
> > +
> > +free_pd:
> > +   free_pd(dev, vm->scratch_pd);
> > +free_pt:
> > +   free_pt(dev, vm->scratch_pt);
> > +free_scratch_page:
> > +   free_scratch_page(dev, vm->scratch_page);
> > +
> > +   return ret;
> >  }
> >  
> >  static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt *ppgtt, bool create)
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use cached cdclk value in i915_audio_component_get_cdclk_freq()

[Mika Kahola]

Looks reasonable.

Reviewed-by: Mika Kahola 

On Tue, 2016-04-26 at 19:46 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> No point in reading the cdclk out from the hardware every single time
> since we have it cached already. Just return the cached value to the
> audio driver.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 56ba8765816e..1063108a9bab 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -624,17 +624,11 @@ static void 
> i915_audio_component_codec_wake_override(struct device *dev,
>  static int i915_audio_component_get_cdclk_freq(struct device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev_to_i915(dev);
> - int ret;
>  
>   if (WARN_ON_ONCE(!HAS_DDI(dev_priv)))
>   return -ENODEV;
>  
> - intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
> - ret = dev_priv->display.get_display_clock_speed(dev_priv->dev);
> -
> - intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
> -
> - return ret;
> + return dev_priv->cdclk_freq;
>  }
>  
>  static int i915_audio_component_sync_audio_rate(struct device *dev,

-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation

[Tvrtko Ursulin]

On 27/04/16 13:58, Chris Wilson wrote:

On Wed, Apr 27, 2016 at 01:51:38PM +0100, Tvrtko Ursulin wrote:


On 26/04/16 21:06, Chris Wilson wrote:

In the next patches, we want to move the work out of freeing the request
and into its retirement (so that we can free the request without
requiring the struct_mutex). This means that we cannot rely on
unreferencing the request to completely teardown the request any more
and so we need to manually unwind the failed allocation. In doing so, we
reorder the allocation in order to make the unwind simple (and ensure
that we don't try to unwind a partial request that may have modified
global state) and so we end up pushing the initial preallocation down
into the engine request initialisation functions where we have the
requisite control over the state of the request.

Moving the initial preallocation into the engine is less than ideal: it
moves logic to handle a specific problem with request handling out of
the common code. On the other hand, it does allow those backends
significantly more flexibility in performing its allocations.


Could add _free_request_extras which would only be allowed to be
called from _alloc_request? That would enable not-polluting the
engine with common code I think.


If you look at where I think it should be placed inside lrc, then we
need multiple phases. Not that isn't much of a big deal:

request_alloc:

engine->pin_request()

/* prep */

engine->init_context()

are more or less what we need, it will take a bit of organisation to
align legacy / execlists. But it can be done.


Forgot to say, patch looks correct to me as it is. So r-b from that 
point of view anyway. Because in my mind solving the big performance 
sloppiness the series fixes is much more important than one (more) 
slight temporary design inelegance.


Regards,

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

Re: [Intel-gfx] [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation

[Chris Wilson]

On Wed, Apr 27, 2016 at 01:51:38PM +0100, Tvrtko Ursulin wrote:
> 
> On 26/04/16 21:06, Chris Wilson wrote:
> >In the next patches, we want to move the work out of freeing the request
> >and into its retirement (so that we can free the request without
> >requiring the struct_mutex). This means that we cannot rely on
> >unreferencing the request to completely teardown the request any more
> >and so we need to manually unwind the failed allocation. In doing so, we
> >reorder the allocation in order to make the unwind simple (and ensure
> >that we don't try to unwind a partial request that may have modified
> >global state) and so we end up pushing the initial preallocation down
> >into the engine request initialisation functions where we have the
> >requisite control over the state of the request.
> >
> >Moving the initial preallocation into the engine is less than ideal: it
> >moves logic to handle a specific problem with request handling out of
> >the common code. On the other hand, it does allow those backends
> >significantly more flexibility in performing its allocations.
> 
> Could add _free_request_extras which would only be allowed to be
> called from _alloc_request? That would enable not-polluting the
> engine with common code I think.

If you look at where I think it should be placed inside lrc, then we
need multiple phases. Not that isn't much of a big deal:

request_alloc:

engine->pin_request()

/* prep */

engine->init_context()

are more or less what we need, it will take a bit of organisation to
align legacy / execlists. But it can be done.
-Chris

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

Re: [Intel-gfx] [PATCH 1/9] drm: Add drm_mode_debug_printmodeline_raw

[Tvrtko Ursulin]

On 27/04/16 13:35, Jani Nikula wrote:

On Wed, 27 Apr 2016, Tvrtko Ursulin  wrote:

From: Tvrtko Ursulin 

Purpose is to enable drivers to print out just the mode
string with their own formatting.


Some alternatives that preserve the use of a single printk(), avoiding
garbled console output due to races (as discussed on intel-gfx in reply
to the cover letter [1]):

1) Simply add a prefix string parameter to use in
drm_mode_debug_printmodeline(). Really easy and covers most
needs. Maybe wrap this in a macro to use the caller's function name.

2) Model drm_mode_debug_printmodeline() after drm_ut_debug_printk(),
adding a mode parameter. Maybe wrap this in a macro to use the
caller's function name.


This sounds good to me...


3) Add char *drm_mode_line(mode) that kmallocs a mode line string, or a
drm_mode_line(mode, buf, bufsize) that prints the mode string to a
statically allocated buffer.


...but it only solved the modeline part of the story. Unless something 
like 3), which I specifically wanted to avoid. String handling etc.. 
best to be avoided in general if possible and more so for debug code 
only. Any potential bug in those is best avoided if they do not exist. 
And some of them log external input so even more so.


Something like debug_start/debug_print/debug_end would solve all that 
but that would be bigger and core.


I'll try to do 2) and see what to do with the rest...

Regards,

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

Re: [Intel-gfx] [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation

[Tvrtko Ursulin]

On 26/04/16 21:06, Chris Wilson wrote:

In the next patches, we want to move the work out of freeing the request
and into its retirement (so that we can free the request without
requiring the struct_mutex). This means that we cannot rely on
unreferencing the request to completely teardown the request any more
and so we need to manually unwind the failed allocation. In doing so, we
reorder the allocation in order to make the unwind simple (and ensure
that we don't try to unwind a partial request that may have modified
global state) and so we end up pushing the initial preallocation down
into the engine request initialisation functions where we have the
requisite control over the state of the request.

Moving the initial preallocation into the engine is less than ideal: it
moves logic to handle a specific problem with request handling out of
the common code. On the other hand, it does allow those backends
significantly more flexibility in performing its allocations.


Could add _free_request_extras which would only be allowed to be called 
from _alloc_request? That would enable not-polluting the engine with 
common code I think.


Regards,

Tvrtko


Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem.c | 28 +---
  drivers/gpu/drm/i915/intel_lrc.c| 16 ++--
  drivers/gpu/drm/i915/intel_ringbuffer.c |  2 +-
  3 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0e27484bd28a..d7ff5e79182f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2766,15 +2766,6 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
req->ctx  = ctx;
i915_gem_context_reference(req->ctx);

-   if (i915.enable_execlists)
-   ret = intel_logical_ring_alloc_request_extras(req);
-   else
-   ret = intel_ring_alloc_request_extras(req);
-   if (ret) {
-   i915_gem_context_unreference(req->ctx);
-   goto err;
-   }
-
/*
 * Reserve space in the ring buffer for all the commands required to
 * eventually emit this request. This is to guarantee that the
@@ -2783,20 +2774,19 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
 * away, e.g. because a GPU scheduler has deferred it.
 */
req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
-   ret = intel_ring_begin(req, 0);
-   if (ret) {
-   /*
-* At this point, the request is fully allocated even if not
-* fully prepared. Thus it can be cleaned up using the proper
-* free code.
-*/
-   i915_gem_request_unreference(req);
-   return ret;
-   }
+
+   if (i915.enable_execlists)
+   ret = intel_logical_ring_alloc_request_extras(req);
+   else
+   ret = intel_ring_alloc_request_extras(req);
+   if (ret)
+   goto err_ctx;

*req_out = req;
return 0;

+err_ctx:
+   i915_gem_context_unreference(ctx);
  err:
kmem_cache_free(dev_priv->requests, req);
return ret;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 910044cf143e..01517dd7069b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -698,7 +698,7 @@ static int execlists_move_to_gpu(struct 
drm_i915_gem_request *req,

  int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request 
*request)
  {
-   int ret = 0;
+   int ret;

request->ringbuf = request->ctx->engine[request->engine->id].ringbuf;

@@ -715,9 +715,21 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
return ret;
}

-   if (request->ctx != request->i915->kernel_context)
+   if (request->ctx != request->i915->kernel_context) {
ret = intel_lr_context_pin(request->ctx, request->engine);
+   if (ret)
+   return ret;
+   }

+   ret = intel_ring_begin(request, 0);
+   if (ret)
+   goto err_unpin;
+
+   return 0;
+
+err_unpin:
+   if (request->ctx != request->i915->kernel_context)
+   intel_lr_context_unpin(request->ctx, request->engine);
return ret;
  }

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ba5946b9fa06..1193372f74fd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2333,7 +2333,7 @@ int intel_engine_idle(struct intel_engine_cs *engine)
  int intel_ring_alloc_request_extras(struct drm_i915_gem_request *request)
  {

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: tidy up gen8_init_scratch (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: tidy up gen8_init_scratch (rev2)
URL   : https://patchwork.freedesktop.org/series/6315/
State : failure

== Summary ==

Series 6315v2 drm/i915: tidy up gen8_init_scratch
http://patchwork.freedesktop.org/api/1.0/series/6315/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (snb-x220t)
Test gem_exec_suspend:
Subgroup basic-s3:
fail   -> PASS   (snb-x220t)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (snb-x220t)

bdw-nuci7total:200  pass:188  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:200  pass:175  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:199  pass:158  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:200  pass:174  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:200  pass:178  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:200  pass:139  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:200  pass:169  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:200  pass:173  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:200  pass:189  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:200  pass:158  dwarn:0   dfail:0   fail:0   skip:42 
snb-x220ttotal:200  pass:157  dwarn:0   dfail:0   fail:2   skip:41 

Results at /archive/results/CI_IGT_test/Patchwork_2089/

4fa405ab5848b76c8568c7fb771d389a6695108c drm-intel-nightly: 
2016y-04m-27d-10h-47m-35s UTC integration manifest
6107550 drm/i915: tidy up gen8_init_scratch

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

Re: [Intel-gfx] [PATCH v6 01/25] drm/i915/fbdev: Call intel_unpin_fb_obj() on release

[Tvrtko Ursulin]

On 26/04/16 21:05, Chris Wilson wrote:

When releasing the intel_fbdev, we should unpin the framebuffer that we
pinned during construction.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/intel_display.c | 2 +-
  drivers/gpu/drm/i915/intel_drv.h | 1 +
  drivers/gpu/drm/i915/intel_fbdev.c   | 7 ++-
  3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b7cb632a2a31..87ce7852482b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2309,7 +2309,7 @@ err_pm:
return ret;
  }

-static void intel_unpin_fb_obj(struct drm_framebuffer *fb, unsigned int 
rotation)
+void intel_unpin_fb_obj(struct drm_framebuffer *fb, unsigned int rotation)
  {
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct i915_ggtt_view view;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cb89a35a6755..dcb19133f640 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1162,6 +1162,7 @@ void intel_release_load_detect_pipe(struct drm_connector 
*connector,
struct drm_modeset_acquire_ctx *ctx);
  int intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
   unsigned int rotation);
+void intel_unpin_fb_obj(struct drm_framebuffer *fb, unsigned int rotation);
  struct drm_framebuffer *
  __intel_framebuffer_create(struct drm_device *dev,
   struct drm_mode_fb_cmd2 *mode_cmd,
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index af561542a5a1..1c3ad121f1b9 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -287,7 +287,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
  out_destroy_fbi:
drm_fb_helper_release_fbi(helper);
  out_unpin:
-   i915_gem_object_ggtt_unpin(obj);
+   intel_unpin_fb_obj(>fb->base, BIT(DRM_ROTATE_0));
  out_unlock:
mutex_unlock(>struct_mutex);
return ret;
@@ -551,6 +551,11 @@ static void intel_fbdev_destroy(struct drm_device *dev,

if (ifbdev->fb) {
drm_framebuffer_unregister_private(>fb->base);
+
+   mutex_lock(>struct_mutex);
+   intel_unpin_fb_obj(>fb->base, BIT(DRM_ROTATE_0));
+   mutex_unlock(>struct_mutex);
+
drm_framebuffer_remove(>fb->base);
}
  }



Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

[Intel-gfx] [PATCH v4 08/10] drm/i915: Unduplicate VLV phy pre pll enabling code

[Ander Conselvan de Oliveira]

The code used by the DP and HDMI paths was very similar, so make them
share it. Note that this removes the write to signal level registers
from the HDMI pre pll enable path, but that's OK since those are set
in vlv_hdmi_pre_enable() function.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Jim Bride 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_dp.c   | 25 +
 drivers/gpu/drm/i915/intel_dpio_phy.c | 28 
 drivers/gpu/drm/i915/intel_hdmi.c | 28 +---
 4 files changed, 31 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8d07f84..8a8a76d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3591,6 +3591,7 @@ void chv_phy_post_pll_disable(struct intel_encoder 
*encoder);
 void vlv_set_phy_signal_level(struct intel_encoder *encoder,
  u32 demph_reg_value, u32 preemph_reg_value,
  u32 uniqtranscale_reg_value, u32 tx3_demph);
+void vlv_phy_pre_pll_enable(struct intel_encoder *encoder);
 
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6b953b3..bb26caf 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2791,32 +2791,9 @@ static void vlv_pre_enable_dp(struct intel_encoder 
*encoder)
 
 static void vlv_dp_pre_pll_enable(struct intel_encoder *encoder)
 {
-   struct intel_digital_port *dport = enc_to_dig_port(>base);
-   struct drm_device *dev = encoder->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc =
-   to_intel_crtc(encoder->base.crtc);
-   enum dpio_channel port = vlv_dport_to_channel(dport);
-   int pipe = intel_crtc->pipe;
-
intel_dp_prepare(encoder);
 
-   /* Program Tx lane resets to default */
-   mutex_lock(_priv->sb_lock);
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(port),
-DPIO_PCS_TX_LANE2_RESET |
-DPIO_PCS_TX_LANE1_RESET);
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(port),
-DPIO_PCS_CLK_CRI_RXEB_EIOS_EN |
-DPIO_PCS_CLK_CRI_RXDIGFILTSG_EN |
-(1<sb_lock);
+   vlv_phy_pre_pll_enable(encoder);
 }
 
 static void chv_pre_enable_dp(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 8fb4fda..975965a 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -395,3 +395,31 @@ void vlv_set_phy_signal_level(struct intel_encoder 
*encoder,
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW5(port), DPIO_TX_OCALINIT_EN);
mutex_unlock(_priv->sb_lock);
 }
+
+void vlv_phy_pre_pll_enable(struct intel_encoder *encoder)
+{
+   struct intel_digital_port *dport = enc_to_dig_port(>base);
+   struct drm_device *dev = encoder->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc =
+   to_intel_crtc(encoder->base.crtc);
+   enum dpio_channel port = vlv_dport_to_channel(dport);
+   int pipe = intel_crtc->pipe;
+
+   /* Program Tx lane resets to default */
+   mutex_lock(_priv->sb_lock);
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(port),
+DPIO_PCS_TX_LANE2_RESET |
+DPIO_PCS_TX_LANE1_RESET);
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(port),
+DPIO_PCS_CLK_CRI_RXEB_EIOS_EN |
+DPIO_PCS_CLK_CRI_RXDIGFILTSG_EN |
+(1<sb_lock);
+}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5c044ce..1a58ba7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1629,35 +1629,9 @@ static void 

[Intel-gfx] [PATCH v4 04/10] drm/i915: Unduplicate CHV phy-releated pre pll enabling code

[Ander Conselvan de Oliveira]

The same logic is used for DP and HDMI so move it to intel_dpio_phy.c.

v2: Rebase

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Jim Bride 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_dp.c   | 83 +--
 drivers/gpu/drm/i915/intel_dpio_phy.c | 81 ++
 drivers/gpu/drm/i915/intel_drv.h  |  5 +++
 drivers/gpu/drm/i915/intel_hdmi.c | 74 +--
 5 files changed, 89 insertions(+), 155 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7309d3f..4e34d3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3583,6 +3583,7 @@ void chv_set_phy_signal_level(struct intel_encoder 
*encoder,
  bool uniq_trans_scale);
 void chv_data_lane_soft_reset(struct intel_encoder *encoder,
  bool reset);
+void chv_phy_pre_pll_enable(struct intel_encoder *encoder);
 
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3a411de..1f6fd89 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -131,11 +131,6 @@ static void vlv_steal_power_sequencer(struct drm_device 
*dev,
  enum pipe pipe);
 static void intel_dp_unset_edid(struct intel_dp *intel_dp);
 
-static unsigned int intel_dp_unused_lane_mask(int lane_count)
-{
-   return ~((1 << lane_count) - 1) & 0xf;
-}
-
 static int
 intel_dp_max_link_bw(struct intel_dp  *intel_dp)
 {
@@ -2915,85 +2910,9 @@ static void chv_pre_enable_dp(struct intel_encoder 
*encoder)
 
 static void chv_dp_pre_pll_enable(struct intel_encoder *encoder)
 {
-   struct intel_digital_port *dport = enc_to_dig_port(>base);
-   struct drm_device *dev = encoder->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc =
-   to_intel_crtc(encoder->base.crtc);
-   enum dpio_channel ch = vlv_dport_to_channel(dport);
-   enum pipe pipe = intel_crtc->pipe;
-   unsigned int lane_mask =
-   intel_dp_unused_lane_mask(intel_crtc->config->lane_count);
-   u32 val;
-
intel_dp_prepare(encoder);
 
-   /*
-* Must trick the second common lane into life.
-* Otherwise we can't even access the PLL.
-*/
-   if (ch == DPIO_CH0 && pipe == PIPE_B)
-   dport->release_cl2_override =
-   !chv_phy_powergate_ch(dev_priv, DPIO_PHY0, DPIO_CH1, 
true);
-
-   chv_phy_powergate_lanes(encoder, true, lane_mask);
-
-   mutex_lock(_priv->sb_lock);
-
-   /* Assert data lane reset */
-   chv_data_lane_soft_reset(encoder, true);
-
-   /* program left/right clock distribution */
-   if (pipe != PIPE_B) {
-   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
-   val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
-   if (ch == DPIO_CH0)
-   val |= CHV_BUFLEFTENA1_FORCE;
-   if (ch == DPIO_CH1)
-   val |= CHV_BUFRIGHTENA1_FORCE;
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
-   } else {
-   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
-   val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
-   if (ch == DPIO_CH0)
-   val |= CHV_BUFLEFTENA2_FORCE;
-   if (ch == DPIO_CH1)
-   val |= CHV_BUFRIGHTENA2_FORCE;
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
-   }
-
-   /* program clock channel usage */
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(ch));
-   val |= CHV_PCS_USEDCLKCHANNEL_OVRRIDE;
-   if (pipe != PIPE_B)
-   val &= ~CHV_PCS_USEDCLKCHANNEL;
-   else
-   val |= CHV_PCS_USEDCLKCHANNEL;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW8(ch), val);
-
-   if (intel_crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW8(ch));
-   val |= CHV_PCS_USEDCLKCHANNEL_OVRRIDE;
-   if (pipe != PIPE_B)
-   val &= ~CHV_PCS_USEDCLKCHANNEL;
-   else
-   val |= CHV_PCS_USEDCLKCHANNEL;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW8(ch), val);
-   }
-
-   /*
-* This a a bit weird since generally CL
-* matches the pipe, but here we need to
-* pick the CL based on the port.
-*/
-   val = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW19(ch));
-   if (pipe != PIPE_B)
-   val &= ~CHV_CMN_USEDCLKCHANNEL;
-   else
-   

[Intel-gfx] [PATCH v4 02/10] drm/i915: Unduplicate CHV signal level code

[Ander Conselvan de Oliveira]

The code for programming voltage swing and emphasis was duplicated
between DP and HDMI code. Move that to a new file, intel_dpio_phy.c.

v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville)
Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Jim Bride 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_drv.h   |   5 ++
 drivers/gpu/drm/i915/intel_dp.c   | 103 ++--
 drivers/gpu/drm/i915/intel_dpio_phy.c | 122 ++
 drivers/gpu/drm/i915/intel_hdmi.c |  70 +--
 5 files changed, 136 insertions(+), 165 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_dpio_phy.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 723c502..63c4d2b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -59,6 +59,7 @@ i915-y += intel_audio.o \
  intel_bios.o \
  intel_color.o \
  intel_display.o \
+ intel_dpio_phy.o \
  intel_dpll_mgr.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 32f0597..9760b42 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3577,6 +3577,11 @@ void intel_sbi_write(struct drm_i915_private *dev_priv, 
u16 reg, u32 value,
 u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 
+/* intel_dpio_phy.c */
+void chv_set_phy_signal_level(struct intel_encoder *encoder,
+ u32 deemph_reg_value, u32 margin_reg_value,
+ bool uniq_trans_scale);
+
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c12c414..bdafd72 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3276,23 +3276,12 @@ static uint32_t vlv_signal_levels(struct intel_dp 
*intel_dp)
return 0;
 }
 
-static bool chv_need_uniq_trans_scale(uint8_t train_set)
-{
-   return (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) == 
DP_TRAIN_PRE_EMPH_LEVEL_0 &&
-   (train_set & DP_TRAIN_VOLTAGE_SWING_MASK) == 
DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
-}
-
 static uint32_t chv_signal_levels(struct intel_dp *intel_dp)
 {
-   struct drm_device *dev = intel_dp_to_dev(intel_dp);
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
-   struct intel_crtc *intel_crtc = to_intel_crtc(dport->base.base.crtc);
-   u32 deemph_reg_value, margin_reg_value, val;
+   struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+   u32 deemph_reg_value, margin_reg_value;
+   bool uniq_trans_scale = false;
uint8_t train_set = intel_dp->train_set[0];
-   enum dpio_channel ch = vlv_dport_to_channel(dport);
-   enum pipe pipe = intel_crtc->pipe;
-   int i;
 
switch (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) {
case DP_TRAIN_PRE_EMPH_LEVEL_0:
@@ -3312,7 +3301,7 @@ static uint32_t chv_signal_levels(struct intel_dp 
*intel_dp)
case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
deemph_reg_value = 128;
margin_reg_value = 154;
-   /* FIXME extra to set for 1200 */
+   uniq_trans_scale = true;
break;
default:
return 0;
@@ -3364,88 +3353,8 @@ static uint32_t chv_signal_levels(struct intel_dp 
*intel_dp)
return 0;
}
 
-   mutex_lock(_priv->sb_lock);
-
-   /* Clear calc init */
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
-   val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
-   val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
-   val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
-
-   if (intel_crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
-   val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | 
DPIO_PCS_SWING_CALC_TX1_TX3);
-   val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
-   val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
-   }
-
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
-   val &= ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
-   val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW9(ch), val);
-
-   if 

[Intel-gfx] [PATCH v4 03/10] drm/i915: Unduplicate chv_data_lane_soft_reset()

[Ander Conselvan de Oliveira]

The function chv_data_lane_soft_reset() was duplicated in DP and HDMI
code. Move it to intel_dpio_phy.c.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Jim Bride 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/intel_dp.c   | 44 ---
 drivers/gpu/drm/i915/intel_dpio_phy.c | 43 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 44 ---
 4 files changed, 45 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9760b42..7309d3f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3581,6 +3581,8 @@ void vlv_flisdsi_write(struct drm_i915_private *dev_priv, 
u32 reg, u32 val);
 void chv_set_phy_signal_level(struct intel_encoder *encoder,
  u32 deemph_reg_value, u32 margin_reg_value,
  bool uniq_trans_scale);
+void chv_data_lane_soft_reset(struct intel_encoder *encoder,
+ bool reset);
 
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bdafd72..3a411de 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2460,50 +2460,6 @@ static void vlv_post_disable_dp(struct intel_encoder 
*encoder)
intel_dp_link_down(intel_dp);
 }
 
-static void chv_data_lane_soft_reset(struct intel_encoder *encoder,
-bool reset)
-{
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   enum dpio_channel ch = 
vlv_dport_to_channel(enc_to_dig_port(>base));
-   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
-   enum pipe pipe = crtc->pipe;
-   uint32_t val;
-
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
-   if (reset)
-   val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
-   else
-   val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
-
-   if (crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
-   if (reset)
-   val &= ~(DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET);
-   else
-   val |= DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
-   }
-
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
-   val |= CHV_PCS_REQ_SOFTRESET_EN;
-   if (reset)
-   val &= ~DPIO_PCS_CLK_SOFT_RESET;
-   else
-   val |= DPIO_PCS_CLK_SOFT_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
-
-   if (crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
-   val |= CHV_PCS_REQ_SOFTRESET_EN;
-   if (reset)
-   val &= ~DPIO_PCS_CLK_SOFT_RESET;
-   else
-   val |= DPIO_PCS_CLK_SOFT_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
-   }
-}
-
 static void chv_post_disable_dp(struct intel_encoder *encoder)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index cbe1703d..9854c93 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -120,3 +120,46 @@ void chv_set_phy_signal_level(struct intel_encoder 
*encoder,
 
 }
 
+void chv_data_lane_soft_reset(struct intel_encoder *encoder,
+ bool reset)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum dpio_channel ch = 
vlv_dport_to_channel(enc_to_dig_port(>base));
+   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
+   enum pipe pipe = crtc->pipe;
+   uint32_t val;
+
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
+   if (reset)
+   val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
+   else
+   val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
+
+   if (crtc->config->lane_count > 2) {
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
+   if (reset)
+   val &= ~(DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET);
+   else
+   val |= DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
+